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.
next prev parent 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