[ocaml-platform] Followup to Leo's proposal

[Yaron Minsky]

On Tue, Mar 12, 2013 at 2:41 PM, Alain Frisch <alain.frisch at lexifi.com> wrote:
> On 3/12/2013 2:29 PM, Yaron Minsky wrote:
>>
>> I agree this would be useful for many uses --- the DSL case is a
>> particularly important one.  My only point is that it does not in my
>> mind obviate the need to have auto-opens attached to namespaces.
>
>
> Agreed.  I believe those are two independent features.  I'm in favor of
> allowing auto-open on the command-line; and I don't really mind about having
> auto-opens attached to namespaces. That said, as Gabriel, I really don't
> like the idea of relying on shadowing to hide/redefine some declarations;
> and I'd actually like to have warnings when I use such ambiguous identifiers
> whose resolution depend on the ordering of opens (implicit or not).  (For
> the case of shadowing local identifiers, I'm less sure...)
>
> Instead of hiding some identifiers from the stdlib, wouldn't it be more
> robust to compile all your code with -nostdlib and expose in Core.Std all
> identifiers which you allow to use?

I agree that would be better for the stdlib case, and in some other
cases as well.  I suspect once we have namespaces, we may do just
what you propose.

But sometimes, shadowing is just what the doctor ordered.  For
example, I very much like the idiom of doing:


   let open Result.Monad_infix in
   ....

as a way of changing the monadic operators in force in some local
scope.  And I think there's something to be said for uniformity.
Shadowing is the order of the day in OCaml, and having namespaces
behave materially differently in this regard is going to be
surprising.

My primary point isn't that shadowing is good, though.  I do
understand the problems of shadowing, and having warnings for
shadowing seems reasonable.

My main point is that namespace control should by and large be
explicit in the source --- e.g., choosing whether or not you open the
Async#Common module in the build system is problematic, because it
hides this very salient semantic fact from the reader of the program.

y