caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Marc Pantel <Marc.Pantel@enseeiht.fr>
To: Daniel de Rauglaudre <daniel.de_rauglaudre@inria.fr>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Overlapping features of variant types and tuples in Ocaml
Date: 17 May 2002 10:17:15 +0200	[thread overview]
Message-ID: <1021623436.1268.29.camel@pegase> (raw)
In-Reply-To: <20020516211727.C2924@verdot.inria.fr>

Hi,

My purpose is not to start another flame war... I only want to give a 
point of view shared by many at work. And support the interesting work
done with CaMLP4.


> This is resolved by fixing the syntax of OCaml. But improving the
> syntax is supposed to be a loss of time by a lot of people.

Improving the syntax is certainly not a loss of time when the syntax is
EXTREMELY ambiguous... We are using CaML as the initial language in our
programming courses at our computer science engineering school ENSEEIHT
and students lose a lot of time introducing parenthesis en order to lift
the ambiguities in many constructs. 


As far as I know, the main use of CaML in France is teaching. Therefore,
improving its syntax is EXTREMELY important.

Also, if we want CaML to be used in Quality-certified industrial
context, we would be much more convincing with a less ambiguous syntax.

However, if the sole purpose of CaML is to develop research software,
I've been using it for years and I do not fall any more in the
ambiguities, therefore let's keep it this way.

If we want to develop its use in other contexts, let's improve its
syntax a bit in order to throw away ambiguities...


I also happen to teach compiler courses (therefore grammar design)...
One of the point we stress is non-ambiguous grammar. We've got a small
experience in purpose specific language design and we are now convinced
that LL(k) constraints ensures easy to read and to write programs...
Even, if the grammars are more complicated. We think that a language
should have a LL(k) grammar event if we use LR(k) tools that allows
left-recursive grammars.


No flame, please. However, all critics are welcomed.

Sorry for the poor english...

Let's not lose too much energy fighting over each others work...
Everything is interesting if it eases the use of CaML in other contexts.

Marc Pantel,
Associate-Professor in Computer Science,
ENSEEIHT, TOULOUSE, FRANCE
-------------------
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:[~2002-05-17 10:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-16 17:04 Vesa Karvonen
2002-05-16 19:17 ` Daniel de Rauglaudre
2002-05-17  8:17   ` Marc Pantel [this message]
2002-05-16 19:45 Vesa Karvonen
2002-05-16 19:57 ` Daniel de Rauglaudre
2002-05-17 11:40   ` Luc Maranget
2002-05-16 22:02 Vesa Karvonen

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=1021623436.1268.29.camel@pegase \
    --to=marc.pantel@enseeiht.fr \
    --cc=caml-list@inria.fr \
    --cc=daniel.de_rauglaudre@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).