Closed awilkins closed 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
.
Would diagnostics warning of Mainframe vs Unix compatibility issues be welcomed?
Missed that. That could be a good idea and helpful if you migrate from mainframe to unix. Might also have to go behind a flag.
Closing as the question has been answered
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?