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
Current wording is "A fixity declaration may appear anywhere that a type
signature appears and, like a type signature, declares a property of a
particular operator. Also like a type signature, a fixity declaration
can only occur in the same declaration group as the declaration of the
operator itse
Koen Claessen wrote
> However, it is not possible to define the fixity of an
> operator which is an argument to a function. If I define:
>
> foldr4 :: (a -> b -> b) -> b -> (a,a,a,a) -> b
> foldr4 (#) z (a,b,c,d) = a # b # c # d # z
>
> I will have to put in parentheses explicitly, because
Hi all,
The topic is fixity declarations for operators.
The report says:
"Fixity is a property of a particular entity (constructor
or variable), just like its type; fixity is not a
property of that entity's name."
It is possible to define fixities for locally declared
bindings:
f x
"Simon Peyton-Jones" wrote
> | For instance if a have
> |
> | module A where
> | data T = A | B
> |
> | which entities are imported when I include the declaration
> |
> | import A hiding(T)
> |
> | in a module? The report is not clear about this but I would
> | expect that
> | this
See Section 4.4.2, after the table. Does that answer the qestion?
Simon
| -Original Message-
| From: S. Alexander Jacobson [mailto:[EMAIL PROTECTED]]
| Sent: 12 July 2001 15:03
| To: [EMAIL PROTECTED]
| Cc: [EMAIL PROTECTED]
| Subject: Re: Another question wrt hiding imports
|
|
| I
I asked this a while ago and never got an answer. Asking again in
better context:
How do you control importing operator precedence?
Suppose that you have:
f x = 2 + 2 * x
And an imported module increases the precedence of (+).
You end up getting mangled.
My assumption is that the only way to
| For instance if a have
|
| module A where
| data T = A | B
|
| which entities are imported when I include the declaration
|
| import A hiding(T)
|
| in a module? The report is not clear about this but I would
| expect that
| this imports data constructors A and B into the current
After the recent discussion import hiding clauses in import
declarations, I was wondering what the meaning of hiding clauses is in
the case of algebraic data types (or classes).
For instance if a have
module A where
data T = A | B
which entities are imported when I include the declarati
| 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
18 matches
Mail list logo
