1.02.2011

Another idea

Since I had this idea of making my own programming language that translates to NBC, I got some nice ideas in general for making a language for programming. Some thoughts I came to the conclusion that I don't want to create a language that doesn't use typical computer science  terms for it's elements. That might sound strange, it gives you a better idea what's behind the code you're writing. When you learn a new language, you'll need to what terms do what in the language, where it puts which kinds of variables and what other concepts it used etc and so on. Sometimes you'll never know what kind of variables lies in the stack, is static or part of the heap. You'll have to figure it out or read it in the 300+ pages manual. Sometimes things aren't really explained in details or how they work internally. My idea is, if I'll ever design a language -which will probably happen in my life-, I'll try to make EVERYTHING as direct as possible. Which means that if you want to put something on the stack, you call some kind of global function with "stack" in the name. The same for static and heap objects, etc. Even better, I could use only object-oriented access structures. So there'd three objects, "static", "stack" and "heap", representing the memory objects you'd add something to. Spanning it over more than just basic allocation, there'd be a "class" object you can use to add classes and so on. I kind of like the idea and it has nice side effect: you could port it to other languages using a converter and it would say you immediately that you can't use certain objects or features in the destination language. You'd also have immediate knowledge about where objects would lie and why something is slow like hell or so. If you get a nullpointer error cause you referenced a not-anymore-existent object from the stack, you could easily identify it cause you've put a big "stack" in front of it.

That's basically what I'm usually complaining about. One syntax for all, exporting to a language of choice using the right converter. So you benefit from a more consistent, non-confusing syntax and destinations languages performance (of course depending on how the converter does it). And well, designing it gives me also an insight to OOP and language design problems in general. One design floating in my head was to have declaration/definition-less programming. Instead of making declarations before you use a class or object, you could write random function names and it runtime-check for it's existence, and link name and declaration on demand as you go. It'd be like having a pool of identifiers you could branch into more identifiers, ultimately leading some kind of randomly accessed chaos lists. The only way the find, for example, a method of a class would be to use a class identifier and search for it inside the pool. Once you found it, it would be linked to the name you used via runtime. I thought about a longer while and came to the fact that you'd need a huge hash table to look if the identifier was already linked. An identifier would consist of checksums of their names you used in the code. And that also means that you'd need identify a single class by using all it's superior scope identifiers. This way you can guarantee that it's possible to identify even completely new classes on demand and so on.

This brings some advantages and some disadvantages. The advantag is that you can have totally random objects with totally random classes. You could probably even generate classes on the fly and search for matching functions using parameter analysis and so on. So no more loss due to definition changes. It'd be like a search engine - maybe add tags, too, and it's possible to find a lot of different things. The first disadvantage coming to my mind is that it'd require to check EVERY member or class access using the hash table. Hash calculation and searching can be costly, especially when a lot of types share a single hash entry. And if the identifier wasn't found yet (happening EVERY first time access) it would also search through all branches coming from the superior identifier. That's quite a heavy overhead, even if you look for already know identifier before the real program starts. And the other big disadvantage is type safety and debugging. You can't just check for non-existing members during compilation since every member set is unknown/expandable. And type safety? Well, forget that. Not during compilation, that only works during execution. Of course would it be possible do to some dry checks during compilation, but that doesn't as you can add everything anytime. Ok, hm... with some special keywords it'd be possible mark a class as fixed. That could integrate nicely into my current language concept! Yes, that's it. Well, I guess I'd need a bytecode interpreter for that... However, the export to other languages could still work as I can simply disable export if specific language features where used. Good idea! Yes, I think that's the "glorious way to go" for me.

No comments: