6.07.2012

Interesting idea

I got an interesting idea a while ago but just fully realized the awesomeness of it. Once again it's about programming languages, dynamic memory allocation to be specific: what's the main problem of it? You want to allocate and release as much and often as possible with no delay while doing so. Usually, this is done with linked list on sytem layer or other stuff that increases memory load the more tings you add and stuff get's overly fragmented over time. Anyway, I've also been looking for something dynamic memory management isn't necessary or atleast so simplified that new and delete becomes an O(1) operation or merged or something like that. Ever thought about LISP would do garbage management? I certainly did while not spoiling the fun via looking it up. I didn't any possible difference to what's in Java or other garbage collecting languages until I realized that if every allocation has the same size and the same link possibility as linked list, then you only need to re-link lists. For example, let's use most of the RAM for a pointer/word pairs and link them in one single list. New would take n elements from the list, delete would move n elements to the old list. Done! I know, it sounds incredibly stupid and wasteful to essentially allocate double memory, but it's a very simple and stable concept. No null pointers by default! Just manage lists and watch for empty ones. Of course this is for singly-linked list and compound types still have to listed, too - making property iteration a pain in the ass. Nontheless, it's very effective in what it does and and I'll consider using is for some parts of my programming languages where it could replace otherwise painful memory management. However, this would only work effectively if you didn't want to access offsets an non-bound properties. All in all, each access to the nth element should either be iterated before or during code block execution. During is bad. Very bad. Before requires dynamic binding so that you can let your functions work on offsets. I sorta hesitate using it due to this disadvantage, but maybe I can code something very small utilizing it or add a feature for quick singly-linked list use. Well, the same idea also applies to doubly-linked list, so it's problem worth this instead due to increased flexibility.

Hmmmm.... it's too bad that most of the cool ideas have severe drawbacks. And you can't change it cause it's too bound to the base of computing. Anyway, I have a few other concepts for my language, too, that are nice enough to have. But I already know that realizing all the stuff I planned so far requires a looooot of work I can't afford right now. The simple, realizable ideas are often the slow or wasteful ones. I'm turning my own concept more and more into something less strict by binding all kinds of symbols when assigning code to a symbol so that it can be used. However, it's still creepy to think about the parsing I'll need to as well as the stack management... I need to find a way around this. It's no problem to change a syntax to something easier to parse, but it's problematic to use this syntax later as I don't really want to sacrifice the possibilities I know from C. And the resulting byte code isn't optimized at all, so I wonder whether it's of use to rely on the same mechanics I use in C. Maybe it's a good idea to reduce stuff step-by-step. Stuff that is of use in C and stuff that can be replaced with some other pattern or concept. Seperating high level parts that don't need to be super-effective from low level parts might be a good first step. I just don't want to spent all time thinking about but finding something that's easy to realize, comftable to use and quick to execute...

Well, I think my problem's the parsing. The knowledge that every infix notation requires a certain amount of optimization and complex operator system to work. I know that I'd love a purly symbolic operator base, but the amount of work to parse all this stuff is too annoying to me. So I'll probably need to find something else, but I don't know whether I want or can cope with something else! Maybe I should combine the possibility of prefix and postfix notation. This enables me to sorta emulate the needed infix sugar if I really need it. Once in a while I'm thinking about this and I realized how I dislike the disadvantages of it. But well, what should I do? Can't spent all day wishing my programming language popping up behind me and yelling "Oh boy, you made it!".

No comments: