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

[Malcolm Matalka]

I'm not paying attention as well as I should be to this thread, but what
you said reminded me of something I'd thought about, maybe it's really
ignorante, but it would be nice if I could do access modules from a
'root' name, kind of like DNS.  So if I have opened Core.Std I can
access the old 'lists' module by doing '.List' or something.  This would
require camlp4 modules to be written intelligently, but the ability would
ensure they know which module they are getting.

Just a thought,
/M

Anil Madhavapeddy <anil at recoil.org> writes:

> There's one scenario which absolutely requires the ability to explicitly open a particular namespace: camlp4 code generation.
>
> Right now, several camlp4 extensions break because they use modules from the standard Pervasives library, and have no way to explicitly state that.  If Core.Std is opened, then compilation fails.  
>
> The two workarounds are:
> - hack the build system to pass -pp options to the camlp4 generator. Painful.
> - have some facility to explicitly open 'Caml_std' or 'Core_std' locally, irrespective of the current module environment.
>
> I believe namespaces addresses the latter workaround.
>
> -anil
>
> On 22 Feb 2013, at 10:39, Daniel Bünzli <daniel.buenzli at erratique.ch> wrote:
>
>> This may be a silly suggestion as I'm not sure I'm really convinced by the absolute *need* for namespaces (I'd rather not have an
>> additional concept in a language that I already find sufficiently complex to my taste).
>> 
>> However it strikes me that while it seems to be agreed upon that a simple mechanism like `-pack` solves the problem albeit not in a
>> technically satisfying way, the worked out proposal seems to skyrocket into complexity. The best way to avoid bureaucracy/complexity is
>> not to introduce the tools to be able to manage it...
>> 
>> So if the problem is `-pack` is not good enough because it produces a huge `cmo`, why not just try to find a corresponding concept workable with `cm[x]a` ?  
>> 
>> Here's a proposal --- from a user point of view, I'll let the compiler hackers comment on how/if this could be workable.
>> 
>> Introduce `cmia` files that bundles the `cmi`'s of a `cm[x]a` with the corresponding file name. The name of the `cmia` file (and hence of
>> the `cm[x]a` file) defines your toplevel module name à la `-pack`. Make it even be backward compatible in the sense that if there's no
>> cmia` for a `cm[x]a` the modules are accessed as before. Now you have a kind of `-pack` that work with `cm[x]a`.
>> 
>> Best,
>> 
>> Daniel
>> 
>> P.S. flat vs hierarchical, I'd also rather go flat.
>> 
>> 
>> _______________________________________________
>> Platform mailing list
>> Platform at lists.ocaml.org
>> http://lists.ocaml.org/listinfo/platform
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform