Okay... here's a case where when I do "exactly" what the gurus at Inria 
do, I get a reduce/reduce conflict, and yet when I build OCaml it does 
not report any such conflicts. [I say "exactly" because obviously I'm 
not...]

simple_expr:
	constant
	...

simple_pattern:
	signed_constant
	...

constant:
	INT
| 	FLOAT

signed_constant:
	constant
|	MINUS INT
|	MINUS FLOAT
  ;; /*  ---------------------------------------------------------- */

The reduce/reduce conflict comes on deciding whether to assign an INT 
seen to signed_constant which will reduce to simple_pattern, or instead 
to become constant which reduces to simple_expr. Both Inria and I do 
completely different semantic reductions in these two cases, and so a 
reduce/reduce conflict could be fatal here...

[ I found many instances of my own reduce/reduce conflicts arising from 
error trapping clauses with things like missing RPAREN's etc. Both 
pattern and expressions had these error traps, and so it was simple to 
remove the reduce/reduce conflict by eliding a trap from one or the 
other of these two places. That's pretty harmless since the compiler 
aborts there anyway and it makes no difference which reduction is 
chosen.

But the last few reduce/reduce conflicts are like the one shown above 
and they do matter.]

So, as so often happens with the master's touch, everything works fine 
for them, but it doesn't for me. Why should this be, in this example 
case?


David McClain
Senior Corporate Scientist
Avisere, Inc.

david.mcclain@avisere.com
+1.520.390.7738 (USA)

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners