English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    
Browse thread
[Caml-list] Generating C stubs
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Markus Mottl <markus@o...>
Subject: Re: [Caml-list] Camlp4/OCaml [was: Generating C stubs]
Dear Pierre,

On Fri, 17 May 2002, Pierre Weis wrote:
> Hence, (to me) there is no question about the fact that semantics (hence
> syntax) is of primordial importance. So that we have to improve the
> syntax of the language if we can. But we cannot say that the regular
> syntax is EXTREMELY ambiguous (with upper case letters and the like). Be
> quite, please! It is not ambiguous. You need some parens sometimes as
> in math, and math is not known to be that ambiguous.

I am not sure whether you, as one of the language designers, felt offended
by my use of an _emphasis_. If yes, it seems to be a misunderstanding,
because I just wanted to point out the fact that "there _are_ problems"
rather than that there was anything extremely ambiguous about OCaml, which
would certainly be unjustified criticism. The problems are comparatively
minor, but they do exist and therefore shouldn't be brushed under the
carpet but (IMHO) solved at some point in the future. That's all I wanted
to say.

> Considering the difficulties of apprentices, some pedagogical theories
> of mathematics once proposed to adopt completely unambiguous (read
> absolutely redundant if you want) notations or encodings for algebraic
> expressions in mathematics (reverse polish or lisp like parentheses
> for operators). This was a complete failure. It happens to be not only
> less readable than the usual notation but even much more difficult to
> teach, use, and learn!

I wouldn't say that e.g. RPN were "absolutely redundant". In fact, I
think the reason why it wasn't so successful is exactly because it isn't
redundant: humans just need some redundant syntactic hints to parse
texts more efficiently. In the case of RPN it is actually impossible
to interpret or correctly modify only a part of an expression without
having parsed it from the beginning. This makes both understanding and
editing very difficult.

Just to give an example, I like the fact that the following is
syntactically redundant in OCaml:

  let f = function X -> () | Y -> ()

and

  let f = function | X -> () | Y -> ()

This way I can more easily choose whether I want to put the whole code in
one line or each match in a separate one. Without allowing a preceding
"|" in the first line of a match it would be annoying to add matches at
the beginning or move the first one elsewhere.

OTOH, I really dislike the lack of distinction between constructors with
tuple arguments and several arguments (as Brian has also mentioned).

Or the following irregularity:

  try ()
  with Exit -> print_string "Hello "; print_endline "world!";
  print_endline "DONE"

and

  if false then print_string "Hello "; print_endline "world!";
  print_endline "DONE"

The catch here is that users can accidently write suggestive code,
which makes people believe that "DONE" will be printed in any case as
in the "try/with"-example or that "world!" would be printed only if the
condition were true in the "if/then/else" example.

A simple-minded fix does not resolve all problems:

  try ()
  with Exit -> (print_string "Hello "; print_endline "world!");
  print_endline "DONE"

This will still not print "DONE"! But here the behaviour changes:

  if false then (print_string "Hello "; print_endline "world!");
  print_endline "DONE"

I think this is just confusing. IMHO, "try/with" and "if/then/else" should
really syntactically force users to explicitly express what they mean. To
prevent myself from falling into such traps I have adopted the strategy
to never use ";" in code parts that are executed conditionally: I use
"let _ = ... in" instead, which doesn't look particularly beautiful, but
which I can still parse successfully even when being in brain-dead mode.

The upper case is particularly bad, because the compiler cannot help you.
But there are similar ones that are annoying, but are at least caught
at compile time, e.g.:

  match v1 with
  | A ->
      match v2 with
      | X -> ()
      | Y -> ()
  | B -> ()

Then there is this question of when to use ";;", which all beginners
wonder about...

> In any way, claiming the Caml syntax is this or that is just useless
> and a waste of time. More interesting is to state problems that have
> to be solved and axioms (or rules) you want to respect.

People are certainly willing to discuss details of syntactic aspects
they find confusing. AFAIK, it's almost always the same kind of problems.

> That's what is interesting in the revised syntax. Believe it or not,
> I am glad to see that it elegantly realizes some of those rules I
> definitely would like to have in the syntax of the language; on the
> other hand it consistantly violate other of my personal axioms about
> the syntaxes I like. It is truly difficult to design a good syntax!

I certainly agree that designing a good syntax is quite challeninging.
Another reason why we should think about it - who doesn't like being
challenged :-)

> So, what I am interested in is to set up a list of rules to guide the
> design of a syntax. This is hard, but interesting and could lead to a
> syntax easy to learn and use. This would be constructive and new.

What I consider at least as important is how to introduce syntactic
changes into a language without driving users mad.  This gets us back
to the topic of having camlp4 in the distribution or not. I think that
irrespective of the syntactic rules the community can finally agree on,
a tool like camlp4 would be very welcome to support a transition.

Best regards,
Markus Mottl

-- 
Markus Mottl                                             markus@oefai.at
Austrian Research Institute
for Artificial Intelligence                  http://www.oefai.at/~markus
-------------------
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