Maybe Mark tries to create the absolutely perfect language. He started to develop BlitzMax and at the beginning it seemed to become exactly what he expected. However he had to note that the precedence wasn't good enough for his expectations, since (as Vertex noticed) you can't directly do operations on strings returned from Chr. So he changed the precedence. However the new precedence is also not a good solution, so he thinks about doing everything new, from beginning. I think he said that also in another thread: "rewriting the compiler is starting to sound more and more appealing!"
Therefore he now thinks about Max2, where he would solve all the problems he didn't in Max1. However you can be sure that this will result in that he finds also some kinds of inconsistency (some little things, which can't be realized because of the groundwork of the compiler), which also causes him to start again from the beginning and to start with Max3, the story will repeat and he'll do Max4, soon Max5.... and so on. He'll never find a finish, since it is impossible to create the perfect compiler.
However since every Max version then would have different advantages and disadvantages they wouldn't be compatible: code written for Max1 couldn't be compiled with Max2, code for Max2 not for Max3, Max3 not for Max4 and so on. So Mark's wish to design the perfect language will result in a big lack of backward compatibility (which I really advice Mark to care more about).
Therefore I'd like to stop this nightmare at the early beginning, so I really hope Mark doesn't start with Max2.
Or, if we expand this for to all issues about downward compatibility, we could have a "Version x.xx" statement at the first line of source code. If the compiler has this version, it would just compile as normal, if the version of the compiler is less than the source file version, it would produce a compiling error like "Version not supported!", and if the source version is lower than the compiler version (in my case 1.24 compiles 1.20) the compiler switches to a compatibility-mode, which hides the most important changes between the versions.
However the best solution would be a "CompilerSpec" command, which allows you to define which parts of the compiler of which version you want to use. It could look like this:
Therefore he now thinks about Max2, where he would solve all the problems he didn't in Max1. However you can be sure that this will result in that he finds also some kinds of inconsistency (some little things, which can't be realized because of the groundwork of the compiler), which also causes him to start again from the beginning and to start with Max3, the story will repeat and he'll do Max4, soon Max5.... and so on. He'll never find a finish, since it is impossible to create the perfect compiler.
However since every Max version then would have different advantages and disadvantages they wouldn't be compatible: code written for Max1 couldn't be compiled with Max2, code for Max2 not for Max3, Max3 not for Max4 and so on. So Mark's wish to design the perfect language will result in a big lack of backward compatibility (which I really advice Mark to care more about).
Therefore I'd like to stop this nightmare at the early beginning, so I really hope Mark doesn't start with Max2.
In Fabian's case, if he could issue a ?Legacy_Precedence or somthing in his code, then he could have the older precedence he desires without having to stay at an older version of the product.
Yes, this would be a pretty nice solution!Or, if we expand this for to all issues about downward compatibility, we could have a "Version x.xx" statement at the first line of source code. If the compiler has this version, it would just compile as normal, if the version of the compiler is less than the source file version, it would produce a compiling error like "Version not supported!", and if the source version is lower than the compiler version (in my case 1.24 compiles 1.20) the compiler switches to a compatibility-mode, which hides the most important changes between the versions.
However the best solution would be a "CompilerSpec" command, which allows you to define which parts of the compiler of which version you want to use. It could look like this:
CompilerSpec "Types: 1.16" 'Since version 1.18 Object Ptr isn't a valid type CompilerSpec "Precedence: 1.20" 'Since version 1.22 the precedence has changed CompilerSpec "Inheritance: 1.22" 'Since version 1.24 overwriting abstract methods can't differ by type CompilerSpec "Casting: 1.24" 'Cast negative Long to Int fixed since version 1.22 CompilerSpec "Operators: 1.24" 'Everything well here CompilerSpec "Other: 1.24" 'The rest (all unnamed specs) should go like version 1.24However this might be a bit off-topic here...