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

[Gabriel Scherer]

So in this case you would have to look for list.cmi, std.cmi then core.cmi
(if you don't know which are namespaces, and which are actual compilation
unit names).

One problem with this proposal is that the compiler has no knowledge of the
set of "existing" namespaces. This combines very badly with the
module/namespace syntactic ambiguity: when you write "open Lsit" (List,
with a typo), the compiler will silently accept the opening of the Lsit
namespace. I formalized this semantics in an earlier proposal, but Fabrice
noticed that this was quite bad from an user interface point of view, and
further proposals used a model with "existing" namespaces and
"non-existing" namespaces -- in the current proposal linked above, the
compiler consults an explicit hierarchical mapping.
(Removing the syntactic ambiguity makes this slightly less of a problem,
but it's still a pain to not be warned of namespace typos.)

On Thu, Feb 21, 2013 at 5:01 PM, Leo White <lpw25 at cam.ac.uk> wrote:

> On Feb 21 2013, Gabriel Scherer wrote:
>
>  How would one specify which search path is associated to a given namespace
>> path (eg. Core.Std)? Is it easy to integrate into ocamlfind?
>>
>>
> .cmi files would be looked up exactly as they are now, using the search
> path specified with -I options. The only difference is that when it finds a
> "list.cmi" file it checks if that file is attached to "Core.Std". If the
> file is attached to that namespace then it is used, otherwise the compiler
> keeps looking in the search path for more "list.cmi" files.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130221/74ec3e7e/attachment-0001.html>