Intended behavior of GenerateMap

Intended behavior of GenerateMap

[Christian Stork]

Hi,

Is my understanding correct that running "camlp4of -filter map ..." over

    class map = Camlp4Filters.GenerateMap.generated

will produce a map class for *all* types defined in the current file --
irrespective if the types are incapsulated in a module (which is then
used for the Camlp4Trash trick)?

Wouldn't it be much nicer, i.e., more economical and more precise, if
the above only produces a map class for the most recently defined type
/ mutually recursive types?   

Just wondering,
Chris

PS: I came to the above question after reading the source and some
experimentation.  Is there any place where the rationale behind
GenerateMap/Fold is explained?

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F

Re: [Caml-list] Intended behavior of GenerateMap

[Nicolas Pouillard]

On 6/8/07, Christian Stork <caml-list@cstork.org> wrote:
> Hi,
>
> Is my understanding correct that running "camlp4of -filter map ..." over
>
>     class map = Camlp4Filters.GenerateMap.generated
>
> will produce a map class for *all* types defined in the current file --
> irrespective if the types are incapsulated in a module (which is then
> used for the Camlp4Trash trick)?

Your understanding is correct.

> Wouldn't it be much nicer, i.e., more economical and more precise, if
> the above only produces a map class for the most recently defined type
> / mutually recursive types?

Yes it will be nicer. I don't remember why I didn't do that, perhaps
to don't have to turn the AST definition in one big mutually recursive
type.

> PS: I came to the above question after reading the source and some
> experimentation.  Is there any place where the rationale behind
> GenerateMap/Fold is explained?

Not really the goal was just to "scrap my boiler plate" in OCaml for
the Camlp4 AST (an economy of merely 5000 lines that are generated).

-- 
Nicolas Pouillard

Re: [Caml-list] Intended behavior of GenerateMap

[Nicolas Pouillard]

I've added to  the Camlp4 wiki a documentation about
Camlp4MapGenerator and Camlp4FoldGenerator

http://brion.inria.fr/gallium/index.php/Camlp4MapGenerator
http://brion.inria.fr/gallium/index.php/Camlp4FoldGenerator

Enjoy!

On 6/13/07, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> On 6/8/07, Christian Stork <caml-list@cstork.org> wrote:
> > Hi,
> >
> > Is my understanding correct that running "camlp4of -filter map ..." over
> >
> >     class map = Camlp4Filters.GenerateMap.generated
> >
> > will produce a map class for *all* types defined in the current file --
> > irrespective if the types are incapsulated in a module (which is then
> > used for the Camlp4Trash trick)?
>
> Your understanding is correct.
>
> > Wouldn't it be much nicer, i.e., more economical and more precise, if
> > the above only produces a map class for the most recently defined type
> > / mutually recursive types?
>
> Yes it will be nicer. I don't remember why I didn't do that, perhaps
> to don't have to turn the AST definition in one big mutually recursive
> type.
>
> > PS: I came to the above question after reading the source and some
> > experimentation.  Is there any place where the rationale behind
> > GenerateMap/Fold is explained?
>
> Not really the goal was just to "scrap my boiler plate" in OCaml for
> the Camlp4 AST (an economy of merely 5000 lines that are generated).
>
> --
> Nicolas Pouillard
>

-- 
Nicolas Pouillard\

Re: [Caml-list] Intended behavior of GenerateMap

[Nicolas Pouillard]

On 6/8/07, Christian Stork <caml-list@cstork.org> wrote:
> Hi,
>
> Is my understanding correct that running "camlp4of -filter map ..." over
>
>     class map = Camlp4Filters.GenerateMap.generated
>
> will produce a map class for *all* types defined in the current file --
> irrespective if the types are incapsulated in a module (which is then
> used for the Camlp4Trash trick)?
>
> Wouldn't it be much nicer, i.e., more economical and more precise, if
> the above only produces a map class for the most recently defined type
> / mutually recursive types?
>

Indeed it's nicer...

These days I've improved this generator to be able to generate,
multiple maps and folds (Map{2,3,4...}, Fold{2,3,4...}). And also the
combination of both: MapFold{,2,3,4...}.

I've also followed your advise by taking in account only the last
defined set of mutually recursive types.

Note that the Camlp4Trash trick is still needed by those that wants
have the type declaration separated from these classes.

-- 
Nicolas Pouillard

Re: [Caml-list] Intended behavior of GenerateMap

[Christian Stork]

On Sat, Jun 23, 2007 at 08:59:24PM +0200, Nicolas Pouillard wrote:
> On 6/8/07, Christian Stork <caml-list@cstork.org> wrote:
> >Hi,
> >
> >Is my understanding correct that running "camlp4of -filter map ..." over
> >
> >    class map = Camlp4Filters.GenerateMap.generated
> >
> >will produce a map class for *all* types defined in the current file --
> >irrespective if the types are incapsulated in a module (which is then
> >used for the Camlp4Trash trick)?
> >
> >Wouldn't it be much nicer, i.e., more economical and more precise, if
> >the above only produces a map class for the most recently defined type
> >/ mutually recursive types?
> >
> 
> Indeed it's nicer...
> 
> These days I've improved this generator to be able to generate,
> multiple maps and folds (Map{2,3,4...}, Fold{2,3,4...}). And also the
> combination of both: MapFold{,2,3,4...}.

Map2 as in List.map2?  So what happens if several ASTs have different
shapes?

BTW, where it that code?  Oh, just found it on the release310 branch.
Great, that means we'll get to use it in 3.10.1 already. :-)

> I've also followed your advise by taking in account only the last
> defined set of mutually recursive types.

Actually, I think the ideal solution is to generate a Map for
the last type and to "suck in" all the other types that are
(transitively) used by that definition.  (Maybe that's what your're
doing already anyway.)
 
Then you don't even need to change your current usages of GenerateMap.

> Note that the Camlp4Trash trick is still needed by those that wants
> have the type declaration separated from these classes.

Sure.

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F

Re: [Caml-list] Intended behavior of GenerateMap

[Nicolas Pouillard]

On 6/23/07, Christian Stork <caml-list@cstork.org> wrote:
> On Sat, Jun 23, 2007 at 08:59:24PM +0200, Nicolas Pouillard wrote:
> > On 6/8/07, Christian Stork <caml-list@cstork.org> wrote:
> > >Hi,
> > >
> > >Is my understanding correct that running "camlp4of -filter map ..." over
> > >
> > >    class map = Camlp4Filters.GenerateMap.generated
> > >
> > >will produce a map class for *all* types defined in the current file --
> > >irrespective if the types are incapsulated in a module (which is then
> > >used for the Camlp4Trash trick)?
> > >
> > >Wouldn't it be much nicer, i.e., more economical and more precise, if
> > >the above only produces a map class for the most recently defined type
> > >/ mutually recursive types?
> > >
> >
> > Indeed it's nicer...
> >
> > These days I've improved this generator to be able to generate,
> > multiple maps and folds (Map{2,3,4...}, Fold{2,3,4...}). And also the
> > combination of both: MapFold{,2,3,4...}.
>
> Map2 as in List.map2?  So what happens if several ASTs have different
> shapes?

Almost like List.map2... But it takes a tuple instead of sevral
arguments, and call #map2_failure when head constructors are
different.

>
> BTW, where it that code?  Oh, just found it on the release310 branch.
> Great, that means we'll get to use it in 3.10.1 already. :-)
>
> > I've also followed your advise by taking in account only the last
> > defined set of mutually recursive types.
>
> Actually, I think the ideal solution is to generate a Map for
> the last type and to "suck in" all the other types that are
> (transitively) used by that definition.  (Maybe that's what your're
> doing already anyway.)
>

No I keep just the last syntactic definition. It's not that simple to
gather the others, since features like modules, open, include, require
a complete analysis.

-- 
Nicolas Pouillard

Anti-matching

[Frédéric Gava]

Dear Caml-list

I have read the following feature of TOM, anti-matching:
http://tom.loria.fr/soft/release-2.4/manual-2.4/manual003.html#toc8


that allow to specify what you don't want to match. For example in a 
OCaml like syntax (for the type 'a option = None | Some of 'a):

(function !(Some _) -> assert false)

would raise an exception in case of None. Ok, this is not a really 
interesting example but is it a good feature for ocaml ? Is some one 
have do a camlp4 extension for this ? I do not find any library for this 
in the the ocaml's hump...

Best,
Frédéric Gava

Re: [Caml-list] Anti-matching

[David Thomas]

Isn't "!(x) -> a | _ -> b" the same as "x -> b | _ ->
a"?  I don't really see much of a benefit, at the cost
(I assume) of complexity.

--- Frédéric Gava <gava@univ-paris12.fr> wrote:

> Dear Caml-list
> 
> I have read the following feature of TOM,
> anti-matching:
>
http://tom.loria.fr/soft/release-2.4/manual-2.4/manual003.html#toc8
> 
> 
> that allow to specify what you don't want to match.
> For example in a 
> OCaml like syntax (for the type 'a option = None |
> Some of 'a):
> 
> (function !(Some _) -> assert false)
> 
> would raise an exception in case of None. Ok, this
> is not a really 
> interesting example but is it a good feature for
> ocaml ? Is some one 
> have do a camlp4 extension for this ? I do not find
> any library for this 
> in the the ocaml's hump...
> 
> Best,
> Frédéric Gava
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
>
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
> 



      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

Re: [Caml-list] Anti-matching

[Frédéric Gava]

David Thomas a écrit :
> Isn't "!(x) -> a | _ -> b" the same as "x -> b | _ ->
> a"?  I don't really see much of a benefit, at the cost
> (I assume) of complexity.

In this case, yes. But you can express interesting (more easier) thinks 
as (examples of TOM)

!f(x,x) -> // matches either something different from f, or an f with x1 
!= x2

f(x,!g(x)) -> {
       // matches an f which has either x2!=g or x2=g(y) with y != x1

You can simulating this using classical pattern matching. So I thinks 
that is possible using camlp4. But, looking for someone you have do this 
work or plan to do this.

FG