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

[Alain Frisch]

On 02/27/2013 05:31 PM, Yaron Minsky wrote:
> Let me try to summarize the current situation about the argument
> between Alain, Leo and myself.  I think Leo and I are roughly on the
> same page, but I may be missing things.
>
> - MAKING LONG NAMES AVAILABLE.  Alain prefers to have unambiguous long
>    names that are usable in a first class way.  I find this mildly
>    distasteful, but would be OK with it as long as it was well hidden
>    from the user by default.  Long names shouldn't show up by default
>    in source files, error messages or documentation.  I view this as
>    quite important for usability of namespaces.

I don't understand how the user is supposed to interpret names in error 
messages or documentation without explicitly qualified names.  It is ok, 
indeed, to assume that within the documentation of Core, references to 
its "List" module are written as "List", but then references to other 
List modules from other libraries would need to use their long names, 
right?   If another library, not part of Core, references types from 
Core_list, should we use simply "List" in its documentation?  Maybe, 
because Core is intended to be a real replacement of the stdlib, but 
this would perhaps not apply to other libraries, and it should certainly 
not be the default to always use short names for external references.

Being able to say for a given unit which name mapping is in scope is 
useful.  This allows ocamldoc and error messages to use this mapping to 
use short names.  But there is also the request of being able to import 
a name mapping locally, for a sub-structure or locally in a function. 
While I understand this can be useful as a convenience for the 
programmer (example: a tool which needs to use locally the compiler-libs 
could import "ocaml.ns" in a restricted scope), I think it would create 
confusion to use those local mapping to shorten error messages.


> - SOURCE-LEVEL OPENS.  Alain would prefer to have namespace
>    manipulations restricted to the command line, and therefore the
>    build system.  He thinks of namespaces as something that should be
>    used pretty rarely (or at least, there should be very few
>    namespaces), and it's therefore OK to push them to the outside.

This does not completely reflect my position.  My initial proposal was 
about an "open namespace" statement which imports module aliases from a 
.ns file locally.  I've then restricted this proposal to only allow 
importing .ns file globally, and to do that on the command-line in order 
to make the use of "stdlib replacements" as transparent as the official 
stdlib for programmers.  I thought this would be a good thing for Core. 
  Now Leo and you have convinced me that (i) being able to import .ns 
file locally is also quite useful; (ii) allowing to specify global .ns 
file on the command-line is neither necessary nor a good idea.  So let 
me retract my simplified proposal and stick to the original one.

That said, I still believe that one needs a way to tell for instance 
ocamldoc which .ns files to use to shorten references when generating 
the documentation for a given module.  And I believe it would be 
extremely confusing for users to allow to use different .ns files on the 
same page, depending on "open .ns" statements in the .mli file.  So 
either ocamldoc should get this information from the command-line, or it 
should find in the source code itself.  I don't really care, as long as 
this is restricted to a global choice for a given unit.

> - NAMESPACES WITH VALUES.  I have argued for allowing the opening of a
>    namespace to also implicitly open some modules, this essentially
>    adding values to the search path in addition to modules.  I would be
>    sad to lose this feature, but I don't think it's absolutely
>    essential.

I've a preference for keeping independent notions as separate in the 
language design even if they are commonly used together.  But I agree, 
this is a non fundamental issue.



Alain