Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Ocaml compiler features
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2007-01-15 (05:56)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] Ocaml compiler features
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

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++: