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 qu
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
| 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 spea
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
>
"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 quali
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 ans
| 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
http://research.microsoft.
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
Haskell
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
| 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
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 rest
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 the
> 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
"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
> > shou
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 i
| | > 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. Her
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 _reve
| > 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
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 refere
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.
I was considering submitting this as a bug report in the Haskell'98
definition, but I don't know whether that is the appropriate
designation or not. In any case, I think it is probably caused by
a hang-over from a previous version of Haskell that never caught up
with the newer features added in '
21 matches
Mail list logo
