[wg-camlp4] getting bitstring to work with Core

[Sebastien Mondet]

Hi

What would be wrong with Xavier's solution?
(having Bitstring ­­call only functions Bitstring.something)

It looks the most hygienic and future-proof to me, and could work for all
syntax extensions — or code generators — that have a library to work with
 (BTW, we had the same problem with PG'OCaml generating code with
String.concat which is different in Core).


cheers
seb




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 ...?
>
> Rich.
>
> --
> Richard Jones
> Red Hat
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/wg-camlp4/attachments/20130528/d7f02617/attachment-0001.html>