From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id QAA13905; Fri, 13 Aug 2004 16:03:11 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id QAA14229 for ; Fri, 13 Aug 2004 16:03:10 +0200 (MET DST) Received: from plato.rocketdogcreative.com (plato.rocketdogcreative.com [66.139.78.99]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i7DE38RM031371 for ; Fri, 13 Aug 2004 16:03:09 +0200 Received: from [10.0.1.3] (65-103-213-184.tcsn.qwest.net [65.103.213.184]) by plato.rocketdogcreative.com (8.11.6/8.11.6) with ESMTP id i7DE38111689 for ; Fri, 13 Aug 2004 07:03:08 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: caml-list@inria.fr From: David McClain Subject: [Caml-list] CFG's and OCaml Date: Fri, 13 Aug 2004 07:04:01 -0700 X-Mailer: Apple Mail (2.619) X-Miltered: at concorde with ID 411CCA1C.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; mcclain:01 mcclain:01 expr:01 expr:01 reductions:01 aborts:01 compiler:01 ocaml:01 ocaml:01 int:01 int:01 float:02 float:02 assign:03 anyway:05 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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