[wg-camlp4] getting bitstring to work with Core
Christophe TROESTLER
Christophe.Troestler at umons.ac.be
Tue May 28 20:45:08 BST 2013
On Tue, 28 May 2013 14:10:26 -0400, Sebastien Mondet wrote:
>
> What would be wrong with Xavier's solution?
> (having Bitstring call only functions Bitstring.something)
Yes, aliasing the needed functions in Bitstring is also a good
solution. I think it is even better than my suggestion.
> On Tue, May 28, 2013 at 1:58 PM, Richard W.M. Jones <rich at annexia.org> wrote:
>
> >
> On Tue, May 28, 2013 at 07:08:51PM +0200, Christophe TROESTLER wrote:
> > > On Tue, 28 May 2013 12:40:33 -0400, Stephen Weeks wrote:
> > > >
> > > > > It's the build system integration that fills me with dread (figuring
> > > > > out the ocamlfind META runes, how to plumb this through to ocamlbuild,
> > > > > OASIS and OMake, and activate it only for files that use Core).
> > > >
> > > > I see. Waiting for namespaces might be the way to go then.
> > > >
> > > > One way that might simplify the build-system nightmare a bit would be
> > > > to always have the Caml module in scope and to have bitstring always
> > > > generate references to it, whether or not one is compiling against
> > > > Core.
> > >
> > > How about that bitstring (automatically) inserts aliases of the
> > > Prevasive modules it needs at the beginning of the file (thus, before
> > > Core is opened) and refers to these? It will then work regardless of
> > > the modules that are shadowed.
> >
> >
> I think I tried to have a camlp4 extension insert something at
> > the beginning of the output, and concluded it wasn't possible.
> >
> > Or perhaps I'm mis-remembering ...?
It is possible.
Best,
C.
More information about the wg-camlp4
mailing list