[ocaml-platform] Changes to my previous proposal for namespaces

[Yaron Minsky]

I'm not quite suggesting this seriously, because I haven't thought about
the consequences carefully, but what if there was a namespace called Local
that one could explicitly open that contained the modules in the local
directory?  Then one could write

open namespace Core
open namespace Local

to get the behavior you propose.  Or, you could do it in the other order if
that was the shadowing behavior that was preferred.

y
On Mar 19, 2013 7:37 AM, "Alain Frisch" <alain.frisch at lexifi.com> wrote:

> On 03/19/2013 11:11 AM, Leo White wrote:
>
>> Neither of these options seems particularly problematic to me. The
>> first one might be more in line with checking that some "foo-*.cmi"
>> exists when the Foo namespace is opened so that typos produce an error
>> or warning. But if Sys.readdir is a problem then the second option is
>> perfectly viable.
>>
>
> Sys.readdir is not currently a problem, but it might prevent alternative
> approaches to discovering dependencies.
>
> While perfectly viable, the second option will significantly complexify
> the definition of the typing environment.  We should carefully evaluate the
> impact on the size of .cmt files and on compilation time (in -bin-annot
> mode, in particular).
>
> If I had to choose, I'd probably use the first approach (Sys.readdir).
>
>     (ii) It allows to write more robust code w.r.t. to future additions to
>>> namespaces.  With namespaces, library authors
>>> won't hesitate to use "short" names for their modules and the risk is
>>> high that a "open namespace" statement hide local
>>> modules when the library is extended.
>>>
>>
>> This is basically just an argument against "open namespace" shadowing
>> things but, as Yaron has said, OCaml uses shadowing all the time and it
>> doesn't seem to have caused too many problems. If in doubt use explicit
>> references instead of opens.
>>
>
> People have carefully avoided to use common name for modules in libraries,
> in order to avoid name clashes.  With namespaces, this can changes.  And
> with the notion of namespaces being more open than module, it's even harder
> to be sure that opening a namespace will never shadow a local module. The
> same would actually apply to other units in the current project, not only
> local modules; so I'd actually propose to look for module in the local
> namespace -- whatever this means -- first.
>
> Concretely, if Core adds a new module Foo, this will break all projects
> using a local Foo module and which "open namespace Core".  A possible
> solution would be that Core ships many .mlpath files corresponding to
> module exposed in older releases, so that there is a way to ensure that
> "open namespace Core" does not bring more modules in scope than before.
>
>
> Alain
> ______________________________**_________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/**listinfo/platform<http://lists.ocaml.org/listinfo/platform>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20130319/7897082b/attachment.html>