[Caml-list] Re: working %.pp.ml target with ocamfind/ocamlbuild

[bob zhang <bobzhang1988@gmail.com>]

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

Btw, there's something wrong with the rule "%.pp.ml", I don't remember
exactly where it's, for your interest, you can have a look at

https://bitbucket.org/HongboZhang/camlp4/src/e88f431db722/myocamlbuild.ml

ocaml has a really really *high quality* compiler, but all the tools around
it is not that satisfied, contribution is much harder than bug fixes :-(

If you take a look at ICFP 12's paper about Shake, the idea is essentially
the same as 'ocamlbuild', and the idea is cool, but the implementation of
ocamlbuild is fragile and buggy.

On Mon, Sep 10, 2012 at 2:08 PM, Hongbo Zhang <bobzhang1988@gmail.com>wrote:

> Greetings,
> On 9/9/12 6:29 PM, Wojciech Meyer wrote:
>
>> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
>>
>>  This is useful for debugging purposes, and for some (minor) modes of
>>> use of Camlp4. However, for most Camlp4 development, this has the
>>> severe downside of losing the location information of the original
>>> file, if I understand correctly. This means that you don't want to use
>>> it as a transparent step towards compilation, but only in exceptional
>>> situations where the developers will re-edit the output code.
>>>
>>
>> I think I've to say I disagree it's not useful, when I'm developing a
>> syntax extension on top of Camlp4 I really want to see the generated
>> code. Moreover to understand some of the more complicated syntax
>> extensions like type_conv, deriving, FoldGenerator I need to look at the
>> expanded code to understand how to use it - last time I hit the same
>>
> Yes, it's damn useful not only for bootstrapping, but also for developing
> to locate type errors. But there's something wrong with Camlp4's printer,
> it has *4* printers in total, writing a printer for an Ast which has no
> backend is totally useless. In my branch of camlp4, *I removed all those 4
> printers and using tools/pprintast.ml* in ocaml's compiler source
> tree(with some my own bug fixes), and it works very well.
> Btw, are you in ICFP? we could have a talk about Camlp4 :-)
>
>> problem it was actually 'deriving-ocsigen' when I needed to implement my
>> own Show module - it's just much faster to see what's being generated
>> for the usual case, then trying to figure out from the recipe in the
>> documentation.  Otherwise for bootstrapping purposes, you might want to
>> pre-generate some code too and put into the repository.
>>
>> --
>> Wojciech Meyer
>> http://danmey.org
>>
>>
>


-- 
Regards
-- Bob

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