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

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

[Anil Madhavapeddy]

There's a very useful %.pp.ml target in OCamlbuild that runs the source through camlp4 and outputs the result.  This doesn't work when ocamlfind is used, as it includes the -pp flags within the ocamlfind invocation.

I took a look at adding support for this into ocamlbuild (when -use-ocamlfind is specified), but I couldn't spot any way to get ocamlfind to output the syntax options.

I just wanted to check that this is all in fact true, since it requires patching ocamlbuild, findlib, and oasis to make it work. Does everyone else manually run the camlp4o command when using syntax extensions like type-conv or pa_lwt?

-anil

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

[Gabriel Scherer]

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

I was also under the impression that ocamlbuild Ocamlfind integration was
unable to use archive(syntax) or archive(preprocessor) dependencies for
ocamlfind packages providing syntax extensions. This is a serious
limitation as it makes some ocamlfind packages unusable. If you're
considering improving this, I thank you in advance.

> I took a look at adding support for this into ocamlbuild (when
-use-ocamlfind is specified), but I couldn't spot any way to get ocamlfind
to output the syntax options.

I'm not sure what you're looking for exactly. If you whish to know what
archives should be included at the preprocessing step, this is done using
the "-predicates" option with, say, "-predicates syntax,preprocessor",
which will gives you the archives included in this situation:

  % ocamlfind query -predicates syntax,preprocessor -format '%A' type-conv
  pa_type_conv.cma

> Does everyone else manually run the camlp4o command when using syntax
extensions like type-conv or pa_lwt?

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.

On Sat, Dec 31, 2011 at 12:19 AM, Anil Madhavapeddy <Anil@recoil.org> wrote:

> There's a very useful %.pp.ml target in OCamlbuild that runs the source
> through camlp4 and outputs the result.  This doesn't work when ocamlfind is
> used, as it includes the -pp flags within the ocamlfind invocation.
>
> I took a look at adding support for this into ocamlbuild (when
> -use-ocamlfind is specified), but I couldn't spot any way to get ocamlfind
> to output the syntax options.
>
> I just wanted to check that this is all in fact true, since it requires
> patching ocamlbuild, findlib, and oasis to make it work. Does everyone else
> manually run the camlp4o command when using syntax extensions like
> type-conv or pa_lwt?
>
> -anil
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

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

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

[Wojciech Meyer]

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
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

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

[Hongbo Zhang]

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
>

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

[bob zhang]

[-- 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 --]

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

[Wojciech Meyer]

On Mon, Sep 10, 2012 at 1:18 PM, bob zhang <bobzhang1988@gmail.com> wrote:
>
> 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

OK. I'll have a look. BTW: At first glance it looks like a lot of good
customisations, thanks for sharing, I will speak about it to you it
later once I got my head around your plugin, which definitely will
happen soon.

> 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.

I watched a video some months ago about Haskell's Shake. I liked it. It
became open source some time ago. Agreed that ocamlbuild need some more
love to make it better. I wouldn't replace ocamlbuild with anything,
just if there weren't some problems, which in fact are not that
significant.

-- Wojciech

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

[Gerd Stolpmann]

Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
> 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.

And I wonder why ocamlbuild is actually used. There is a *high quality*  
build tool for ocaml: omake.


> 
> 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
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

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

[Wojciech Meyer]

Gerd,

I agree omake is a high quality tool for non trivial builds, however
it does not solve the same problems as ocamlbuild. The point of
dicsussion is to improve ocamlbuild not to switch to the external
tool.
I will lament, because I used both and ocamlbuild have some clear
advantages over omake (and some clear disadvantages too):

- it's dead easy to build a single file, without constructing
horrendous command line or adding an unneeded target
- it's declarative, you don't want to construct tons of special
variables and concatate them
- it's part of our distribution - no additional dependencies, so if
it's there, there is some reason, and if something it's not working
properly we have to fix it

Overall ocamlbuild is based on some nice ideas, whatever people would
say. Not that I say that OMake is no good - in fact it's a very robust
and excellent build system, and I recommend anyone who's got already
bootstraping phases, lot of meta programming with unsual tools,
portability problems etc..

Both however suffer from almost similar problem - OMake is a bit
underused for the quality you get, where ocamlbuild is just underrated
for the ideas it has.

-- 
Wojciech

On Tue, Sep 11, 2012 at 1:27 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
>>
>> 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.
>
>
> And I wonder why ocamlbuild is actually used. There is a *high quality*
> build tool for ocaml: omake.
>
>
>>
>> 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
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>
> --
> ------------------------------------------------------------
> Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> Creator of GODI and camlcity.org.
> Contact details:        http://www.camlcity.org/contact.html
> Company homepage:       http://www.gerd-stolpmann.de
> ------------------------------------------------------------
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

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

[Gerd Stolpmann]

Am 11.09.2012 14:50:24 schrieb(en) Wojciech Meyer:
> Gerd,
> 
> I agree omake is a high quality tool for non trivial builds, however
> it does not solve the same problems as ocamlbuild. The point of
> dicsussion is to improve ocamlbuild not to switch to the external
> tool.

Well, I don't want to stop you fixing ocamlbuild. My point is rather  
that users sometimes don't recognize the point of complexity when  
ocamlbuild is no longer the right utility, and I just want to point out  
that there is an alternative tool.

> I will lament, because I used both and ocamlbuild have some clear
> advantages over omake (and some clear disadvantages too):
> 
> - it's dead easy to build a single file, without constructing
> horrendous command line or adding an unneeded target

Come on, this is not a fair critique. Have you ever started a fresh  
omake project? It's really short:

.DEFAULT: $(OCamlProgram put_here_the_name_of_your_program, module1  
module2 ...)

> - it's declarative, you don't want to construct tons of special
> variables and concatate them

You can have pattern rules in omake, and I think they are a full  
replacement for tags.

> - it's part of our distribution - no additional dependencies, so if
> it's there, there is some reason, and if something it's not working
> properly we have to fix it

Right, being part of the distribution is the advantage of ocamlbuild.

> Overall ocamlbuild is based on some nice ideas, whatever people would
> say. Not that I say that OMake is no good - in fact it's a very robust
> and excellent build system, and I recommend anyone who's got already
> bootstraping phases, lot of meta programming with unsual tools,
> portability problems etc..

I'd recomment it already when the alternative is to write ocamlbuild  
plugins (which are the biggest error of ocamlbuild - ocaml is just not  
the right language to modify the behavior of builds).

> Both however suffer from almost similar problem - OMake is a bit
> underused for the quality you get, where ocamlbuild is just underrated
> for the ideas it has.

ocamlbuild certainly has some nice ideas, but I'd overall say that it  
jumps too short. It's ok for student projects, and I guess this is the  
main justification for having it in the distribution. It's easier than  
traditional Makefiles. What's missing is that you cannot easily modify  
existing behavior, and to my mind, plugins do not use the right  
abstractions. A one-liner in omake's DSL (which is actually a nice  
dynamically-typed functional language) turns into a lengthy phrase.

Well, there are also things I don't like in omake (e.g. environments  
are powerful but also difficult to debug). But so far it is the clear  
winner for me, mostly because it has a good DSL which is more adequate  
than

Gerd


> --
> Wojciech
> 
> On Tue, Sep 11, 2012 at 1:27 PM, Gerd Stolpmann  
> <info@gerd-stolpmann.de> wrote:
> > Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
> >>
> >> 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.
> >
> >
> > And I wonder why ocamlbuild is actually used. There is a *high  
> quality*
> > build tool for ocaml: omake.
> >
> >
> >>
> >> 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
> >>
> >> --
> >> Caml-list mailing list.  Subscription management and archives:
> >> https://sympa-roc.inria.fr/wws/info/caml-list
> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> >>
> >>
> >
> > --
> > ------------------------------------------------------------
> > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
> > Creator of GODI and camlcity.org.
> > Contact details:        http://www.camlcity.org/contact.html
> > Company homepage:       http://www.gerd-stolpmann.de
> > ------------------------------------------------------------
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa-roc.inria.fr/wws/info/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> >
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 
> 
> 

-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

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

[Wojciech Meyer]

>> - it's dead easy to build a single file, without constructing
>> horrendous command line or adding an unneeded target
>
>
> Come on, this is not a fair critique. Have you ever started a fresh omake
> project? It's really short:
>
> .DEFAULT: $(OCamlProgram put_here_the_name_of_your_program, module1 module2
> ...)

Yes, right, but still you have to write a special rule and change
file, instead of requesting this to be built straight from a comfort
of shell.
So the state is involved, you can perhaps do that with some --eval
sort of thing.
For instance, sometimes I really want to experiment and build a single
module without any plans to integrate it, then ocamlbuild is
appropriate for that job.
BTW: Have you tried out of tree builds? This works out of the box and
by default with ocamlbuild, and AFAIR I couldn't understand how to do
this in OMake.

>> - it's declarative, you don't want to construct tons of special
>> variables and concatate them
>
>
> You can have pattern rules in omake, and I think they are a full replacement
> for tags.

Need to look at it!

> I'd recomment it already when the alternative is to write ocamlbuild plugins
> (which are the biggest error of ocamlbuild - ocaml is just not the right
> language to modify the behavior of builds).

In fact I fully agree that DSLs are way better in some respects than
full blown and turing complete languages.
In this case it's just easy to analyze the rules, however here you
*have also* a  DSL too, just embedded in the plugin.
OCamlbuild have very simple and clean interface to deal with the
essential properties of the tree like dependencies, shell commands
etc.
So in fact the plugin is a meta program that *generates* instances of
these rules, in a spirit of ML.
So I disagree that this is a bottleneck, you have extra syntactical
verbosity but usually it's a minor problem.
OTOH you can factor out easily the patterns. Of course this comes with
a risk of user being in full control of the build system, and then
it's not easy to explain what to do and what not to do.

>> Both however suffer from almost similar problem - OMake is a bit
>> underused for the quality you get, where ocamlbuild is just underrated
>> for the ideas it has.
>
>
> ocamlbuild certainly has some nice ideas, but I'd overall say that it jumps
> too short. It's ok for student projects, and I guess this is the main
> justification for having it in the distribution. It's easier than
> traditional Makefiles. What's missing is that you cannot easily modify
> existing behavior, and to my mind, plugins do not use the right
> abstractions. A one-liner in omake's DSL (which is actually a nice
> dynamically-typed functional language) turns into a lengthy phrase.

> Well, there are also things I don't like in omake (e.g. environments are
> powerful but also difficult to debug). But so far it is the clear winner for
> me, mostly because it has a good DSL which is more adequate than
> ocamlbuild's attempt to reuse ocaml for build purposes.

I'm mostly buying your argument about the DSL, however as I said
ocamlbuild has it too and just not on a syntactic level.

> Gerd

Wojciech

>
>
>
>> --
>> Wojciech
>>
>> On Tue, Sep 11, 2012 at 1:27 PM, Gerd Stolpmann <info@gerd-stolpmann.de>
>> wrote:
>> > Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
>> >>
>> >> 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.
>> >
>> >
>> > And I wonder why ocamlbuild is actually used. There is a *high quality*
>> > build tool for ocaml: omake.
>> >
>> >
>> >>
>> >> 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
>> >>
>> >> --
>> >> Caml-list mailing list.  Subscription management and archives:
>> >> https://sympa-roc.inria.fr/wws/info/caml-list
>> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
>> >>
>> >>
>> >
>> > --
>> > ------------------------------------------------------------
>> > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>> > Creator of GODI and camlcity.org.
>> > Contact details:        http://www.camlcity.org/contact.html
>> > Company homepage:       http://www.gerd-stolpmann.de
>> > ------------------------------------------------------------
>> >
>> > --
>> > Caml-list mailing list.  Subscription management and archives:
>> > https://sympa-roc.inria.fr/wws/info/caml-list
>> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>> >
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>>
>

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

[Hongbo Zhang]

On 9/11/12 2:27 PM, Gerd Stolpmann wrote:
> Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
>> 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.
>
> And I wonder why ocamlbuild is actually used. There is a *high quality*
> build tool for ocaml: omake
Well, IMHO, using a general purpose programming language with some 
combinators is *way more better* than a DSL, I used ocamlbuild to build 
a quite complex project: which includes bootstrapping, different 
preprocessing flags, nested directories, packing modules(byte code, 
native coce), (I even dynamically caculated the preprocess flags).

The problem with ocamlbuild is its implementation, not the idea, the 
idea is pretty good.
>
>>
>> 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
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>

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

[Gerd Stolpmann]

Am 11.09.2012 22:24:29 schrieb(en) Hongbo Zhang:
> On 9/11/12 2:27 PM, Gerd Stolpmann wrote:
>> Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
>>> 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.
>> 
>> And I wonder why ocamlbuild is actually used. There is a *high  
>> quality*
>> build tool for ocaml: omake
> Well, IMHO, using a general purpose programming language with some  
> combinators is *way more better* than a DSL, I used ocamlbuild to  
> build a quite complex project: which includes bootstrapping,  
> different preprocessing flags, nested directories, packing  
> modules(byte code, native coce), (I even dynamically caculated the  
> preprocess flags).

Fully agreed - just FYI, your statement is also completely true for the  
omake DSL. As said, it is a functional language adapted to the special  
needs of build processes. The effects you mention are surprisingly  
simple to get from omake.

Just a few examples:

- nested directories: A build project is always a tree. You add a
   subdirectory by listing it in .SUBDIRS. You can refer to files in
   other directories with relative path, or by $(rootname path), which
   turns it into a path relative to the project root. omake understands
   when different paths mean the same file. Dependencies work
   cross-directory, of course.

- preprocessing flags: Here is a function that adds some flags for
   a certain top-level module:

   Camlp4o(module) =
       section
           OCAMLPACKS += camlp4
           OCAMLFINDFLAGS += -syntax camlp4o
           $(module).cmi:
           $(module).cmo:
           $(module).o $(module).cmx:

   You call it as Camlp4o(my_module), and the effect is that the
   flags are added to the default ones. Easy, isn't it? (Unfortunately,
   this example is missing in the manual.)

   This is possible because omake has scoped dependencies. This is
   ultra-cool, and I haven't this seen anywhere else in a build tool
   yet.

- Dynamically calculated flags: Well, variables can be lazily evaluated,
   so you can include function calls, e.g.

   OCAMLFLAGS = -pp -Dbuild_time=$`(gettimeofday)

   gettimeofday is here first called just before the compiler is invoked
   (because of the backtick, which makes it lazily called). Depending
   on when you want to calculate the flags, there are lots of  
alternatives.
   An example:

   OCAMLFLAGS += $(if $(multithreaded),-thread,)

   (when "multithreaded" is a boolean variable).

- You can vmount directories over each other. This is very useful for
   bootstrapping somthing, e.g.

   if $(eq $(stage),1)
       vmount(-l,src,stage_1)

   if $(eq $(stage),2)
       vmount(-l,src,stage_2)

   The binary output of stage 1 is written to directory stage_1, and the
   output of stage 2 to stage_2. Both directories can have different
   build rules, so you can declare to build stage_2 with the tools from
   stage_1.

The omake DSL is different from ocaml in the following points (apart  
from supporting special syntax for describing dependencies, and a nice  
standard library):

- It has dynamically scoped variables by default (i.e. closures take
   the bindings from where the function is called, not defined). This
   makes variables work more like normal arguments, and this is very
   useful here - build actions can be modified by the user in a
   context-dependent way.
- It is dynamically typed (but supports strings, lists/arrays, maps,  
objects,
   functions, and a number of other types). The dynamic typing is not  
crucial
   here, though - it is more a matter of a simple implementation.
- You can mix eager and lazy evaluation arbitrarily
- The expression syntax can be directly embedded in shell commands

Summarized, you can instruct omake with a few definitions to support  
even complex builds. It's just a time saver.

Gerd

> The problem with ocamlbuild is its implementation, not the idea, the  
> idea is pretty good.
>> 
>>> 
>>> 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
>>> 
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa-roc.inria.fr/wws/info/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>> 
>>> 
>> 
> 
> 


-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------

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

[Hongbo Zhang]

Thanks for your interesting input.
I admit omake is a high quality tool if well maintained. But DSL is not 
enough, for example, can it do the 'io', calling my self customized 
lexing rules to generate dependency dynamically?(This is fairly simple 
in ocamlbuild). The DSL solution is wrong since you never know how 
complex rules your customer needs in advance.

If ocamlbuild accept binary input(not only one myocamlbuild.ml), it will 
be much more powerful.

On 9/12/12 1:13 AM, Gerd Stolpmann wrote:
> Am 11.09.2012 22:24:29 schrieb(en) Hongbo Zhang:
>> On 9/11/12 2:27 PM, Gerd Stolpmann wrote:
>>> Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
>>>> 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.
>>>
>>> And I wonder why ocamlbuild is actually used. There is a *high quality*
>>> build tool for ocaml: omake
>> Well, IMHO, using a general purpose programming language with some
>> combinators is *way more better* than a DSL, I used ocamlbuild to
>> build a quite complex project: which includes bootstrapping, different
>> preprocessing flags, nested directories, packing modules(byte code,
>> native coce), (I even dynamically caculated the preprocess flags).
>
> Fully agreed - just FYI, your statement is also completely true for the
> omake DSL. As said, it is a functional language adapted to the special
> needs of build processes. The effects you mention are surprisingly
> simple to get from omake.
>
> Just a few examples:
>
> - nested directories: A build project is always a tree. You add a
>    subdirectory by listing it in .SUBDIRS. You can refer to files in
>    other directories with relative path, or by $(rootname path), which
>    turns it into a path relative to the project root. omake understands
>    when different paths mean the same file. Dependencies work
>    cross-directory, of course.
>
> - preprocessing flags: Here is a function that adds some flags for
>    a certain top-level module:
>
>    Camlp4o(module) =
>        section
>            OCAMLPACKS += camlp4
>            OCAMLFINDFLAGS += -syntax camlp4o
>            $(module).cmi:
>            $(module).cmo:
>            $(module).o $(module).cmx:
>
>    You call it as Camlp4o(my_module), and the effect is that the
>    flags are added to the default ones. Easy, isn't it? (Unfortunately,
>    this example is missing in the manual.)
>
>    This is possible because omake has scoped dependencies. This is
>    ultra-cool, and I haven't this seen anywhere else in a build tool
>    yet.
>
> - Dynamically calculated flags: Well, variables can be lazily evaluated,
>    so you can include function calls, e.g.
>
>    OCAMLFLAGS = -pp -Dbuild_time=$`(gettimeofday)
>
>    gettimeofday is here first called just before the compiler is invoked
>    (because of the backtick, which makes it lazily called). Depending
>    on when you want to calculate the flags, there are lots of alternatives.
>    An example:
>
>    OCAMLFLAGS += $(if $(multithreaded),-thread,)
>
>    (when "multithreaded" is a boolean variable).
>
> - You can vmount directories over each other. This is very useful for
>    bootstrapping somthing, e.g.
>
>    if $(eq $(stage),1)
>        vmount(-l,src,stage_1)
>
>    if $(eq $(stage),2)
>        vmount(-l,src,stage_2)
>
>    The binary output of stage 1 is written to directory stage_1, and the
>    output of stage 2 to stage_2. Both directories can have different
>    build rules, so you can declare to build stage_2 with the tools from
>    stage_1.
>
> The omake DSL is different from ocaml in the following points (apart
> from supporting special syntax for describing dependencies, and a nice
> standard library):
>
> - It has dynamically scoped variables by default (i.e. closures take
>    the bindings from where the function is called, not defined). This
>    makes variables work more like normal arguments, and this is very
>    useful here - build actions can be modified by the user in a
>    context-dependent way.
> - It is dynamically typed (but supports strings, lists/arrays, maps,
> objects,
>    functions, and a number of other types). The dynamic typing is not
> crucial
>    here, though - it is more a matter of a simple implementation.
> - You can mix eager and lazy evaluation arbitrarily
> - The expression syntax can be directly embedded in shell commands
>
> Summarized, you can instruct omake with a few definitions to support
> even complex builds. It's just a time saver.
>
> Gerd
>
>> The problem with ocamlbuild is its implementation, not the idea, the
>> idea is pretty good.
>>>
>>>>
>>>> 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
>>>>
>>>> --
>>>> Caml-list mailing list.  Subscription management and archives:
>>>> https://sympa-roc.inria.fr/wws/info/caml-list
>>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>>>
>>>>
>>>
>>
>>
>
>

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

[Wojciech Meyer]

> 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.

Yes, typing errors are also hard to track in the default Camlp4
"stealth mode". I generally think it works well, apart from the corner
cases which will always occur during development where you really need
full excerpt of the generated code.

> Btw, are you in ICFP? we could have a talk about Camlp4 :-)

Not on ICFP but on OUD only.. but yeah, we could talk about Camlp4, I
think OCaml meta programming tools deserve much more attention in
general.

- Wojciech

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

[Alain Frisch]

On 09/10/2012 02:55 PM, Wojciech Meyer wrote:
> Not on ICFP but on OUD only.. but yeah, we could talk about Camlp4, I
> think OCaml meta programming tools deserve much more attention in
> general.

Shameless plug: the last session (= the one before the beer) of the ML 
workshop will be a panel session on 'syntactic meta-programming for ML'. 
  Camlp4 will certainly be a central point of discussion.  This is the 
day before OUD, same location.

-- Alain

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

[Paolo Donadeo]

On Mon, Sep 10, 2012 at 3:52 PM, Alain Frisch <alain@frisch.fr> wrote:
> Camlp4 will certainly be a central point of discussion.  This is the day
> before OUD, same location.

Do you plan to release slides of the session? I'll not be there this year...


-- 
Paolo

[Caml-list] Slides of ML workshop (was: working %.pp.ml target with ocamfind/ocamlbuild)

[Alain Frisch]

On 9/10/2012 4:36 PM, Paolo Donadeo wrote:
> On Mon, Sep 10, 2012 at 3:52 PM, Alain Frisch <alain@frisch.fr> wrote:
>> Camlp4 will certainly be a central point of discussion.  This is the day
>> before OUD, same location.
>
> Do you plan to release slides of the session? I'll not be there this year...

All the slides for the ML2012 workshop are now online at:

http://www.lexifi.com/ml2012/


Videos should be available today or tomorrow on Youtube.


Alain

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

[Anil Madhavapeddy]

On Sun, Sep 09, 2012 at 05:29:53PM +0100, 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
> 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.

The %.pp.ml rule is really essential for day-to-day development too.
Since camlp4 cannot generate ocamldoc comments, it's often easier to just
dump the .pp.ml output and inspect the code directly, rather than root
around figuring out what the code generator modules are doing.

This is less of an issue with well-established extensions such as sexplib,
but useful when learning new ones such as the Lwt one (which has some odd
corner cases such as the >> bind precedence).

-- 
Anil Madhavapeddy                                 http://anil.recoil.org