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
On Thu, Jul 21, 2011 at 6:46 PM, Simon Peyton-Jones
simo...@microsoft.com wrote:
You point is that the (C Int) dictionary has (C String) as a superclass, and
(C String) has (C Int) as a superclass. So the two instances are mutually
recursive, but that’s ok.
That is not unreasonable. But it
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.
You point is that the (C Int) dictionary has (C String) as a superclass, and (C
String) has (C Int) as a superclass. So the two instances are mutually
recursive, but that's ok.
That is not unreasonable. But it is dangerous. Consider
class C [a] = C a
Then any dictionary for (C a) would
*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
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)
20 matches
Mail list logo