hm, i had a look at your definition
looks like you have a slightly different design goal than me, you were more or less replacing each nfo action with a textual description
I consider this a first step to get acquainted with the problems and challenges in NFO. GRL is a step forward imho compared to NFO (less hexadecimal coding to do) while still being able to express everything
i was aiming at a higher level of abstraction, e.g. the "feature" did not appear anywhere in my specification, it gets implicitly defined by which original object you were replacing, graphics will automatically get "linked" to the object they are specified in
So what do you do when I make something completely new then? Somewhere I will have to tell whether it is a train or a ship.
I completely agree with you that key=value
is not what you want (that's why it is a first step). The problem I see happening at some point in time though is that the higher level language is not completely supporting what a user wants, either because he wants something that the higher level language was not designed for, or because GRF and NFO were extended in some direction that the higher level language has not been developed for (eg the new airport branch in ottd). In that case, I don't want to be forced back to NFO-like coding.
In other words, my key=value stuff is intended as fallback to the higher level language.
At the same time, I get to understand the NFO language, and I develop code that understands how to make a NFO sprite from a set of values. That should make development of higher level primitives easier.
Last but not least, in this way I get a framework where I can put new primitives in and always be able to create complete NFO files without having to code some parts in NFO.
In other words, I don't exclude such higher level primitives as the next step, I merely added an additional step, namely getting some feeling for where the tricky parts are going to be, and at the same time developing useful (both for me and for the community (I hope)).
also, in my plan, callbacks will look like functions in most regular programming languages, a programmer in a higher level language doesn't have to know what "registers" are
I am also quite annoyed at the reversed action2+3 nodes. Function-like syntax sounds like a good idea.
Do you have a nice syntax in mind?
this approach generally needs a higher amount of analysis and transformations in the compiler
yep, and that's a good thing. The computer should go figure out what to generate rather than me.
one last comment: using "-" in identifiers is a really bad idea
I had some doubts about this one. I still think it looks very nice, but you are probably right, I should eliminate it.