A recent grumpyness about how few you can generalize without overhead and disadvantages made me think more about my programming language concept. So far, all control about function calls (when, where, inline or not and how), as well as input/output of values is done and now it comes to how I should implement variables, static/dynamic memory and so on. My biggest problem is how to implement static variables. It's easy to handle dynamic memory, as it requires just an adress to work with. But in essence you'll need to know the place where this adress lies and so on. Currently, I don't really make any difference between types and variables. I have a static memory and it's filled with data. Access via byte address, type interpretation via casts in the C-code. Pretty simple idea, but I just don't know how to make work nicely. At first, you'll need to know how many bytes you want for your static memory. Simple: as many bytes as you'd need for the total size of all global variables. And where do you store this information then? I don't want to store it in a special header in the bytecode or so since I'd rather like to keep it clean from anything that would generate overhead during execution. So another idea would be to include a command that allocates as much storage as needed for static variables. No allocation would mean no variables to allocate. This is quite interesting as it enables you to make with only input adresses directly inserted as well as an output address. No temporary variables, not allocation - in essence a perfect inline function, a simple set of commands on a given set of data, just perfect. In the end, I can use this ideal function as a base for all bytecodes I'd want to execute. So it all boiles down to a single command to allocate a set of static memory, keeping the address of it in a single variable required for each bytecode interpreter. But still - how to determine the amount of memory required efficiently? My idea is to introduce a new bracket type that's the compiler step I was talking about before: a pair of {} brackets to signal a pre-compilation calculation. You could still code everything you want with simply using literals - no variable names, just relative addresses. In the way, variables are only bound addresses with a given type and thus size. However, even if I'd had a pair of {} brackets with code in them counting the number of defined variables, it doesn't qualify as something actually useful in this case. If it'd be execute before actual compilation, you couldn't rely on it having variables allready. So you'd need to use numbers - not a problem at all. But even then, is it really the compiler step I want? No. If you compile and execute each {} pair, you'd need to input something, in this case the code itself to look for definitions of variables etc. Kinda cause this would also require some kind of literal aliasing the code itself, enabling reflection for the complete program. I don't know. This kind of goes into a wrong direction I think. Personally, I think it's better to think about something different. Also, what you need to do if you'd want to execute a code? Right, compile it. Thus every {} requires compilation and returning a value. I think it's a too special step somehow. I'll keep it in the concept for things like... I don't know. Maybe config files for execution you can read in using these unnamed programs and generating a different output file. Hm, could be useful one day. No, it may be an interesting features for flexibility purposes, but not for solving the variable problem. Oh and then there's the alias problem. Since it doesn't make sense to use {} all the time, I need a notation for aliases, namespace, scopes etc. Yes, you could do everything by using numbers as addresses. But thats no way to code appropriately, for obvious reasons. So here the design of the language's keywords or symbols kicks in. I need to design them! This will be fun, finally choosing the keywords and designs one would want to use. Even the functions need names, so I can hopefully rely on a simple symbol-based solution... Hm. Not sure if it's wise to use so many symbols. I like to have the freedom to use whatever symbol combinations I want for function and variable names in general. It's useful when, for example, integrating common mathematical notations or so. I can image it beeing more useful than just keeping keywords free... Yeah.

"So what's next, Jimmy?"

No comments: