Version française
Home     About     Download     Resources     Contact us    
Browse thread
If OCaml were a car
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Joerg van den Hoff <j.van_den_hoff@f...>
Subject: Re: [Caml-list] If OCaml were a car
On Mon, Aug 20, 2007 at 04:26:24PM +1000, skaller wrote:
> 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).

as a ocaml novice I probably would'nt have mailed to this list any time
soon and I'm afraid this goes off at a tangent, but anyway: I won't
argue against your (probably not so well founded?) assessment of a
'ridiculously clumsy grammar', still what you wrote down as being a
german sentence is not even the equivalent to pidgin english. "a walk
in the black forest" would simply be "ein Spaziergang im Schwarzwald"
with a nearly one-to-one correspondence of the words. "Walking in the
black forest" would be "im Schwarzwald spazieren gehen", possible
tranlation: "taking a walk in the black forest". to be sure, there
_are_ some grammatical idiosyncrasies (cf. e.g. a rather funny small
polemic written by mark twain, I believe) -- or so it must seem to
non-native speakers. so much in defense of my native language :-).
apologies for this intrusion...

> 
> 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
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs