2.12.2011

So as I got another brainstorming session done and I must I quite my current idea how I will step by step, slowly conceptualize the right structure for my own language. At first I thought about how to support only C functions and how well one could integrate it into the idea of step-based, custom compilation and so on. But then I got quite an interesting idea: I like using paranthesis to seperate not only logical blocks and document syntactical specialties using them. So I got the idea of relying on paranthesis in general, similar to how Lisp does it. Of course not in the way that everything is stored in the same format or requires endless amounts of closing brackets after a code. Rather like using all four kinds of brackets: (), [], {} and <> as a fundamental parts of the syntax. That also led to a weird idea: Why don't create a bytecode that can also be exported to C directly and then mixing it with static code? Having a flexible code execution unit INSIDE your static program! And the interesting part of it is that you can access the same memory, creating bytecode via your static code and thus having an effectively self-programming program benefitting from both fast, static code and slower, dynamic code! And on the plus side you can at first focus development on the bytecode and then writing the converter. When they use the same memory, it's probably an equivalent of having a modifyable code. However, the brackets brought to that cause I usually associated () with beeing dynamic, soft and round and [] as fixed and rather static - almost conservative. So why not use this association within the code itself? So maybe you could specify on your own what wll come - [code] for static code and (code) for bytecode. Note that it's sometimes easier to start with an existing set of code, so this is definitely something I may keep in mind. However, this can also be applied to memory. Having [] mark a static variable area and () a set of dynamically allocatable things. I want to have a strong distinction between static and dynamic data, since this you always need static memory to store the adresses you allocated dynamically. In the end, everything ends up in normal memory except when the compiler decides to choose registers as he wishes. And there it also comes to how my memory layout would look like. If I think about it, there's probably a lot of time between converting my code to C and then compiling the C code. I'm not sure whether I want to export it directly so that you can see all your variable names like you wrote them in C code. I still need to access all memory from bytecode. And at the moment my unfinished bytecode design bases heavily on adresses instead of identifiers for variables. And I'm sure it's not really useful to do otherwise - using a simple offset in a big block of memory is easier to export than always letting the bytecode know where what address of which variable is. I could rely on a simple layout and the C compiler would calculate all the static array offsets and we wouldn't need to bother about naming them. Plus it may make compilation easier for the compiler cause he doesn't need to check for existing names and types etc. If there's just a big block you can freely access it without all the things you know from C's harsh compilation errors.

No comments: