caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Jon Harrop <jon@jdh30.plus.com>
To: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] CFG's and OCaml
Date: Sat, 14 Aug 2004 21:19:10 +0100	[thread overview]
Message-ID: <200408142119.11234.jon@jdh30.plus.com> (raw)
In-Reply-To: <1092470117.29139.582.camel@pelican.wigram>

On Saturday 14 August 2004 04:33, Brian Hurt wrote:
> > 3. If so, is the fact that most languages disallow "a<b<c" due to this?
> 
> No.  "a<b<c" is parsed the same way as "a+b+c".

Sorry, I should have been more specific. With left- or right- or 
non-associative, commuting, 'a->'a->'a operators (like + and *) you can get 
away with parsing that way, e.g. "a+b+c" as:

either  (a+b)+c  or  a+(b+c)

But you can't do this with comparison 'a->'a->bool operators because it forces 
you to deviate from conventional mathematical meaning, e.g. you get a type 
error in OCaml on the "3" in "1<2<3" because it parses as "(1<2)<3" which 
evaluates to "true<3" which just doesn't make any sense.

IMHO, being able to do "1<2<false", although valid in OCaml and many other 
languages, is not terribly useful. Indeed, it can lead to overt 
confusingnesses:

# false=false=false;;
- : bool = false
# false=false=false=false;;
- : bool = true

I thought that the ML family were designed to mimic mathematical notation 
where possible but, AFAIK, most implementations don't do "a<b<c" this way.

I had always assumed that this was a limitation of LALR(1) but, according to 
skaller and Eric, I was wrong.

On Saturday 14 August 2004 08:55, skaller wrote:
> ...
> It is possible to make < a chain operator instead,
> ...

I see. You don't just make (x + y) an expression in the grammar but a whole 
new rule "sum" which contains (x + y) or (x + sum) and has the precendence of 
"+"?

So I want to take all comparison operators "'a -> 'a -> bool" and make a rule 
"inequality" for a (x op1 y) or (x op1 comparison) chain "operator" which, 
say, builds a list of operand and operators? Then you could do "x0 <= x < 
x1". Woohoo!

Would this have to be a conflict in the grammar with "a<b<c" parsed as 
"(a<b)<c"?

> > 4. Could that be added to OCaml? ;-)
>
> Not without breaking existing code...

Right, because somebody somewhere is bound to have done the equivalent of 
"2<5<false" in their OCaml code. But does "2<5<false" have defined behaviour?

> > 5. Is it productive to think in terms of coercing lex and yacc into doing
> > as much of the work as possible
>
> I personally think you should do the opposite -- let lex/yacc
> do the least possible work since they're fairly rigid.
> You may need to fiddle with your grammar to get the language
> you want -- and it is better if that has the minimum
> impact on your semantic logic. IMHO.

But making more use of lex and yacc is good because they detect conflicts or 
ambiguities? Not great in the sense that reduce-reduce conflicts can be a 
nightmare to get rid of though (especially if you don't own the grammar), but 
that's the trade-off.

Cheers,
Jon.

-------------------
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


  reply	other threads:[~2004-08-14 20:22 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-13 14:04 David McClain
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 [this message]
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=200408142119.11234.jon@jdh30.plus.com \
    --to=jon@jdh30.plus.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).