Re: [Caml-list] Intended behavior of GenerateMap

["Nicolas Pouillard" <nicolas.pouillard@gmail.com>]

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