(Sorry I'm so late to this dialogue.)
In http://www.haskell.org/pipermail/glasgow-haskell-users/2011-July/020593.html,
SPJ asks
The superclasses are recursive but
a) They constrain only type variables
b) The variables in the superclass context are all
mentioned in the head. In
I just thought of an additional consideration regarding this part of the
design space.
On 25/07/2011 2:02 PM, Edward Kmett wrote:
(I had said):
Here is another way to look at it: when you say
class LeftModule Whole m = Additive m
you are closer to specifying an *instance*
2011/7/25 Edward Kmett ekm...@gmail.com:
2011/7/25 Gábor Lehel illiss...@gmail.com
type family Frozen t
type family Thawed t
class Immutable (Frozen t) = Mutable t where
thawedFrozen :: t - Thawed (Frozen t)
unthawedFrozen :: Thawed (Frozen t) - t
class Mutable (Thawed t) =
:07
To: Simon Peyton-Jones
Cc: Gábor Lehel; glasgow-haskell-users@haskell.org
Subject: Re: Superclass Cycle via Associated Type
2011/7/22 Simon Peyton-Jones
simo...@microsoft.commailto:simo...@microsoft.com
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive
2011/7/23 Edward Kmett ekm...@gmail.com:
2011/7/23 Gábor Lehel illiss...@gmail.com
2011/7/22 Dan Doel dan.d...@gmail.com:
2011/7/22 Gábor Lehel illiss...@gmail.com:
Yeah, this is pretty much what I ended up doing. As I said, I don't
think I lose anything in expressiveness by going the
On Mon, Jul 25, 2011 at 4:46 AM, Simon Peyton-Jones
simo...@microsoft.comwrote:
On further reflection I have a question.
** **
Under the limited design below, which Edward says will do all he wants:***
*
**· **The mutually recursive classes (call them A, B, C) must be
2011/7/25 Gábor Lehel illiss...@gmail.com
type family Frozen t
type family Thawed t
class Immutable (Frozen t) = Mutable t where
thawedFrozen :: t - Thawed (Frozen t)
unthawedFrozen :: Thawed (Frozen t) - t
class Mutable (Thawed t) = Immutable t where
frozenThawed :: t -
On 25/07/2011 9:55 AM, Edward Kmett wrote:
If you have an associative (+), then you can use (.*) to multiply by a
whole number, I currently do fold a method into the Additive class to
'fake' a LeftModule, but you have to explicitly use it.
class Additive m = LeftModule r m
class LeftModule
On Mon, Jul 25, 2011 at 1:40 PM, Jacques Carette care...@mcmaster.cawrote:
**
On 25/07/2011 9:55 AM, Edward Kmett wrote:
If you have an associative (+), then you can use (.*) to multiply by a
whole number, I currently do fold a method into the Additive class to
'fake' a LeftModule, but
2011/7/22 Dan Doel dan.d...@gmail.com:
2011/7/22 Gábor Lehel illiss...@gmail.com:
Yeah, this is pretty much what I ended up doing. As I said, I don't
think I lose anything in expressiveness by going the MPTC route, I
just think the two separate but linked classes way reads better. So
it's
2011/7/23 Gábor Lehel illiss...@gmail.com
2011/7/22 Dan Doel dan.d...@gmail.com:
2011/7/22 Gábor Lehel illiss...@gmail.com:
Yeah, this is pretty much what I ended up doing. As I said, I don't
think I lose anything in expressiveness by going the MPTC route, I
just think the two separate
and-or implementible?
Simon
From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Ryan Trinkle
Sent: 20 July 2011 17:37
To: glasgow-haskell-users@haskell.org
Subject: Superclass Cycle via Associated Type
The following code doesn't compile
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive superclasses, albeit we have a bit more work to do on the type
inference engine first.
The situation we think we can handle ok is stuff like Edward wants (I've
removed all the methods):
class LeftModule
2011/7/22 Simon Peyton-Jones simo...@microsoft.com:
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive superclasses, albeit we have a bit more work to do on the type
inference engine first.
The situation we think we can handle ok is stuff like Edward wants
2011/7/22 Simon Peyton-Jones simo...@microsoft.com
I talked to Dimitrios. Fundamentally we think we should be able to handle
recursive superclasses, albeit we have a bit more work to do on the type
inference engine first.
The situation we think we can handle ok is stuff like Edward wants
2011/7/22 Gábor Lehel illiss...@gmail.com:
Yeah, this is pretty much what I ended up doing. As I said, I don't
think I lose anything in expressiveness by going the MPTC route, I
just think the two separate but linked classes way reads better. So
it's just a would be nice thing. Do recursive
My situation is fairly similar to Gabor's, and, like him, I was able to make
do with an equality superclass. However, instead of combining two classes,
I found that I needed to add a third.
My concept here is to create two monads which share much of their
functionality, but not all of it.
...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Ryan Trinkle
Sent: 20 July 2011 17:37
To: glasgow-haskell-users@haskell.org
Subject: Superclass Cycle via Associated Type
The following code doesn't compile, but it seems sensible enough to me. Is
this a limitation
*Simon Peyton-Jones* simonpj at microsoft.com
glasgow-haskell-users%40haskell.org?Subject=Re%3A%20Superclass%20Cycle%20via%20Associated%20TypeIn-Reply-To=%3C59543203684B2244980D7E4057D5FBC125661A72%40DB3EX14MBXC308.europe.corp.microsoft.com%3E
--
You point is that the
The following code doesn't compile, but it seems sensible enough to me. Is
this a limitation of GHC or is there something I'm missing?
class C (A x) = C x where
type A x :: *
instance C Int where
type A Int = String
instance C String where
type A String = Int
The error I get is:
On Wed, Jul 20, 2011 at 10:07 PM, Ryan Trinkle ryant5...@gmail.com wrote:
The following code doesn't compile, but it seems sensible enough to me. Is
this a limitation of GHC or is there something I'm missing?
class C (A x) = C x where
type A x :: *
Did you mean
class (A x) = C x where
This isn't a GHC limitation. The report specifies that the class
hierarchy must be a DAG. So C cannot require itself as a prerequisite,
even if it's on a 'different' type.
Practically, in the implementation strategy that GHC (and doubtless
other compilers) use, the declaration:
class C (A x)
22 matches
Mail list logo
