From: David McClain <David.McClain@Avisere.com>
To: caml-list@inria.fr
Subject: [Caml-list] CFG's and OCaml
Date: Fri, 13 Aug 2004 07:04:01 -0700 [thread overview]
Message-ID: <A0DA8CB8-ED31-11D8-99DF-000A95C19BAA@Avisere.com> (raw)
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
next reply other threads:[~2004-08-13 14:03 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-13 14:04 David McClain [this message]
2004-08-13 15:05 ` Damien Doligez
2004-08-13 15:26 ` David McClain
2004-08-13 16:12 ` Damien Doligez
2004-08-13 15:28 ` David McClain
2004-08-13 15:49 ` Brian Hurt
2004-08-13 16:04 ` David McClain
2004-08-13 16:29 ` Brian Hurt
2004-08-13 16:42 ` Xavier Leroy
2004-08-13 17:18 ` Ken Rose
2004-08-13 18:55 ` Brian Hurt
2004-08-14 0:25 ` Jon Harrop
2004-08-14 0:57 ` Erik de Castro Lopo
2004-08-14 8:52 ` Alan Schmitt
2004-08-14 3:33 ` Brian Hurt
2004-08-14 7:55 ` skaller
2004-08-14 20:19 ` Jon Harrop
2004-08-14 20:55 ` Brian Hurt
2004-08-14 20:57 ` Marcin 'Qrczak' Kowalczyk
2004-08-14 22:15 ` skaller
2004-08-15 1:26 ` Jon Harrop
2004-08-15 8:24 ` skaller
2004-08-15 15:39 ` Brian Hurt
2004-08-15 16:54 ` Jon Harrop
2004-08-14 22:13 ` skaller
2004-08-13 16:58 ` Paul Snively
-- strict thread matches above, loose matches on Subject: below --
2004-08-12 19:15 David McClain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=A0DA8CB8-ED31-11D8-99DF-000A95C19BAA@Avisere.com \
--to=david.mcclain@avisere.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).