Yesterday my mind circled around certain aspects of my programming language as well as the fact that I still wasn't able to figure out a nice concept solving all things regularly to do in general programming. That means that the current as it was before wouldn't been able to work comftably (though the bytecode for it probably would). So I realized that my actual wish to base return and input values on stacks did already exist: Forth! Stack-based languages and such. I always loved the concept and looking at it again, it makes writing formulas kind of more efficient as I'd usually have to formalu in head or write it down before tweaking it to work nicer. The best formulas I ever wrote for graphics programming were extremely straight-forward, not utilizing any complex expression but exact operation order to reach a specific goal. And that's exactly what you're doing in Forth, though it's something easier to write in from right to left instead of left to right. Therefore, I think I'll a) look at existing Forth implementations and related variations to look how they solved specific problems, non-stack-based things such as array access and so on. I could figure out my own, but it's always a good idea to look for existing solution. That said, I'll also add a bunch of own, more C-like and register/array-based extensions to the general idea as well as direct support of batch instructions one can utilize more nicely integrated this way than it would be in a typical C-like language. All in all the idea of Forth seems waayyy more suitable for fast execution speed and small bytecode because there's no need to store any parameter information. But one thing I'll do is to also put in some parameter-supporting elements like special keywords for multiple stacks serving special grouping purposes you can use for function parameters. Yeah, let's say this brings all my ideas forward and does still make it possible to include all my previously designed syntax elements. Too bad I didn't learn designing in Forth before! Good thing to practive it now when having an own language.
Yay! I hope this finally prevents brain metabolism disorders for later plannings. Making programming languages is either a very slow, planned process or a quick idea with some things you can already rely on. In my case, it's part of my philosophy of giving only a programmer only the stuff that'd make his alghorithm/program better and more efficient. Currently, a stack base is the best I can think of in a bytecode language.