Aw, man. Nothing is more boring than a lecturer only sending his partner to his first meeting with the students. It means no real introduction by guy who'll actually do the stuff for the rest of the semester but instead you get something that's totally unrelated. Hmph.

Anyway, I could not build any Lego guns there, so I made some more notes and thoughts about the programming language I planned some time ago. I also wrote a blog post with more specific syntax and details behind, but I lost it eventually. So I'm quite far, farther than I thought. The basic syntax of function calls (the most important element in this language), how to define and declare stuff etc. You'll get the idea behind sending and receiving data to and from functions if you're familiar with modular synthesizer: they have input and output slots. It's designed to to get rid of the problem of designing inline function with reference or pointer parameters. Instead of always beeing aware of how they should be designed to tell it even the dumbest optimizer to inline, you can specify it by yourself and effectively passing zero parameters as all inputs and outputs are, when inlining, direct insertions of values put in by the calling line. I never the math-like function syntax of most programming languages. It often limites you to the use of mathematical notations, only one return type on a side and makes the language more difficult to parse with the addition of operators. I often think that I now have a set of variables, listing them as parameters as I type and then looking for the correct functions I want to call. You'll need to insert it before, you can't write from left to write in the way I think when writing quick or simple things. Yes, I know! It's just sugar on my cake, but I love sugar and so I do want it. Anyway, the actually interesting point beside notation is that I found some surprisingly smart way of operating with variable parameters during compilation and runtime. Since I only have some brackets, symbol names, ";" and "<", ">", it's quite easy to add more essential features with additional symbols. So the thing I talking about is the insertion of macros using the {} brackets. Not macros in the sense of C, no. But rather complete compile-time code blocks. So you can for example check for wrong bounds, wrong types etc - functions don't have a specified interface, they are rather declaration-less except for the name. So to check for correct parameter types you use a macro that'll access global, language-defined objects with information about how many input and output parameters are there, what type they are , whether they are variables, literals, arrays, etc... even their names and the name of the function! That said, you can check parameters with a single line by using logic and type equality. At this point, it wouldn't base on any rtti data but only the data the compiler also knows. It makes me amped to even think about it. It makes a couple of things easier: debugging (get function and variable names, even calling position), reflexion (you could take a look at the call tree, the context and such), auto decision between fixed and dynamic values (whether it's better to unroll a loop or so) and whatever not. So whatever is normally done by the language during runtime or by it's optimizers can, to a larger part, be done by such a system while still looking this the fixed version you'd normally write. But it requires the compiler to create function definitions by their call and thus a lot more evaluation and so on. Not sure where to put this macro - in the function body where it has the highest relevance? Also, when to instantiate can only depend on the number of input/output/types combination. So each different syntax will create an instantiation if the macro doesn't call back to the compiler and stop compilation process. It's also uncertain whether it makes sense to allow the macros to generate parsable strings or bytecode directly. I think the parsing stuff should be done once, cause it'd result in exponentially more work as every generated piece of code needs to be parsed. So I better move on continuing the bytecode/code insertion part inside the language and how to access the compiler structures. I think using the classic object.attribute syntax isn't necessary as I can abuse the in/out syntax for this, too. And on the plus side it gives you equal attribute/property access - x and doWeirdStuff are accessed/called/set/read in the same syntax, no need to introduce another element.

It's a language for lazy bums not interested in learning too many syntax rules and people who like to reduce every line of source code spent to overview's sake. That makes a reduced but quite ugly to look at code. It's not made for readability or relying on existing conventions. For example, "a<(<0));" would be the same as "a=b+(c==b?c:0)" in C. Everythings a function that'll eventually converted back to the C expression but delivering other features you don't have in C, especially those whether multiple go in and out, where code looks often the same but has only a few differences and so on. I'm convinced that the concept can prove worthy in reality, especially when the limitations of C can't help you expressing the code you really want in a time and cost efficient way.

However, future music and stuff. Back to doing anarchic stuff.

No comments: