Re: [Caml-list] warning on value shadowing

Re: [Caml-list] warning on value shadowing

[David Allsopp]

> On Wednesday 21 February 2007 20:41, Sam Steingold wrote:
> > 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).
>
> I think this is such a common style (I use shadowing deliberately all the 
> time) that it would be very annoying to be warned about it.

I agree --- local shadowing is too useful a programming style to have
warnings issued. Though redefining a value at global level is possibly worth
having a warning about.

IMHO Pervasives is the only module that should be opened --- renaming a
module with "module Foo = SomeVeryLongModuleNameYouDontWantToTypeLots" is
better (makes clearer code) than "open ... ". But that's just another
opinion...

Re: [Caml-list] warning on value shadowing

[skaller]

On Wed, 2007-02-21 at 22:56 +0000, David Allsopp wrote:

> IMHO Pervasives is the only module that should be opened --- renaming a
> module with "module Foo = SomeVeryLongModuleNameYouDontWantToTypeLots" is
> better (makes clearer code) than "open ... ". But that's just another
> opinion...

I open every module I use as a matter of principle.
This makes the body code independent of modular refactoring.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] warning on value shadowing

[Jon Harrop]

On Wednesday 21 February 2007 22:56, David Allsopp wrote:
> IMHO Pervasives is the only module that should be opened --- renaming a
> module with "module Foo = SomeVeryLongModuleNameYouDontWantToTypeLots" is
> better (makes clearer code) than "open ... ". But that's just another
> opinion...

I wish Printf was opened by default. I abhore the hideous verbosity of 
Print.fprintf "Hello world!". My fingers ache just thinking about it...

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] warning on value shadowing

[Wolfgang Lux]

David Brown wrote:

> The other odd difference is that in Haskell, importing puts the names
> into the current module.  If the current module is exporting
> everything, then these names will be exported from it as well.

I know this is getting off-topic, but the above statement is not  
correct.
Haskell by default exports only the top-level definitions of a module.
You have to mention any imported entities that you want to export from
a module explicitly in its export list.

Regards
Wolfgang

Re: [Caml-list] warning on value shadowing

[David Brown]

Jacques Garrigue wrote:

> 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.

You can import in Haskell as qualified, which is frequently done with
shorter names.

  import qualified LongName as L

and then use L.foo

It also allows other tricks such as
  import qualified LongName as L
  import LongName (baz)

which will import the symbol 'baz' from LongName, and the rest of
LongName is accessed qualified (L.foo).

This kind of stuff can be done in OCaml too, but gets tedious,
especially with types.

The other odd difference is that in Haskell, importing puts the names
into the current module.  If the current module is exporting
everything, then these names will be exported from it as well.

Dave

Re: [Caml-list] warning on value shadowing

[Jacques Garrigue]

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

Re: [Caml-list] warning on value shadowing

[skaller]

On Wed, 2007-02-21 at 13:51 -0800, David Brown wrote:

> >>> Proposal: When both foo.ml and bar.ml define zot and quux.ml opens
> >>> both Foo and Bar, there should be a warning [..]

> One could also argue that this condition is an error.  

IMHO, only an error on use of the ambiguous name.
It should be a hard error then. It can be resolved
by qualification.

I don't believe this is inconsistent with deliberate
hiding like let x = e in let x = x + 1 in .. indeed
this can also be used to resolve a conflict:

open A
open B
let x = A.x 

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] warning on value shadowing

[Jon Harrop]

On Wednesday 21 February 2007 20:41, Sam Steingold wrote:
> 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).

I think this is such a common style (I use shadowing deliberately all the 
time) that it would be very annoying to be warned about it.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists

Re: [Caml-list] warning on value shadowing

[David Brown]

Sam Steingold wrote:
> Christian Lindig wrote:
>>
>> On Feb 21, 2007, at 9:41 PM, Sam Steingold wrote:
>>
>>> Proposal: When both foo.ml and bar.ml define zot and quux.ml opens
>>> both Foo and Bar, there should be a warning [..]
>>
>> While I see your concern I think open is best avoided.
>
> Yes, of course.  Alas, I am not at liberty to arbitrarily and
> pervasively change a huge code-reviewed project to satisfy my
> stylistic preferences.  I just see no reason for the compiler not to
> issue such a warning.

One could also argue that this condition is an error.  The closest
equivalent in Haskell is erroneous (only when the symbol is
referenced).  Of course Haskell gives a lot more control over the
importing or names, and is declarative, so it isn't equivalent at all.

The problem with this as a warning, is that outside of multiple
modules, this scenario is fairly common:

  let x = ...
  let x = ... x ...

Since ocaml uses the most recent declration, this is well defined, as
it is with multiple 'open's.

Dave

Re: [Caml-list] warning on value shadowing

[Sam Steingold]

Christian Lindig wrote:
> 
> On Feb 21, 2007, at 9:41 PM, Sam Steingold wrote:
> 
>> Proposal:
>> When both foo.ml and bar.ml define zot and quux.ml opens both Foo and 
>> Bar, there should be a warning [..]
> 
> While I see your concern I think open is best avoided.

Yes, of course.
Alas, I am not at liberty to arbitrarily and pervasively change a huge 
code-reviewed project to satisfy my stylistic preferences.
I just see no reason for the compiler not to issue such a warning.

Thanks for you comment.

Sam.

Re: [Caml-list] warning on value shadowing

[Christian Lindig]

On Feb 21, 2007, at 9:41 PM, Sam Steingold wrote:

> Proposal:
> When both foo.ml and bar.ml define zot and quux.ml opens both Foo  
> and Bar, there should be a warning [..]

While I see your concern I think open is best avoided. To still enjoy  
the convenience of  short names, consider writing this in quux.ml:

module F = Foo
module B = Bar

	F.zot ... B.zot

Voilà, no name clashes or shadowing.

-- Christian