From: Sam Steingold <sds@gnu.org>
To: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
Cc: caml-list@inria.fr
Subject: Re: warning on value shadowing
Date: Fri, 23 Feb 2007 15:51:35 -0500 [thread overview]
Message-ID: <45DF53D7.4090007@gnu.org> (raw)
In-Reply-To: <20070222.095436.125900161.garrigue@math.nagoya-u.ac.jp>
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.
next prev parent reply other threads:[~2007-02-23 20:51 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
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 [this message]
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=45DF53D7.4090007@gnu.org \
--to=sds@gnu.org \
--cc=caml-list@inria.fr \
--cc=garrigue@math.nagoya-u.ac.jp \
/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