|Reduce/Reduce conflict in Algol60 grammar email@example.com (Leonardo Teixeira Passos) (2006-10-10)|
|Re: Reduce/Reduce conflict in Algol60 grammar firstname.lastname@example.org (Andru Luvisi) (2006-10-11)|
|Re: Reduce/Reduce conflict in Algol60 grammar email@example.com (firstname.lastname@example.org) (2006-10-11)|
|Re: Reduce/Reduce conflict in Algol60 grammar email@example.com (SM Ryan) (2006-10-11)|
|Re: Reduce/Reduce conflict in Algol60 grammar cfc@shell01.TheWorld.com (Chris F Clark) (2006-10-12)|
|Re: Reduce/Reduce conflict in Algol60 grammar firstname.lastname@example.org (SM Ryan) (2006-10-13)|
|Re: Reduce/Reduce conflict in Algol60 grammar email@example.com (Ken Rose) (2006-10-14)|
|Re: Reduce/Reduce conflict in Algol60 grammar bobduff@shell01.TheWorld.com (Robert A Duff) (2006-10-14)|
|[2 later articles]|
|From:||Andru Luvisi <firstname.lastname@example.org>|
|Date:||11 Oct 2006 23:21:33 -0400|
|Posted-Date:||11 Oct 2006 23:21:33 EDT|
>>>>> "Leonardo" == Leonardo Teixeira Passos <email@example.com> writes:
Leonardo> Note the common part between primary and
Leonardo> boolean_primary, which leads to the conflict. The only
Leonardo> way that I could resolve this was to merge
Leonardo> arithmetic_expression and boolean_expression, respecting
Leonardo> the precedence estabelished, and then distinguish them
Leonardo> through semantic actions.
I seem to recall that this was the standard solution in the 1960s. The
trouble is that it makes perfect sense for numbers and arithmetic
operators to be in a boolean expression.
For example, consider "i + 3*j > 100". You can't tell that it might
be a boolean expression until you get to the ">".
If you're really interested, you could check out "Computing: A Human
Activity" by Peter Naur, "Algol 60 Implementation" by Randell and
Russell, and "Programming Systems and Languages" edited by Rosen.
Also, Dijkstra wrote a couple of interesting papers on Algol 60
The Naur book contains some papers that go into detail about the type
checking. The compiler described didn't build syntax trees. It did
"pseudo evaluation" where at compile time it would perform all of the
operations using a stack, but instead of actual values, all that was
stuck on the stack was type identifiers. An expression could be
"pseudo evaluated" and if at any point an operator was applied while
invalid types were on the stack, it was a type error. Also, the final
type of the expression could be determined by looking at the last type
left on the stack when the pseudo evaluation was finished.
Best of luck,
Return to the
Search the comp.compilers archives again.