Version française
Home     About     Download     Resources     Contact us    
Browse thread
Intended behavior of GenerateMap
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Christian Stork <caml-list@c...>
Subject: Re: [Caml-list] Intended behavior of GenerateMap
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