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

[Yaron Minsky]

I very much agree with Alain on this.  Having a simple core seems
essential, from a number of viewpoints.  Implementation complexity
alone seems to demand it.

Moreover, I would argue that we should move past the question of
whether to build a simpler thing, and focus more on what that simple
thing should look like.  Once we have a clearer idea about that, we
can circle back and make sure we think like the end result is good
enough to justify the change.

y

On Fri, Jan 25, 2013 at 12:26 PM, Alain Frisch <alain at frisch.fr> wrote:
> 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
>
>
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4