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

[Gabriel Scherer]

I think that to help tooling (and programmers) we could allow explicit
disambiguation of capitalized names (as mentioned in spec.pdf).

The idea is that while "X" may refer to either an internal module
defined in the program (or introduced in scope by an "open module") or
a compilation unit name, ".X" can only be an internal module, while
"..X" (I'm reusing Alain's proposed .. notation here) can only be a
compilation unit name.

So, to reuse Alain's example,

  module X = struct let x = 1 end
  open namespace Foo
  let a = X.x

would be ambiguous, but

  module X = struct let x = 1 end
  open namespace Foo
  let a = .X.x

or

  module X = struct let x = 1 end
  open namespace Foo
  let a = ..X.x

would not.

(I'm again not talking about the concrete syntax here: . or .. would
create ambiguities, for example "Some .X.bar". But merely the idea to
get rid of the syntactic ambiguity between external and internal
modules, which allows careful users to make "ocamldep" trivially
correct without any approximation.)

On Tue, Mar 19, 2013 at 11:38 AM, Leo White <lpw25 at cam.ac.uk> wrote:
> Alain Frisch <alain.frisch at lexifi.com> writes:
>
>> Two more comments on Leo's proposal:
>>
>> 1. I think we should look for a different notation than Foo # Bar for namespace qualification.  "#" is already used for
>> the method calls; it should be possible to implement this notation without creating conflicts in the grammar, but it
>> might create confusion.  Consider the expression:
>>
>>   Foo#Bar.my_object # f Foo#Bar.e
>>
>> (I've been kind enough to avoid putting whitespaces around '#' when used for namespaces).
>
> While I'm certainly not against a different notation, I would point out
> that this example is no worse than:
>
>     Foo.Bar.my_record . f Foo.Bar.e
>
> which is currently a valid expression.
>
>> I haven't really thought about a good alternative, but what about using ".." instead of "#" ?
>
> To me Foo..Bar looks like some kind of range.
>
>> 2. I think we should get rid of the aliasing feature in search path files ("Foo#Baz : Foo#Bar").  I expect that only
>> advanced users will write search path files, and then can do the
>> resolution themselves (or this could be automated).
>
> This would prevent one package from providing aliases for modules in
> another package. It is much safer to provide an alias to Core#Mutex than
> to provide one to core-mutex.cmi and hope that Jane Street doesn't
> change its file name.
>
>> Aliases don't really simplify the life of end-users and they add complexity to the resolution mechanism (which might
>> need to be re-implemented by build systems).
>
> The complexity added is minuscule.
>
> As I have previously proposed, ocamldep (or some other tool) would
> support the following use:
>
>     ocamldep -lookup Foo#Baz foo.mlpath
>
> This would lookup Foo#Baz within the search path file "foo.mlpath", if
> it finds a mapping then it returns that mapping.
>
> So the lookup logic is:
>
>     name := Foo#Baz
>     while there are more paths
>         if !path is a directory then
>             check for file named !name in !path
>             if it found a file then
>                 return the filename
>         else !path is a file
>             run "ocamldep -lookup !name !path"
>             if it found a mapping
>                 if mapping was a filename then
>                     return the filename
>                 else mapping was an alias
>                     name := !alias
>
> So aliases add a single if condition.
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform