caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Sam Steingold <sds@gnu.org>
To: caml-list@inria.fr
Cc: Christian Lindig <lindig@cs.uni-sb.de>, Caml List <caml-list@inria.fr>
Subject: Re: warning on value shadowing
Date: Wed, 21 Feb 2007 17:04:24 -0500	[thread overview]
Message-ID: <45DCC1E8.3050807@gnu.org> (raw)
In-Reply-To: <45DCBEED.10706@davidb.org>

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.


  reply	other threads:[~2007-02-21 22:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-21 20:41 Sam Steingold
2007-02-21 20:57 ` [Caml-list] " Christian Lindig
2007-02-21 21:10   ` Sam Steingold
2007-02-21 21:51     ` David Brown
2007-02-21 22:04       ` Sam Steingold [this message]
2007-02-21 22:13         ` [Caml-list] " David Brown
2007-02-21 23:15       ` [Caml-list] " skaller
2007-02-21 22:25 ` Jon Harrop
2007-02-23 20:40   ` Sam Steingold
2007-02-22  0:54 ` [Caml-list] " Jacques Garrigue
2007-02-22  1:09   ` David Brown
2007-02-23 15:12     ` Wolfgang Lux
2007-02-23 20:51   ` Sam Steingold
2007-02-24  3:31     ` [Caml-list] " skaller
2007-02-25  0:23       ` Sam Steingold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45DCC1E8.3050807@gnu.org \
    --to=sds@gnu.org \
    --cc=caml-list@inria.fr \
    --cc=lindig@cs.uni-sb.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).