[wg-camlp4] Feedback to Leo's post from Jake

[Alain Frisch]

On 01/25/2013 05:48 PM, Hongbo Zhang wrote:> Hi Anil,
 >     I am just wondering why not expose a simple API on top of  Camlp4
 > instead of rolling a new mechanism? The advanced users can still have
 > advanced features.

Even if you manage to simplify Camlp4, it will always be a complex 
beast, creating some maintenance overhead for the core team when the 
language evolve or if you need to work with a fork of the language (such 
as MetaOCaml, OCamlDuce, or LexiFi's local version).  As a very concrete 
example, Jacques Garrigue recently proposed a patch (for generative 
functors) which requires a (light) extension to the OCaml syntax.  Of 
course, he did not upgrade Camlp4 (its version of the OCaml AST, its N 
parsers, and the mapping to the regular OCaml AST) yet.  So you cannot 
try this patch on your whole project if it depends on any camlp4-based 
tool.  This is very sad, isn't it?  Projects which rely on -ppx (like 
Bisect, sedlex, omonad) work perfectly ok with Jacques'  patch and 
nobody had to suffer to make this happen.

Why should we build something simple on top of something complicated 
when it is rather easy to build the simple solution directly?  This 
seems much more robust and future proof to me.  Those who enjoy the 
extra complexity (or actually need it) can indeed continue to work on 
and use camlp4/camlp5/fan.  This is not incompatible with -ppx at all. 
But the day ocamlfind, lwt, js_of_ocaml, type_conv and other 
"infrastructure" tools will work without camlp4, I will feel much more 
comfortable relying on them.

Also, I have reasons to believe that -ppx based tools will interact 
nicely with each other, better than camlp4 ones (I think about the
unfortunate incompatibility between deriving and type_conv). I claim 
that camlp4's model of independent extensions being allowed to tweak the 
concrete syntax as they want by mutating grammar rules is a design 
mistake with unfortunate consequences.  I have other technical concerns 
with camlp4 and I will try to summarize them in a blog post, so as to 
keep this mailing list more focused to pushing alternatives to camlp4 
(rather than justifying why this is a good idea to do so).

On 01/25/2013 05:34 PM, Anil Madhavapeddy wrote:
 >  Some extensions (such as bitstring) are very naturally packaged as
 > camlp4 syntax extensions, and not entirely solved by the ppx scheme. 
  > It would be good to understand if this is outside of the scope of
 > ppx, or on the list to solve.


This does not look very different from Sedlex ( 
http://www.lexifi.com/sedlex ), which encodes regular expressions as 
normal patterns.   And adding quotations in pattern position would make 
it possible to use any concrete syntax.


Alain