[ocaml-platform] on the need and design of OCaml namespaces

[Gabriel Scherer]

> It's not evident to me that namespaces actually solve the problem either,
they just seem to push the problem in the build system. The actual problem
seems very related to the problem of hygienic macros (accidental name
capture).

Indeed.

What you really want of Camlp4 extensions is not "namespaces", but
*hygiene*. Hygiene in hygenic macro systems means two things:
  1. having binders in macros not capture bound variables in expanded
user-provided code (unless explicitly desired, to implement a new binding
structure as macro)
  2. having bound variables in macros not be captured by user-provided
binders

None of those two distinct aspects are specifically accounted for in the
current OCaml+Camlp4 combination. The lack of the first can be worked
around by being careful in extension code (preserve the scope of
user-provided code and not expand it under extension binders, which is
possible thanks to OCaml expressive "let ... and .." feature), the lack of
the second is more problematic as it would require the extension *user* to
be careful (not happening in practice).

This is related to this bug report by Hongbo:
  http://caml.inria.fr/mantis/view.php?id=5849

Namespaces are only an attempt to workaround the problem by adding an
indirection in naming that would make lack of hygiene less visible. It's a
reasonable side-effect of a namespace proposal, but that cannot reasonably
be the main motivation for adding namespaces. "Let's add this new feature
so that this problem with that ugly tool can be partially fixed in this
ugly way" is not going to fly.

(Note that Lisp languages solve this by embedding the macro facility in the
language itself, instead of having an up-front AST-generation model. This
allows macro expansion to elaborate internal unique names instead of
surface names, which solves this hygiene problem. An OCaml equivalent would
be to give a way to address a module by its internal compilation unit name.)

On Fri, Feb 22, 2013 at 3:33 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch>wrote:

> Le vendredi, 22 février 2013 à 14:52, Malcolm Matalka a écrit :
> > So would a syntax extension always have to store the modules it wants to
> > be sure to access at the beginning of a file it requires, making sure
> > not to choose overlapping names?
>
> Why not ? Each extension could have its own module against which you have
> to link to use the extension that has the module it uses in it
> (MyExt.List…).
>
> It's not evident to me that namespaces actually solve the problem either,
> they just seem to push the problem in the build system. The actual problem
> seems very related to the problem of hygienic macros (accidental name
> capture).
>
> Besides I'm not sure the example Anil gave is as widespread as it seems,
> it feels like a corner case that could be avoided, as he suggested, by
> having the ability to refer to stdlib's modules under a toplevel name
> (OCaml.List) and this still seems in the realm of the module system (and
> could be realized via something like cmia).
>
> Daniel
>
>
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130222/bbdfb83d/attachment.html>