stray commas in grammar.y ?
Jason Quinn wrote on Dec 01, 2012
For giggles I started playing around with the grammar.y file in pkg/vocl.
If you compile with bison, you get
Under my (inexperienced) understanding of yacc and bison, these commas shouldn't be there.
If you compile with bison, you get
bison grammar.y
grammar.y:125.15: warning: stray `,' treated as white space
grammar.y:125.22: warning: stray `,' treated as white space
grammar.y:125.30: warning: stray `,' treated as white space
grammar.y:125.40: warning: stray `,' treated as white space
grammar.y:125.48: warning: stray `,' treated as white space
grammar.y:126.15: warning: stray `,' treated as white space
grammar.y:126.24: warning: stray `,' treated as white space
grammar.y:126.32: warning: stray `,' treated as white space
grammar.y:127.16: warning: stray `,' treated as white space
grammar.y:127.27: warning: stray `,' treated as white space
grammar.y: conflicts: 10 shift/reduceUnder my (inexperienced) understanding of yacc and bison, these commas shouldn't be there.
Mike Fitzpatrick wrote on Dec 01, 2012
Hi Jason,
Sharp-eyed as always, fixed for the next release. I guess yacc was a bit more forgiving.
Cheers,
-Mike
Sharp-eyed as always, fixed for the next release. I guess yacc was a bit more forgiving.
Cheers,
-Mike
Jason Quinn wrote on Dec 01, 2012
In grammar.y, there's a handful of non-terminal symbols that are written with uppercase. These are:
EOST, DELIM, BARG, EARG, LP, RP, NL
I would replace all instances of these with lowercase because conventionally, uppercase is reserved for tokens, and lowercase for non-terminals, even when the rule is functioning as a "pseudo-token". This makes the grammar much easier to read.
The DELIM rule is only functioning to detect a comma. Instead of just converting to lowercase, I would replace all instances of DELIM with ',' and delete the rule. This eliminates one state from the state machine while also giving another readability boost.
Jason
PS I'm slowly learning and digesting IRAF's lexer and parser. I've already discovered a few things. One is that IRAF has a "concat-equal" operator ("//=") that I never knew about. I have yet to get this to work. I've been trying things like
Here I'd expect mystring to be equal to "walking". Instead a syntax error is thrown. What's an example of the concat-equal usage?
EOST, DELIM, BARG, EARG, LP, RP, NL
I would replace all instances of these with lowercase because conventionally, uppercase is reserved for tokens, and lowercase for non-terminals, even when the rule is functioning as a "pseudo-token". This makes the grammar much easier to read.
The DELIM rule is only functioning to detect a comma. Instead of just converting to lowercase, I would replace all instances of DELIM with ',' and delete the rule. This eliminates one state from the state machine while also giving another readability boost.
Jason
PS I'm slowly learning and digesting IRAF's lexer and parser. I've already discovered a few things. One is that IRAF has a "concat-equal" operator ("//=") that I never knew about. I have yet to get this to work. I've been trying things like
string mystring="walk"
mystring//="ing"
Here I'd expect mystring to be equal to "walking". Instead a syntax error is thrown. What's an example of the concat-equal usage?
Mike Fitzpatrick wrote on Dec 01, 2012
Hi Jason,
I agree the upper-case terminals are unconventional but the code pre-dates me so I can't explain why it was done that way.
The good news is that there are major changes planned for the CL language next year (i.e. 'subroutines', user-defined functions, parallelized execution and an 'image' operator) that will include clean-up of all the known 'quirks' (e.g. the array operators and if-else ambiguities) so I'll just add this to the list of known issues.
As for the concatenation operator: I'm not sure at what release it broke, or if it ever actually worked. One known CL 'quirk' people have come to use is that a simple "+=' operation on strings does the same thing, so maybe it was just an unused feature nobody knew about? In any case, I'll fix it.
-Mike
I agree the upper-case terminals are unconventional but the code pre-dates me so I can't explain why it was done that way.
The good news is that there are major changes planned for the CL language next year (i.e. 'subroutines', user-defined functions, parallelized execution and an 'image' operator) that will include clean-up of all the known 'quirks' (e.g. the array operators and if-else ambiguities) so I'll just add this to the list of known issues.
As for the concatenation operator: I'm not sure at what release it broke, or if it ever actually worked. One known CL 'quirk' people have come to use is that a simple "+=' operation on strings does the same thing, so maybe it was just an unused feature nobody knew about? In any case, I'll fix it.
-Mike
Last post on Dec 01, 2012