Quote:
Originally Posted by Potato Uno
Yes, all of that is correct, but that doesn't justify why the devs should break old syntax support. It's not like parsing old syntax is the barrier to having new amazing features. And even if it is, they can split spcomp to 2 and have one of them be incompatible with old syntax and the other one be fully compatible with an old and new syntax mix. That would still make both sides happy. (In fact, BAILOPAN said this might be a thing, but he doesn't know.)
I think the JIT implementation of new features is what is slowing them down more but I don't know; I'm only speculating here. I don't have a strong background on compiler or interpreter theory.
|
compilers typically have structures like the
lexer/parser which takes in string/char input and scans it for tokens like "+=" for self-addition and stuff, the AST (abstract syntax tree) Generator which organizes the data given from the lexer/parser to setup grammar into nodes, and the code generator which processes the AST Nodes into the target code whether it's bytecode, assembly, or straight up machine code.
SourcePawn uses a recursive descent parser which basically scans the source file from top to bottom and processes it token by token until the end of the source file. I know this because I looked at the original compuphase pawn compiler and of course Bailopan told me lol.
They CAN split up spcomp into separate dialects but for all I know, 1.7+ spcomp will be the one getting all the updates and bugfixes compared to 1.6 spcomp.
Eventually, everybody will drop 1.6 spcomp in favor of 1.7+ spcomp. I think you misunderstand that I'm not asking for SM devs to intentionally break compatibility but I'm advocating for everybody to modify their currently supported plugins into 1.7+ syntax
__________________