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] Ocaml compiler features
Date: Mon, 15 Jan 2007 16:56:07 +1100	[thread overview]
Message-ID: <1168840567.20477.49.camel@rosella.wigram> (raw)
In-Reply-To: <200701142049.57959.jon@ffconsultancy.com>

On Sun, 2007-01-14 at 20:49 +0000, Jon Harrop wrote:

> > I think camlp4 is the not the proper way to extends the language, and is
> > definitevely *NOT* going to improve the world of OCaml.
> 
> Camlp4 may be the best we have. I can't wait to see the next generation...
> 
> Playing with Haskell and F# has opened my eyes a bit. F#'s operator 
> overloading and active patterns will make my code much nicer. 

Felix has 'user defined syntax' which includes infix operators,
outfix operators (brackets), and arbitrary statements. Arbitrary
extensions to expressions aren't supported yet.

However the system isn't really as good as Camlp4: if user
grammar productions are overloaded, then because the system
uses recursive descent parsing error handling is weak
(an unoverloaded production is handled as a special case,
so left factoring is recommended). Caml p4 allows almost arbitrary
intervention in the grammar, and the action rules are arbitrary
Ocaml -- felix only allows syntax macros (which are Turing complete
but macros just don't cut it compared to explicit code generation 
for complex cases).

Of course, Felix has function overloading (which subsumes
operator overloading).

I'm curious what active patterns are. Is that using RTTI to
decode expressions at run time? Like a strong form of
C++ 'dynamic cast'? (or, an extension of variant decoding,
which after all is also using a variant tag for run time
decoding).

BTW: the *major* problem with all code generators is error handling.
It's very easy to add 'sugar' to a language in the form of rewrite
rules .. it is much harder to handle errors, because they might
occur either in the desugaring OR in subsequent processing 
(eg type checking). Since the subsequent processing uses the
desugared form of the code, it is hard to refer properly
to the location of the error.

Mind you .. HM type inference has this problem too.


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


  parent reply	other threads:[~2007-01-15  5:56 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-13  5:37 Edgar Friendly
2007-01-13  5:56 ` [Caml-list] " Tom
2007-01-14 17:35   ` Edgar Friendly
2007-01-14 17:59     ` ketty
2007-01-14 18:21       ` Edgar Friendly
2007-01-14 18:29         ` Jon Harrop
2007-01-13  7:41 ` David Baelde
2007-01-13  9:31   ` ketty
2007-01-14 17:33   ` Edgar Friendly
2007-01-14 18:23     ` Jon Harrop
2007-01-14 18:41       ` Vincent Hanquez
2007-01-14 20:49         ` Jon Harrop
2007-01-14 23:38           ` Gabriel Kerneis
2007-01-15  0:55             ` Jon Harrop
2007-01-15  6:12               ` skaller
2007-01-15  0:05           ` Vincent Hanquez
2007-01-15  5:59             ` skaller
2007-01-15 20:23             ` Martin Jambon
2007-01-15 21:30               ` Jon Harrop
2007-01-15 22:13                 ` Try finally (was Re: [Caml-list] Ocaml compiler features) Daniel Bünzli
2007-01-15 22:27                   ` Vincent Hanquez
2007-01-15 22:40                     ` Quôc Peyrot
2007-01-15 23:08                       ` Vincent Hanquez
2007-01-15 22:17               ` [Caml-list] Ocaml compiler features Vincent Hanquez
2007-01-16  1:18                 ` skaller
2007-01-16  2:11                   ` Jon Harrop
2007-01-16  5:18                     ` Edgar Friendly
2007-01-16  6:36                       ` skaller
2007-01-16  6:33                     ` skaller
2007-01-16 13:55                     ` Brian Hurt
2007-01-16  9:00                   ` Vincent Hanquez
2007-01-16 14:14                     ` skaller
2007-01-16 15:00                       ` Vincent Hanquez
2007-01-16 17:47                         ` skaller
2007-01-16 19:24                           ` Edgar Friendly
2007-01-17  3:28                             ` skaller
2007-01-17 11:41                               ` Vincent Hanquez
2007-01-17 12:53                                 ` Olivier Andrieu
2007-01-17 13:18                                   ` Vincent Hanquez
2007-01-17 14:09                                 ` skaller
2007-01-16 19:42                           ` Jon Harrop
2007-01-16 21:15                             ` Florian Weimer
2007-01-17  3:46                             ` skaller
2007-01-17 11:50                               ` Vincent Hanquez
2007-01-15  5:56           ` skaller [this message]
2007-01-15  9:35         ` Nicolas Pouillard
2007-01-15 18:28           ` Martin Jambon
2007-01-15 19:02             ` ls-ocaml-developer-2006
2007-01-14 19:01       ` Edgar Friendly
2007-01-14 18:51     ` Vincent Hanquez
2007-01-14 20:49       ` Jon Harrop
2007-01-15  0:19         ` Vincent Hanquez
2007-01-20 19:19           ` Jon Harrop
2007-01-20 21:40             ` skaller
2007-01-14 21:47     ` Tom
2007-01-15 10:36 ` Richard Jones
2007-01-15 14:24   ` Vincent Hanquez
2007-01-16  8:45     ` Hendrik Tews
2007-01-16  9:08       ` Vincent Hanquez
2007-01-21 17:07         ` [Caml-list] native-code stack backtraces (was: Ocaml compiler features) Xavier Leroy
2007-01-21 18:53           ` Pierre Etchemaïté
2007-01-16  5:21   ` [Caml-list] Ocaml compiler features Edgar Friendly
2007-01-16  5:33     ` ketty
2007-01-16  6:00       ` Edgar Friendly
2007-01-16  6:10         ` ketty
2007-01-16  5:55     ` Christophe TROESTLER
2007-01-16 17:51       ` Edgar Friendly
2007-01-16 19:09         ` Jon Harrop
2007-01-16 19:21         ` Brian Hurt
2007-01-16 20:06         ` Jonathan Roewen
2007-01-16 20:13         ` Florian Weimer
2007-01-16  6:51     ` skaller
2007-01-16 18:01       ` Edgar Friendly
2007-01-17  2:23         ` skaller
2007-01-16  8:00   ` Florian Hars

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=1168840567.20477.49.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).