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

[Gabriel Scherer]

> I would somewhat prefer more flexibility for auto-open modules (i.e.,
> allow for the specification of multiple modules to open, of arbitrary
> name, and allow for merge operations to open both, in order, rather
> than just one), and I don't really understand why this more limited
> version is preferable; but I don't mind enough to fight.

I tend to agree that the semantics I proposed in my email, that allows
arbitrary "open lists" and in particular proper merging, would be a
better choice.

Leo's main argument is that systematically using Pervasives is more
predictable for users (that may not want to have to look at namespace
descriptions to know which compilation units will be opened by
default).
I'd say in practice it's rather obvious at medium scale (for any given
software project) which module is meant to be the
Pervasives/Std/Prelude one, and large scale composability by default
could be a better choice. But for large-scale composability of
namespaces I believe more in the hierarchical model than in merging
all namespaces, anyway.

On Mon, Mar 18, 2013 at 2:51 PM, Yaron Minsky <yminsky at janestreet.com> wrote:
> Got it.  That matches my initial mental model.  Just to be explicit:
>
>     open namespace Core
>     open namespace Async
>
> Will lead to separate opens of the Core and Async Pervasives modules.
>
> I would somewhat prefer more flexibility for auto-open modules (i.e.,
> allow for the specification of multiple modules to open, of arbitrary
> name, and allow for merge operations to open both, in order, rather
> than just one), and I don't really understand why this more limited
> version is preferable; but I don't mind enough to fight.  This
> solution seems like it would solve the use cases that I am aware of.
>
> y
>
> On Mon, Mar 18, 2013 at 9:28 AM, Gabriel Scherer
> <gabriel.scherer at gmail.com> wrote:
>> This is fine: it will desugar into:
>>
>>   open namespace Core
>>   open Pervasives (* line produced only if Core#Pervasives exists *)
>>   let () = printf "Hello world!\n"
>>   open namespace Async
>>   open Pervasives (* line produced only if Async#Pervasives exists *)
>>   let () = printf "Hello world!\n"
>>
>> You would be in trouble if you defined a CorePlusAsync namespace as, say
>>    include "core.ns"
>>    include "async.ns"
>>
>> and then did
>>    open namespace CorePlusAsync
>>
>> it would desugar into
>>    open namespace CorePlusAsync
>>    open Pervasives
>>
>> which is equivalent to
>>    open namespace CorePlusAsync
>>    open Async#Pervasives
>>
>> and not
>>    open namespace CorePlusAsync
>>    open Core#Pervasives
>>    open Async#Pervasives
>>
>> On Mon, Mar 18, 2013 at 1:55 PM, Yaron Minsky <yminsky at janestreet.com> wrote:
>>> It occurs to me I just don't understand the semantics of this.  What
>>> happens if I do this:
>>>
>>>     open namespace Core
>>>     let () = printf "Hello world!\n"
>>>     open namespace Async
>>>     let () = printf "Hello world!\n"
>>>
>>> or, for that matter:
>>>
>>>     open namespace Core
>>>     let () = printf "Hello world!\n"
>>>     let open namespace Async in
>>>     printf "Hello world!\n"
>>>
>>> Async and Core have different definitions of printf, as it happens.
>>> Which gets called in these cases?
>>>
>>> y
>>>
>>> On Mon, Mar 18, 2013 at 8:34 AM, Leo White <lpw25 at cam.ac.uk> wrote:
>>>>> Can the case of both Core and Async (and opening both of their
>>>>> pervasives modules) be handled here?  This seems to me to be of
>>>>> fundamental importance.  If that's missing, then I misunderstood
>>>>> the proposal.
>>>>
>>>> Yes that is fine. It just means that if you made a new namespace by
>>>> merging the Core namespace with the Async namespace then the Pervasives
>>>> module of one would shadow the Pervasives module of the other.
>>>> _______________________________________________
>>>> Platform mailing list
>>>> Platform at lists.ocaml.org
>>>> http://lists.ocaml.org/listinfo/platform
>>> _______________________________________________
>>> Platform mailing list
>>> Platform at lists.ocaml.org
>>> http://lists.ocaml.org/listinfo/platform