[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