[ocaml-platform] Is this mandatory to continue this discussion [was: on the need and design of OCaml namespaces]

[Sylvain Le Gall]

Hi,

We almost reach 60 mails in this thread, withouth any clear consensus.

My take on this:
We could build a first version of the platform WITHOUT namespaces. So
lets focus on building a first version (choosing packages, setting up
infrastructure, packaging, testing, website et al)

We will have plenty of time to discuss namespace after a first platform release.

My 2nd take on this:
Put this to vote !
With the following proposals:
A. Implement rich namespace
B. Implement simple flat namespace
C. Fix -pack issue rather than implementing namespace
D. Postpone discussion

Regards
Sylvain

2013/2/26 Wojciech Meyer <wojciech.meyer at gmail.com>:
> Hi Daniel,
>
> I appreciate your strong stand that we should not introduce redundant
> concepts to the language. I can understand that concept of module can
> give the impression of managing compilation units. However I think this
> is where the similarities end. Given the semantics of OCaml module
> system, that each module is separate compilation unit - it's hard to say
> it's flexible enough to cover functionality of namespaces which scale up
> across the boundaries of compilation units. All the technical problem of
> -pack are because modules are not namespaces. So why not to fix it
> properly?
>
> In ML world the smallest abstraction available is function, that scale
> up to the level of modules, then we have modules that scale up to the
> library level, and then we have an empty place that we try to structure
> using modules. It would be natural to think that at the library level,
> we should not use modules for abstracting and structuring things.
>
> If you are still not sure, please see what SML community have done many
> years ago with their compilation manager:
>
> http://www.smlnj.org/doc/CM/index.html
>
> This is an interesting paper. I don't literally repeat what is inside -
> as I read this quite long time ago, but it covers a lot more than just
> namespace management.
>
> Hope this will make your more confident.
>
> Daniel Bünzli <daniel.buenzli at erratique.ch> writes:
>
>> Le vendredi, 22 février 2013 à 17:40, Leo White a écrit :
>>> There is no real reason that something cannot be placed in two locations
>>> within the hierarchy.
>>
>> But as I suggested from the perspective of programming *in the
>> language* there no point of having it at two different location. Even
>> from the perspective of reading code it's confusing you have to learn
>> all the places where a module may be and understand that all these
>> modules are in fact the same.
>>
>>> I agree with this in general. However, there are some specific cases where
>>> a hierarchical namespace is very useful. For example:
>>>
>>> 1. In some very large libraries, it is useful to be able to divide the
>>> modules into sub-components that can opened individually.
>>>
>>> 2. In some libraries it is useful to provide multiple versions of some
>>> components (e.g. Foo.Async.Io and Foo.Lwt.Io).
>>
>> For me all this should be solved within the realm of the module
>> system. Maybe we need to fix the way we link things in (since that
>> seems to be the only reason why -pack is not deemed reasonable). But I
>> really see no point in introducing new namings mechanisms into the
>> core language.
>>
>> Daniel
>>
>>
>
> --
> Wojciech Meyer
> http://danmey.org
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform