Ashley Yakeley wrote:
At 2002-04-08 12:45, Lennart Augustsson wrote:
I just just wanted to say that I agree with almost everything Conor said.
I find it a little odd that the extension to Haskell that allows explicit
forall
does not also allow you use explicit type application (and type
Hi
Lennart wrote:
I was referring to the expression language.
So this is already allowed:
f :: (forall a . a - a) - (b, c) - (c ,b )
f i (x,y) = (i y, i x)
I'd like to be able to have explicit type applications.
If we denote type application with infix # I'd like to write
f i (x, y)
At 2002-04-09 04:53, C T McBride wrote:
There's a plentiful supply of good examples arising naturally from
higher-hind polymorphism. * - * is full of functions with good
properties (eg being functorial or monadic) which aren't datatype
constructors. Haskell's inability to express them and to
I just just wanted to say that I agree with almost everything Conor said.
I find it a little odd that the extension to Haskell that allows explicit
forall
does not also allow you use explicit type application (and type lanbda).
-- Lennart
C T McBride wrote:
Hi
On Fri, 5 Apr 2002, Ashley
At 2002-04-08 12:45, Lennart Augustsson wrote:
I just just wanted to say that I agree with almost everything Conor said.
I find it a little odd that the extension to Haskell that allows explicit
forall
does not also allow you use explicit type application (and type lanbda).
What did you have in
Ashley Yakeley [EMAIL PROTECTED] writes:
[...]
-- which of these types are the same?
f1 = MkFoo undefined :: Foo Succ;
f2 = MkFoo undefined :: Foo Succ';
f3 = MkFoo undefined :: Foo Succ'';
f4 = MkFoo undefined :: Foo (Add (Succ Zero));
yeah, why not! Have them all be the same
Hi
On Fri, 5 Apr 2002, Ashley Yakeley wrote:
At 2002-04-04 05:57, C T McBride wrote:
...which would be very useful, but would probably have unpleasant
consequences for type inference...
To my mind, this is not a credible objection. The horse has already
bolted; there's no point in
At 2002-04-04 05:57, C T McBride wrote:
...which would be very useful, but would probably have unpleasant
consequences for type inference...
To my mind, this is not a credible objection. The horse has already
bolted; there's no point in trying to shut the stable door.
Perhaps I should say
It's a bug in GHC 5.02 and earlier; fixed in 5.03
Simon
| -Original Message-
| From: Hal Daume III [mailto:[EMAIL PROTECTED]]
| Sent: 04 April 2002 00:15
| To: Haskell Mailing List
| Subject: deriving over renamed types
|
|
| Why can't I do this:
|
| import FiniteMap
| type FM
Hi all,
At 2002-04-03 15:14, Hal Daume III wrote:
type FM = FiniteMap
type FM a b = FiniteMap a b
I wasn't aware there was (supposed to be) a difference
between these two declarations? Is there?
On Wed, 3 Apr 2002, Ashley Yakeley wrote:
type FM a b = FiniteMap a b
...This
| ...which would be very useful, but would probably have unpleasant
| consequences for type inference...
|
| To my mind, this is not a credible objection. The horse has
| already bolted; there's no point in trying to shut the stable
| door. The existing post-Hindley-Milner aspects of
Why can't I do this:
import FiniteMap
type FM = FiniteMap
instance (Show a, Show b) = Show (FiniteMap a b) where
show = show . fmToList
data X = X (FM Int Int)
deriving (Show)
if I replace
type FM = FiniteMap
with
type FM a b = FiniteMap a b
it works fine. I wasn't aware
At 2002-04-03 15:14, Hal Daume III wrote:
if I replace
type FM = FiniteMap
with
type FM a b = FiniteMap a b
it works fine. I wasn't aware there was (supposed to be) a difference
between these two declarations? Is there?
I don't know about your example, but there is a difference.
type
13 matches
Mail list logo
