search

linkrope / gamma

Extended Affix Grammar Compiler Generator
Boost Software License 1.0
4 stars 1 forks source link

Added recognition of EOF at LL(1) parsers. #16

Closed kuniss closed 1 year ago

kuniss commented 1 year ago

Made the old behavior for Oberon2 which allows arbitrary trailing content before EOF optional and the new behavior the default. The option of allowing arbitrary content can be enabled by passing the command line option '-t' to the generated compiler. This solves GH issue #11.

kuniss commented 1 year ago

I propose a breaking change without any option for the old behavior.

So, is your proposal to remove the old behavior at all and put the trailing content at the Oberon examples in single line comments?

linkrope commented 1 year ago

I propose a breaking change without any option for the old behavior.

So, is your proposal to remove the old behavior at all and put the trailing content at the Oberon examples in single line comments?

Yes! Because the elegant solution is to add a compiler option, while it should have been a genrator option. I want to generate an Oberon compiler, but then the option is only valid, if I generate an LL parser. A dependent option. Placing the option into the LL parser code avoids this problem, but then you have to select this option for every run of the generated Oberon compiler.

kuniss commented 1 year ago

I propose a breaking change without any option for the old behavior.

So, is your proposal to remove the old behavior at all and put the trailing content at the Oberon examples in single line comments?

Yes! Because the elegant solution is to add a compiler option, while it should have been a genrator option. I want to generate an Oberon compiler, but then the option is only valid, if I generate an LL parser. A dependent option. Placing the option into the LL parser code avoids this problem, but then you have to select this option for every run of the generated Oberon compiler.

Agree!

kuniss commented 1 year ago

The token name "end" tries to abstract from "end of file", "end of text"... Here, we should also consistently say "end" instead of "EOF".

I improved the naming and the error message. :smile: But I found it better to reference both "end of file" and "end of text" in the error message with a preference to "end of file" as this will normally happen, right?

linkrope commented 1 year ago

But I found it better to reference both "end of file" and "end of text" in the error message with a preference to "end of file" as this will normally happen, right?

OK. I would just have said "unexpected content at the end".