| Even with option 2, there is scope for confusion. Import
| without qualified, imports both qualified and unqualified
| names, but adding the word qualified doesn't make any
| difference to the position of qualified names, but instead
| silently fails to import unqualified names.
True
|
Brian Boutel wrote
Option 2 is closer to what the syntax of imports, read as English, suggests
is intended, but, if it wasn't for that, I'd be promoting option 1.
The primary purpose of being able to restrict imports is to avoid name
clashes, and with qualified import there is no risk of a
Simon Peyton-Jones wrote:
| [..modules..] So here's the message anyway. I don't
| think it's controversial, since it's the outcome the
| cognoscenti were seeking, and no one else will care.
That is not true! I do care! :-)
Often, after having been bitten by a misunderstanding of the
| I have often tried, but never succeeded, to understand what
| the report says and at the same time unify it with what the
| particular compiler I was using actually implemented.
Could I ask you to try one more time, with the current draft report?
available at
Simon Peyton-Jones wrote:
| Could I ask you to try one more time, with the current
| draft report? available at
| http://research.microsoft.com/~simonpj/haskell98-revised
I did that before I wrote my e-mail.
| Can you suggest ways in which it could be made
| clearer? I've filled in the
Simon Peyton-Jones [EMAIL PROTECTED] writes:
I hope the Report now unambiguously states that
import M hiding (a,b,c)
import qualified M hiding(a,b,c)
imports exactly the same entities (namely all that M exports
except a,b,c), only in the latter case only the qualified names
Koen Claessen wrote
What I would like to see in the report are *examples*.
Namely what happens in each of the following cases:
Ok, let me try:
import A
visible: x, y, p, q, v, w, A.x, A.y, A.p, A.q, A.v, A.w
import A()
nothing imported
import A(x,y)
visible: x, y, A.x, A.y
| The behaviour I think you're describing seems by far the most
| useful thing do and the description in the report is now very
| clear, so this isn't an issue with anything you're proposing,
| just a observation that 'GHC implements it' isn't yet quite true.
True -- I'm fixing that as we
Simon Peyton-Jones wrote:
| There is still a
| strange asymmetry, too. Whereas adding qualified to import
| Modname ( a, b, c) doesn't change which entities are
| imported, just the ability to refer to them by unqualified
| names, adding qualified to import Modname hiding ( a, b,
| c) has
Wolfgang Lux wrote:
Brian Boutel wrote
Option 2 is closer to what the syntax of imports, read as English, suggests
is intended, but, if it wasn't for that, I'd be promoting option 1.
The primary purpose of being able to restrict imports is to avoid name
clashes, and with qualified
Folks
It seems that I forgot to send this message a couple of weeks ago.
Assuming that silence meant assent, I implemented the proposal below
in the report I put out yesterday. But in this case silence meant you
hadn't
been asked (an excellent way to reach consensus that I must remember
for
Option 2 is closer to what the syntax of imports, read as English, suggests
is intended, but, if it wasn't for that, I'd be promoting option 1.
The primary purpose of being able to restrict imports is to avoid name
clashes, and with qualified import there is no risk of a clash, so no need
for
| | Currently, you are permitted to write
| |
| | import A hiding (f)
| | import B as A (f)
| |
| | and this means that everything exported from module A is visible,
| | with the exception that function `f' is overridden by a different
| | definition from module B. Here, a
Simon Peyton Jones writes:
In short, an import *always* brings the entire *qualified*
set of names into scope. Hiding and revealing applies only
to unqualified names. I must say that I thought GHC implemented
this rule; if not I should fix it.
That's not my reading of the report, and it's
Simon Marlow [EMAIL PROTECTED] writes:
Simon Peyton Jones writes:
In short, an import *always* brings the entire *qualified* set of
names into scope. Hiding and revealing applies only to unqualified
names. I must say that I thought GHC implemented this rule; if not I
should fix it.
In short, an import *always* brings the entire *qualified* set
of names into scope. Hiding and revealing applies only to
unqualified names.
I agree with SimonM that this is not what the Report says. At one time
it may have done, but careful reading shows that only the qualified
names for
Malcolm Wallace writes:
I submit that the way `hiding' clauses are ignored is a vestige from
the days when it was not possible to have overlapped module renamings.
Now that overlapped renamings are possible, the `hiding' clauses
should be permitted to take effect.
I think you're right.
Malcolm Wallace wrote
Currently, you are permitted to write
import A hiding (f)
import B as A (f)
and this means that everything exported from module A is visible,
with the exception that function `f' is overridden by a different
definition from module B. Here, a reference to
| Currently, you are permitted to write
|
| import A hiding (f)
| import B as A (f)
|
| and this means that everything exported from module A is visible,
| with the exception that function `f' is overridden by a different
| definition from module B. Here, a reference to `A.f'
Malcolm Wallace wrote
However, if you are indeed correct, then we have an even stranger
situation:
import A (g)
brings only A.g into scope, but
import A hiding (f)
brings both A.f and A.g into scope! So `hiding' is doing the opposite
of hiding, and in fact _reveals_
20 matches
Mail list logo
