[wg-camlp4] Status of extension_points extensions

Romain Bardou romain.bardou at inria.fr
Tue Jun 4 10:08:36 BST 2013


Dear wg-camlp4,

Recently Alain has impressively shown great examples of extension_points
in action.

- An extension to generate .mli files from .ml files with annotations
such as "this type should be abstract":

[@@mli abstract]

(Alain does *not* endorse the idea of generating .mli files
automatically, this is just a proof-of-concept!)

- an extension to put ocamldoc-like comments, added not as comments but
as extension points (making it more clear that the comment is attached
to a given node in the parsetree):

[@@doc "This is an internal module."]

- an extension to copy a type definition from the .mli to the .ml

type t = [%copy_typedef]

The syntax makes it very clear that extensions are not part of the
language and are extensions. This is good. However, it also means that
if the extension proves so useful that we want it part of the actual
language, we are left with the following choices:
- provide the extension as-is;
- reprogram the extension with a dedicated syntax.

If we provide the extension as-is, the fact that the syntax says it is
an extension suddenly is a problem because it is not actually an
extension anymore if it is part of the language. Moreover the syntax may
not be ideal. And if this approach is used, and several extensions are
included, we may end up with programs which are cluttered with brackets,
so to speak.

If, on the other hand, we reprogram the extension, we are able to
provide a nicer syntax. For instance, just write "abstract" instead of
"[@@mli abstract]". But it means more work and we would not know what to
do with programs that used the extension before: rewrite them with the
new syntax? Keep using the extension, which will probably no longer be
maintained if it is part of the language?

Until now, I saw extension_points as a very nice way to experiment with
language extensions, and to provide custom, project-local extensions.
But Alain just showed how powerful it is and my fear is now that,
paradoxically, we and up with a lot of very useful extensions that would
almost become need-to-haves… and with the drawback that for many of them
the syntax would not be ideal.

Has this issue already been discussed?

That being said, it is a problem which is rather good to have.

Cheers,

-- 
Romain Bardou


More information about the wg-camlp4 mailing list