Re: [Caml-list] warning on value shadowing

[Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>]

From: Sam Steingold <sds@gnu.org>
> Proposal:
> When both foo.ml and bar.ml define zot and quux.ml opens both Foo and 
> Bar, there should be a warning (when compiling quux) about Foo.zot being 
> shadowed by Bar.zot (or vice versa, depending on the order of the open 
> statements).
> If you think this is an overkill, please at least consider issuing the 
> warning when zot is used in quux.ml.
> If you think that is also an overkill, please at least consider issuing 
> the warning when foo=quux.

The first one is clearly overkill: if nobody uses zot, then who cares?
The second one might be useful, but it creates some problems.
For instance, it is common practice to open Format or Unix, and have
them intentionally shadow definitions from Pervasives. Should we make
an exception for that? But it is not so infrequent to do it  with
other modules too (for instance open Printf, then Format). For this to
be practical, the language would have to be enriched with finer grain
control on imports.
It has been mentionned that many other languages, including Lisp and
Haskell, have warnings or errors with such situations, but there are
some differences too. Compared with Lisp, in ocaml the typing avoids
most errors: if you forgot shadowing, you will most often get a type
error. Haskell has types too, but it also has overloading, which
confuse things a bit, and IIRC there are no qualified identifiers,
when you want to make explicit which definition you want to use.

How bad is the problem in practice? My experience is not so bad.
My most common gripe is that when I open Unix, it shadows
Pervasives.stdin, and I get type errors... but this is the intended
behaviour. I do not remember any situation where the shadowing by a
definition with the same type created a semantical error. If I had
such an experience, I would probably react like you at first, but
then, as other suggested, there are programming styles that avoid this
kind of problems.

As for the 3rd case, I'm not sure what you are pointing at. You mean
shadowing a definition done in the current module by using open? In
general, it is suggested to do all the open's at the beginning of the
module, except when you intentionnally want to change the namespace
somewhere.

Jacques Garrigue