warning on value shadowing

warning on value shadowing

[Sam Steingold]

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.

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

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

[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: warning on value shadowing

[Sam Steingold]

David Brown wrote:
> 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.

It is also an error in Lisp - although there is a well defined way to 
avoid the error by explicitly specifying who shadows what.
http://www.lisp.org/HyperSpec/Body/fun_shadow.html
http://www.lisp.org/HyperSpec/Body/sec_11-1-1-2-5.html

I think there is a way to treat warnings as errors, so this is covered.

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

it should be possible to separate 4 situations:
1 cross-module shadowing (warning)
2 redefining a global value in the same file (warning)
3 shadow a global value with a local one (warning)
4 redefine a local value as in your example (no warning)
the warnings can be made optional; one may be able to enable them 
separately (one by one) etc.

Sam.

Re: [Caml-list] Re: warning on value shadowing

[David Brown]

Sam Steingold wrote:

>> The problem with this as a warning, is that outside of multiple
>> modules, this scenario is fairly common:
>>
>>   let x = ...
>>   let x = ... x ...
>>

> 3 shadow a global value with a local one (warning)
> 4 redefine a local value as in your example (no warning)

I guess my example was a little ambiguous.  Those were meant to be
top-level bindings.  I've seen this construct fairly commonly.  It is
especially useful when making something that wraps around another
call, adding a bit more functionality.

Dave

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

[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

[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

[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

[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: warning on value shadowing

[Sam Steingold]

Jon Harrop wrote:
> 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.

of course there should be a way to tell the compiler that the shadowing 
is intentional.

Re: warning on value shadowing

[Sam Steingold]

Jacques Garrigue wrote:
> 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?

you are not using it NOW, but you might in the future, at which point 
you will all of a sudden have to refactor your code to avoid the 
warning. I would rather see the shadowing warning the moment I add "open 
Foo" for the first time.

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

you should be able to say something like
shadow Foo.bar with Baz.bar

> How bad is the problem in practice?

horrible.

silent shadowing is one of those "low probability -- high consequences" 
situations. the fact that you personally have never had to spend hours 
chasing a stupid bug that should have been uncovered by the compiler 
does not mean that silent shadowing is good practice.

> As for the 3rd case, I'm not sure what you are pointing at.

bar.ml defines zot.
foo.ml contains this:
	open Bar
	let zot = 1
compiling foo.ml should warn me that foo shadows Bar.zot.

Sam.

Re: [Caml-list] Re: warning on value shadowing

[skaller]

On Fri, 2007-02-23 at 15:51 -0500, Sam Steingold wrote:
> Jacques Garrigue wrote:

> > The first one is clearly overkill: if nobody uses zot, then who cares?
> 
> you are not using it NOW, but you might in the future, at which point 
> you will all of a sudden have to refactor your code to avoid the 
> warning. I would rather see the shadowing warning the moment I add "open 
> Foo" for the first time.

Once perhaps. After that you'd be demanding a way to turn it off
for that case.

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

Re: [Caml-list] Re: warning on value shadowing

[Sam Steingold]

> * skaller <fxnyyre@hfref.fbheprsbetr.arg> [2007-02-24 14:31:45 +1100]:
>
> On Fri, 2007-02-23 at 15:51 -0500, Sam Steingold wrote:
>> Jacques Garrigue wrote:
>
>> > The first one is clearly overkill: if nobody uses zot, then who cares?
>> 
>> you are not using it NOW, but you might in the future, at which point 
>> you will all of a sudden have to refactor your code to avoid the 
>> warning. I would rather see the shadowing warning the moment I add "open 
>> Foo" for the first time.
>
> Once perhaps. After that you'd be demanding a way to turn it off
> for that case.

of course, there must be a way to clearly specify that I expect Foo.bar
to shadow Zot.bar so that I will not be bothered zbout bar again.

-- 
Sam Steingold (http://sds.podval.org/) on Fedora Core release 6 (Zod)
http://memri.org http://ffii.org http://pmw.org.il http://camera.org
http://palestinefacts.org http://dhimmi.com http://israelunderattack.slide.com
nobody's life, liberty or property are safe while the legislature is in session