Today was a very interesting day as I figured so many aspects of my programming languages design. Enough to that I brainstormed a major part of it's implemention and formal description (which is, if you already know what you want, not to hard to do at once). To my surprise, it turned out that I'd benefit more from seeing the language as something abstract, more reflexive than it was before. The essential concept of giving a program the ability to compile-time execute byte code that knows about names and types of parameters and the like is reflexion. Though not exactly during runtime, it's possible to put it in, too.
However, the approach I use to give the language it's generic features is afaik far far away from what C/C++ and other languages do. Instead of explicitely specifying each type and parameter for every function and adding functions instances as you need them, my approach is not convert it to implicite typing. Means you don't specify required types for input/output parameters but rather constraints about how the data it takes and gives should look like. Then, depending on the stuff passed as input and output, the bytecode compiler instanciates function bodies with the appropriate type informations to keep it as static as possible inside the final bytecode. So you will have 100% compatibility to normal C code and will be able to even use the output names and structures inside external header files, as long as the converter works flexible enough. And this implicite design brings also other questions like to how and it what manner types are to compare, how you can work with them, with reflexion, typeIDs during runtime etc... I came to this version when I was thinking about how to type and instanciate variables. So far, I got a very generic naming system done, that is part of a system to interpret sequences of bytecode as structures. So a long functions with variables and code in it will translate to a structure description, longer or shorter. Depending on how well I will be able to design the ways of checking for compatibility with other structures, it will translate to a mask usable for comparison. So taking this as a base for more sophisticated variable declarations creates the possibility to write code, structures and variables instanciation in the same syntax and same structure with NO massive ruleset required to parse it. There are a few rules and a few symbols combinable in a limited set of ways. The devil lies in generating and iterating through structures, making compilation a bit more calculation-intensive compared to rule checking. But that's not really something bringing down the time required for it. Most stuff is still done by the C converter later, so it's convenient to have an executable bytecode with less compiling on hand.
As you see, stuff's going on and well enough to say that it approximites an real programming language. I'll need to make some changes for the input/output parameter accesses another day, hm... More and more I think about how to take advantage of C libraries then. The problem is, executing bytecode doesn't give you the possibility to call C functions except if they are build into the executer. Sometimes it sounds better to create bytecode executers on demand, so that one will be able to execute the most common ones. Dunno, maybe I'll think about soo, but probably not. It's not that it's so essential for getting the code running here.