caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: skaller <skaller@users.sourceforge.net>
To: Jon Harrop <jon@ffconsultancy.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] If OCaml were a car
Date: Mon, 20 Aug 2007 16:26:24 +1000	[thread overview]
Message-ID: <1187591184.6295.36.camel@rosella.wigram> (raw)
In-Reply-To: <200708200437.59877.jon@ffconsultancy.com>

On Mon, 2007-08-20 at 04:37 +0100, Jon Harrop wrote:

> >
> > The thing is that 'else' has a different 'precedence' than 'then'.
> > So you can write:
> >
> > 	if e then e1 else a; b; c
> >
> > and a,b,c are all executed if the condition is false,
> 
> I do not believe this is true. The "b" and "c" are executed in both cases 
> because the above is parsed as:
> 
>   (if e then e1 else a); b; c
> 
> which is syntactically uniform:
> 
> # (<:expr< (if true then a else a);b;c >>) =
>   (<:expr< if true then a else a;b;c >>);;
> - : bool = true
> 
> Perhaps you were thinking of this:
> 
>   if p then t else
>     let () = () in
>     f1;
>     f2;
>     f3
> 
> because "let" binds more tightly.

Well there you go! I've been writing Ocaml almost 10 years and 
didn't know that. Here's my real code:

    if ret = `BTYP_tuple [] then "// elided (returns unit)\n","" else
    let funtype = fold syms.dfns (`BTYP_function (argtype, ret)) in

I guess I'm just lucky. From what you say, the grammar is exceptionally
bad: the scope of the 'else' is *extended* by the let/in non-terminal
so it goes past ';' -- that should be a syntax error. 

Roughly a 'loosely' binding operator is extending the scope 
of a 'tightly' binding operator: doing that is fragile. For example
if I drop the 'let .. in' part the semantics may** change silently.

The 'right' way to extend a scope is to use an scope extension 
operator with no semantics, such as ( .. ) or begin .. end,
or $ in Felix in Haskell.

But please note: just because I present this analysis doesn't mean
I believe it 100%. Contrarily .. it is just a data point. It has
to be weighted against other factors: every syntactic form has
both advantages and disadvantages, and it is very dependent
on the client's prior experience. ***

German, for example, has the ridiculously clumsy grammar of
putting the verb at the end and concatenating adjectives onto
nouns: "Ein Schwartz-Wald-Spatzieren-Gehen" = "A Walk in
the Black Forest" .. literally "A Black Forest Walk Going"
(FYI: a famous jazz number from the '60s).

I'd probably fall over laughing at how stupid French is :)

Except .. I happen to know English is the most absurd language
around. It just happens to be my native language so I'm used 
to it.

** it's likely I'll get a type error and become very confused,
but that is much better than not getting a type error, which is
quite possible if everything is returning unit.

*** when I designed Felix I made a decision that the grammar
had to be LALR1 and entirely unambiguous, a choice easily
enforced by using Ocamlyacc (without any %prec rubbish,
and by grepping the .output to make sure there were
no shift/reduce conflicts).

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net


  reply	other threads:[~2007-08-20  6:26 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-18 19:21 Richard Jones
2007-08-18 20:24 ` [Caml-list] " Jeff Meister
2007-08-18 21:32   ` Michael Vanier
2007-08-19 11:50     ` Daniel Bünzli
2007-08-19 11:59       ` Erik de Castro Lopo
2007-08-22  5:50         ` Luca de Alfaro
2007-08-22  8:13           ` Jon Harrop
2007-08-22  9:20             ` Jacques Garrigue
2007-08-24  2:54           ` Nathaniel Gray
2007-08-25 19:45             ` Oliver Bandel
2007-08-19 14:43       ` John Carr
2007-08-19 16:22         ` brogoff
2007-08-19 17:07         ` Richard Jones
2007-08-19 17:19           ` Stefano Zacchiroli
2007-08-22  6:04             ` Luca de Alfaro
2007-08-19 20:51           ` Vincent Hanquez
2007-08-21  8:05           ` David Allsopp
2007-08-21 18:33             ` Richard Jones
2007-08-19 20:30         ` Tom
2007-08-19 21:45           ` skaller
2007-08-20  3:37             ` Jon Harrop
2007-08-20  6:26               ` skaller [this message]
2007-08-20 10:00                 ` Joerg van den Hoff
2007-08-21 12:03                   ` Florian Hars
2007-08-20  6:54               ` skaller
2007-08-20 19:54       ` Oliver Bandel
2007-08-20 20:27         ` David Allsopp
2007-08-20 20:50           ` Ulf Wiger (TN/EAB)
2007-08-21 10:56             ` Joerg van den Hoff
2007-08-20 21:13           ` Oliver Bandel
2007-08-21  0:47         ` skaller
2007-08-21  9:51           ` Oliver Bandel
2007-08-21 10:30             ` skaller
2007-08-21 18:57               ` Richard Jones
2007-08-22  2:49                 ` skaller
2007-08-22 11:33                   ` Thomas Fischbacher
2007-08-21 14:46             ` Business Adoption of Ocaml [was Re: [Caml-list] If OCaml were a car] Robert Fischer
2007-08-21 15:09               ` Brian Hurt
2007-08-21 15:48           ` [Caml-list] If OCaml were a car brogoff
2007-08-19 18:15 [caml-list] " Mike Lin

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=1187591184.6295.36.camel@rosella.wigram \
    --to=skaller@users.sourceforge.net \
    --cc=caml-list@yquem.inria.fr \
    --cc=jon@ffconsultancy.com \
    /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).