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

Yaron Minsky yminsky at gmail.com
Tue Mar 19 10:57:49 GMT 2013


I agree with Leo that this seems like an awkward departure from the
semantics of naming elsewhere in OCaml.

For what it's worth, most of the time, namespace declarations will
happen only at the beginning of a file, at which point Alain's
semantics don't change anything.  I think that means that the
precision he is looking for can most of the time be obtained without
changing the semantics in the way he describes.

y

On Tue, Mar 19, 2013 at 6:11 AM, Leo White <lpw25 at cam.ac.uk> wrote:
>> Consider the following piece of code:
>>
>>  module X = struct let x = 1 end
>>  open namespace Foo
>>  let a = X.x
>>
>> and assume that there is a module Foo#X.  Would X.x refer to this module, or to the one defined defined on the first
>> line?
>>
>
> While the second semantics may be easier to implement, it would be
> completely counter-intuitive to OCaml programmers.
>
>> [...] I see only two ways to implement the first semantics:
>>
>>     - Scan the search path for all foo-*.cmi files when processing the "open namespace" statement (i.e. use Sys.readdir,
>> and not only Sys.file_exists as today), in addition to the search path files.  This would probably work ok with most
>> current build systems, but it would prevent from doing "live" discovery of dependencies by instrumentation of system
>> calls (I've created a few years ago a toy build tool based on capturing calls to open/stat though LD_PRELOAD, and it
>> worked quite well).
>>
>>     - Completely change the representation of the typing environments to maintain a list of "layers" made either of
>> local scopes or namespace opens.
>>
>
> 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.
>
>>   (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.
>
>>   (iii) It makes dependency analysis more precise (and code easier to read).  In the example above, ocamldep knows (with
>> the second semantics) that there is no dependency to an external unit X.
>
> This is no worse than how ocamldep currently handles modules contained
> within other modules.
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform


More information about the Platform mailing list