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 SAA20115; Fri, 13 Aug 2004 18:03:38 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA16586 for ; Fri, 13 Aug 2004 18:03:37 +0200 (MET DST) Received: from plato.rocketdogcreative.com (plato.rocketdogcreative.com [66.139.78.99]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i7DG3ZmL000580 for ; Fri, 13 Aug 2004 18:03:36 +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 i7DG3Z114377; Fri, 13 Aug 2004 09:03:35 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73EC7D25-ED42-11D8-99DF-000A95C19BAA@Avisere.com> Content-Transfer-Encoding: 7bit From: David McClain Subject: Re: [Caml-list] CFG's and OCaml Date: Fri, 13 Aug 2004 09:04:27 -0700 To: Brian Hurt , caml-list@inria.fr X-Mailer: Apple Mail (2.619) X-Miltered: at nez-perce with ID 411CE657.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 caml-list:01 non-obvious:01 lalr:01 mixes:01 subtrees:01 reductions:01 expr:01 expr:01 reductions:01 compiler:01 ocaml:01 ocaml:01 int:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Uhuhh... Yes, I did that same "evil" thing as well, even before discussing all these reduce/reduce conflicts/ What I find is that these screwball little tricks might help, and the might not. YACC is just too darned sensitive to minor and non-obvious perturbations in the input grammar specification. Realizing its legacy, indeed it does arise from the old IBM-360, or more properly PDP-10, days. That was the style of programming back then.. I remember it well. I see that the root of the problem really lies in the reducion from LL(1) to LALR(1) where driver table entries are shared as much as possible to diminish the size of these tables. However, when that occurs, we end up getting mixes like we have between the distinct expression and pattern subtrees in the grammar. Indeed these do appear syntactically similar, yet by way of specification, we are hoping to apply completely different semantic actions to these reductions. This is a dilemma. I had though the other night about creating a common subtree of semantic actions and then let the higher levels unravel that subtree. That would probably work well here, but it is a lot more work. David McClain Senior Corporate Scientist Avisere, Inc. david.mcclain@avisere.com +1.520.390.7738 (USA) On Aug 13, 2004, at 08:49, Brian Hurt wrote: > On Fri, 13 Aug 2004, David McClain wrote: > >> 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... > > When the compiler sees an int, which path should it take? > > My advice would be to remove the constant from signed_constant's > patterns. > > >> 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? > > They're doing something evil- take a look at line 355 of > parsing/parser.mly in 3.08.0. > > -- > "Usenet is like a herd of performing elephants with diarrhea -- > massive, > difficult to redirect, awe-inspiring, entertaining, and a source of > mind-boggling amounts of excrement when you least expect it." > - Gene Spafford > Brian > ------------------- 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