Re: [Caml-list] Re: Syntax extensions without Camlp4

[Hongbo Zhang <bobzhang1988@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]

On 5/30/12 8:41 AM, Alain Frisch wrote:
Hi Alain,
    Thanks for your message.
    I am building a framework on top of camlp4, which provides those 
features you mentioned in the post in a flexible way. It needs to be 
polished. So far, writing generic plugins is really easy. (generic 
printing, comparison, lift filter, etc , each about 20 lines).
    The conclusion below is based on my observation and experiences. 
Feel free to correct me if I am wrong.

    1. Why camlp4 is buggy?
    The main buggy part is its parsing technology.  So is its parsing 
technology a bad idea? No, it's really convenient for rapid ad-hoc 
prototyping, suppose you don't need write a lexer, and its parser simply 
works in the toplevel, the parser itself it really shorter even compared 
with menhir, if you refactor your parser part.
    The main buggy part lies in camlp4of, which is not tested at all. 
it's easy to test camlp4o, camlp4rf. There's large code base written 
both in camlp4o and camlp4rf. So in my opinion, we should just *drop 
camlp4of*, unless it's really heavily tested. *camlp4rf* is a good 
syntax, in my experience, it just took me one day to get used to, and I 
wrote my daily caml code in revised syntax. It's not hard to learn. It's 
much easier compared with the complexity of camlp4ast or ocamlast. So, 
IMHO, we should just advise camlp4 developers to use revised syntax. It 
would be nice if Daniel would write some articles how internal parser 
mechanism works. Revised syntax just catch up with the trunk, it should 
not be exactly the same, this gives the caml develop team enough freedom 
to introducing new constructs(monad support, etc)

   2. About the proposal.
     There are mainly 2 pieces. About the hook 
Parsetree.structure->Parsetree. structure, given that camlp4 already 
imports Parsetree, it's really trivial to
add another hook after camlp4astdump2ocamlast.
     The other piece about introducing attribute grammar, whcich is 
orthogonal to camlp4, IMHO.
     It's still nontrivial to write a robust Parsetree.structure -> 
Parsetree.structure,  it would be nice if we could provide a quotation 
syntax for Parsetree.types. I would contribute if there was some funding 
support.

  3. Extending the syntax.
     It is really nice to extend your syntax for ad-hoc hacking. Your 
nice software ulex, and bitstring is a good example. It could be even 
better to just introduce a new quotation for robustness.

     But I am against mutating syntax for personal taste. (try finally, 
monad syntax), those improvement should be in the trunk.

Many Thanks
> On 05/27/2012 06:53 PM, Hongbo Zhang wrote:
>> Well, I don't think it's good to downplay camlp4. The problem is we need
>> more documentation and more tests.
>
> (The new) Camlp4 has been here for several years.  Documentation and 
> tests are still lagging behind.  Nevertheless, it burns a 
> non-negligible fraction of the total resource spent by maintainers on 
> OCaml (fixing bugs, struggling with camlp4 to take new language 
> features into account).
>
> In addition, there is a growing consensus that the most common uses of 
> camlp4 (such as code generation driven by type declaration) might be 
> based on a much simpler approach, and this would actually have 
> advantages for the end-users (like not changing the concrete syntax)
> and for developers (much less information to grasp in order to write 
> such an extension).
>
> Coq is one of the few examples of a big project that relies on other 
> aspects of camlp4 (e.g. its parsing framework with extensible 
> grammars).  As far as I know, it also still works with camlp5, which 
> is actively maintained, and I don't believe the Coq guys enjoy so much 
> maintaining support for both camlp4 and campl5.
>
> All that considered, and this is only a personal opinion: I don't see 
> compelling arguments to continue investing efforts in camlp4 itself 
> (at least, for the core OCaml team) and I believe it is a good time to 
> start considering a (medium-term) future of OCaml without camlp4.  Of 
> course, alternative solutions need to be developed and streamlined 
> before killing camlp4 is even considered.
>
>
> Alain


[-- Attachment #2: Type: text/html, Size: 9454 bytes --]