let open in with mikmatch

[Guillaume Yziquel]

Hi.

Just to mention the following thing I experienced concerning the 'let
open in' construct. (Could not easily find a way to report it on
OCamlForge, so posting it here).

Basically, when you write something like:

match chunk with
| RE "\000\000\000\005" (_* as remaining) ->
let open Stuff in nothing
| _ -> assert false

well, the 'let open Stuff in' stops mikmatch from correctly generating
the __mikmatch_regexp_n values.

On a small example like this, things will be correctly generated, but
on my larger code (~1300 lines of protocol parsing code), it fails
when I add this let open in construct.

Is there still interest in mikmatch development to expect to see this
issue addressed in the future? If not, what's the easiest to debug
such a complex syntax extension?

Guillaume.

[Martin Jambon]

On 03/27/11 05:36, Guillaume Yziquel wrote:
> Hi.
>
> Just to mention the following thing I experienced concerning the 'let
> open in' construct. (Could not easily find a way to report it on
> OCamlForge, so posting it here).
>
> Basically, when you write something like:
>
> match chunk with
> | RE "\000\000\000\005" (_* as remaining) ->
> let open Stuff in nothing
> | _ -> assert false
>
> well, the 'let open Stuff in' stops mikmatch from correctly generating
> the __mikmatch_regexp_n values.
>
> On a small example like this, things will be correctly generated, but
> on my larger code (~1300 lines of protocol parsing code), it fails
> when I add this let open in construct.
>
> Is there still interest in mikmatch development to expect to see this
> issue addressed in the future?

Development: no.
Maintenance: yes (although it is much more costly than it should be,
because of the camlp4-camlp5 mess)

Whether I fix this is going to depend on how much work is involved,
whether existing user code is affected, etc.

> If not, what's the easiest to debug
> such a complex syntax extension?

I suggest you start by isolating the smallest piece of code that doesn't
work as it should, and then post it here.

Martin

[Guillaume Yziquel]

Le Sunday 27 Mar 2011 à 10:59:52 (-0700), Martin Jambon a écrit :
> On 03/27/11 05:36, Guillaume Yziquel wrote:
> > Hi.
> >
> > Just to mention the following thing I experienced concerning the 'let
> > open in' construct. (Could not easily find a way to report it on
> > OCamlForge, so posting it here).
> >
> > Basically, when you write something like:
> >
> > match chunk with
> > | RE "\000\000\000\005" (_* as remaining) ->
> > let open Stuff in nothing
> > | _ -> assert false
> >
> > well, the 'let open Stuff in' stops mikmatch from correctly generating
> > the __mikmatch_regexp_n values.
> >
> > On a small example like this, things will be correctly generated, but
> > on my larger code (~1300 lines of protocol parsing code), it fails
> > when I add this let open in construct.
> >
> > Is there still interest in mikmatch development to expect to see this
> > issue addressed in the future?
>
> Development: no.
> Maintenance: yes (although it is much more costly than it should be,
> because of the camlp4-camlp5 mess)

Don't you think it'd be wiser to only maintain stuff on the camlp4 side
and drop the camlp5 one. It seems that it's the only one that is widely
used nowadays (may be mistaken however).

> Whether I fix this is going to depend on how much work is involved,
> whether existing user code is affected, etc.
>
> > If not, what's the easiest to debug
> > such a complex syntax extension?
>
> I suggest you start by isolating the smallest piece of code that doesn't
> work as it should, and then post it here.

I'll try trimming it down.

> Martin

--
Guillaume Yziquel