Browse thread
Ocaml compiler features
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| 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 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