MarkusAmshove
commented
1 month ago @Claes65 is using Natural on the mainframe while we use it on Linux. We currently don't make any distinctions in the parser, so patches like these are welcome. Some mainframe specific stuff is already supported, as I understand, because Claes is adding it.
Our goal is not to be a compiler, so if the parser is happy with ¬= but the compiler is yelling at us, that's okay.
This might change in the future if there are differences that are bigger, but I can't see that coming around any time soon.
Another example is that we don't care about the parser settings (yet), so 1.5 and 1,5 are both seen as a floating point number, because the settings DecimalCharacter and ThousandSeparatorCharacter from Natural are not known to this project.
In this particular case, we can add support for ¬= and add diagnostics.
Code style diagnostics are gated behind flags in an .editorconfig file, as described here.
natls.style.comparisons with value sign will raise a diagnostic if you write #A EQ #B because it wants it to be #A = #B.
awilkins
I'm working on a reasonably large body (> 1M lines) of mainframe Natural ; there's plenty in here the parser can't currently cope with, like e.g. the deprecated "not equals", but I'd love for your tools to be able to cope with it all because it will make a number of things easier.
¬=^=Is the project open to receiving patches inspired by rather old Mainframe code? Would you want things gated behind mode flags? Would diagnostics warning of Mainframe vs Unix compatibility issues be welcomed?