Originally posted by WhiteYoshiEggWow, that's actually really cool! I had no idea you were working on stuff like this.
Haha, yeah, that's because I love surprising people!
As already mentioned, I mainly did it because there was that one missing feature I didn't know how to work around without leaving the bounds of Asar, namely the readfile functions. I could have used an external script to generate the tables I need, but that didn't feel like a pleasing solution to me (mainly because it requires you to install some kind of interpreter on the system, unless you use bat files, which I have no experience with). Anyways, while I was already at it, I thought "well, why not implement those other features I wanted to have in the past and also fix a few of the bugs that annoyed me".
Ironically, I encountered a lot of the bugs I fixed just from working on Asar. I didn't know about them beforehand and only stumbled across them while verifying certain features or adding in my own stuff. This mainly goes for most of the bugs related to functions. I didn't know about those until trying to add in my own functions and noticing they were never executed correctly.
Originally posted by WhiteYoshiEggAnd while I'm at it, @Alcaro: you once mentioned you had discontinued Asar and dislike the way you coded it back then. Just out of curiosity, would you mind explaining what you'd do differently today?
After having worked on this, I can kinda see what he means. The source code of Asar isn't in the best shape. This means: in some places it's hard to understand and therefore hard to maintain (and even harder to extend). A lot of things are hard-coded, there is a lot of macro abuse and many problems are solved "in-place" with little structure on a higher level. Basically, when you write a compiler for a programming language and want to have it clean and extensible, you'll probably want to generate an
AST. Asar doesn't do that, but instead basically just reads line by line from the source file, then splits that line into words and does some stuff, depending on what words it found in that line. This works fair enough, but has its limitis and is bound to get confusing sooner or later. It's also difficult to extend. Asar's main code generator, for example, is basically just a giant if/elseif block with all functionality hardcoded there, so if you want to add functionality to Asar, you basically have to hijack this enormous construct (which I had to do for adding while loops). Some code is also "all over the place", making it a bit difficult to find what you're looking for.
As much as object orientation is overused nowadays and used in a lot of wrong places, I think a parser & compiler is actually one of the things that could actually benefit from it when used correctly and could make your code a lot more maintainable and extensible (although technically, that doesn't even necessarily require objects per se, what reallys matters is just having a clear and structures hierarchy of things that's easy to extend).
Those are basically the impressions I've got so far, but then again, I may just not be used to this kind of code, since the code I encounter at work is usually very different, which makes sense, considering I enqounter game code most of the time and only rarely code for tools.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!