> 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).<br>
<br>Indeed.<br><br>What you really want of Camlp4 extensions is not "namespaces", but *hygiene*. Hygiene in hygenic macro systems means two things:<br> 
 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)<br>  2. having bound variables in macros not be captured by user-provided binders<br><br>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).<br><br>This is related to this bug report by Hongbo:<br>  <a href="http://caml.inria.fr/mantis/view.php?id=5849">http://caml.inria.fr/mantis/view.php?id=5849</a><br><br>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.<br><br>(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.)<br>

<br><div class="gmail_quote">On Fri, Feb 22, 2013 at 3:33 PM, Daniel Bünzli <span dir="ltr"><<a href="mailto:daniel.buenzli@erratique.ch" target="_blank">daniel.buenzli@erratique.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Le vendredi, 22 février 2013 à 14:52, Malcolm Matalka a écrit :<br>
<div class="im">> So would a syntax extension always have to store the modules it wants to<br>
> be sure to access at the beginning of a file it requires, making sure<br>
> not to choose overlapping names?<br>
<br>
</div>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…).<br>
<br>
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).<br>


<br>
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).<br>


<div class="HOEnZb"><div class="h5"><br>
Daniel<br>
<br>
<br>
<br>
_______________________________________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" target="_blank">http://lists.ocaml.org/listinfo/platform</a><br>
</div></div></blockquote></div><br>