Re: Camlp4 mysteries (was Re: On language extensions (was Re: [Caml-list] global record))

[Martin Jambon <martin1977@laposte.net>]

On Fri, 21 Jul 2006, Alain Frisch wrote:

> Martin Jambon wrote:
>> Otherwise it's possible to define well-disciplined syntax extensions.
>> For example, if each new syntax construct (new rule) is forced to start
>> with a unique, registered keyword and end with "end", then different
>> syntax extensions that follow this rule should play well together.
>
> Except that any new keyword can potentially break existing code. You'd
> need some other syntactical convention.

Sure, but for future code which uses future syntax extensions, it will be 
OK.

For the current extensions, it is possible to offer alternatives (via a 
-std option or something like that). If I understand correctly, we will have to 
adapt quite a few things for our syntax extensions to support the new 
Camlp4, so while we are at it, adding an alternate standardized syntax 
won't be a problem if it doesn't require too much thinking.

(In addition to that, like Skaller suggested, something like "open syntax 
Mysyntax" would make syntax extensions available like library modules, 
which simplifies makefiles and doesn't force every module to use them. But 
that's about integrating Camlp4 tightly in the OCaml language, which is 
another story)


>> It would be really nice to have official guidelines on how to develop
>> clean syntax extensions, if not automatic enforcement.
>
> Do you have concrete examples of extensions that don't play well together?

Yes, mine :-)

In micmatch I delete and redefine the constructs with bindings: let, let 
in, match, try, function.

The resulting syntax gives the illusion of a nice integration, but this 
is a redefinition of the existing constructs, so if another extension 
does the same, only the one which is loaded last will be usable.

In practice I haven't had any problem like that, but it's a 
possibility.
So this is why someone should decide of a standard, and we will follow it.


Martin

--
Martin Jambon, PhD
http://martin.jambon.free.fr