| which leads me to a problem i have with ATs, which applies
| to class aliases as well: although the ATs are written as if they
| were local to the class, they get lifted out of the class in a naive
| manner. in particular, they can only refer to their parameters,
| not to other local definitions
| which leads me to a problem i have with ATs, which applies
| to class aliases as well: although the ATs are written as if they
| were local to the class, they get lifted out of the class in a naive
| manner. in particular, they can only refer to their parameters,
| not to other local definitions/
class alias Foo a => Foo a = Bar a where ...
Has a defined (if not very useful) meaning with class aliases, but is
really odd if you consider 'Foo a' a "superclass". So, I think the
following terminology should be used:
Context of --+
alias| The alias -++--- The expansion of
A aliasing of constraints/classes
(this is the semantic part that could also be explained by
reduction, or by simple mutual implication encodings)
B aliasing of syntax, especially instance definitions
(this syntactic part is hard to encode, and simple in
terms of
hmm, i thought i understood what class aliases were about,
but the recent discussion about superclasses and fixpoints
has me confused again.
may i suggest that the updated proposal page follows this
outline (in particular, providing 1 and 2 before diving into 3):
1. general idea + one simple
On Fri, May 02, 2008 at 11:54:13AM +0100, Simon Peyton-Jones wrote:
> Even more crumbs! Is this fixpoint iteration (being careful to avoid
> infinite expansion) *really* essential to your proposal? That would
> be a significant and unwelcome thing IMHO.
>
> To be concrete, consider f :: (Foo a)
| > Crumbs! I have no idea what that means! Did you really mean to repeat
"Foo"? According to your
| expansion in type signatures
| > f :: (Foo a) => ...
| > expands to
| > f :: (Foo a, Bar a) => ...
| > which presumably expands again. I'm totally lost here
|
| Yes I did, becau
On Fri, May 02, 2008 at 11:24:11AM +0100, Simon Peyton-Jones wrote:
> | The more I think about it, I think 'superclass' is just the wrong
> | terminology for dealing with class aliases. Superclass implies a strict
> | partial order on classes, which just isn't the case for class aliases,
> | for in
| > Notice that this part *is* exactly true of a superclass with no
| > methods
| >
| > class (S a, C1 a, C2 a) => A a where {}
|
| No, this isn't true. imagine
|
| > f :: (S a, C1 a, C2 a) => a -> Int
| > f x = g x
|
| > g :: A a => a -> Int
| > g x =
|
| If A is a class alias, then t
| The more I think about it, I think 'superclass' is just the wrong
| terminology for dealing with class aliases. Superclass implies a strict
| partial order on classes, which just isn't the case for class aliases,
| for instance
|
| > class alias Foo a => Foo a = Bar a where ...
Crumbs! I have n
On Fri, May 02, 2008 at 10:00:32AM +0100, Simon Peyton-Jones wrote:
> John
>
> This is good stuff, but I fear that in 3 months time it'll be buried
> in our email archives. In contrast, your original web page is alive
> and well, and we were able to start our discussion based on it
>
> So can I sug
Any chance to express this in terms of a formal (constraint rewrite
framework).
For example, the Haskell rule, do *not* display implied superclasses,
can be
specified as follows. Consider the special case of
class Eq a
class Eq a => Ord a
Eq a, Ord a <=> Ord a
The above rule only applies
This isn't really a response to your email, but I have been mulling the
last few hours away from a computer and wanted to get this stream of
conciousness out when it is fresh in my mind.
The more I think about it, I think 'superclass' is just the wrong
terminology for dealing with class aliases. S
On Fri, May 02, 2008 at 08:30:59AM +0200, Tom Schrijvers wrote:
>> Note that when declaring an instance of a concrete type, like Int, the
>> constraint (S Int) will be trivially satisfied or not at compile time.
>> (bf2 is free to use methods of 'S' of course).
>>
>> this translation is also a bije
John
This is good stuff, but I fear that in 3 months time it'll be buried in our
email archives. In contrast, your original web page is alive and well, and we
were able to start our discussion based on it
So can I suggest that you transfer your web page to the Haskell' wiki (simply a
convenien
Hmm.. okay, here is a rough draft that covers all the important cases I
think.
assume the following declarations:
class C1 a where
f1 :: t1
f1 = d1
class C2 a where
f2 :: t2
f2 = d2
f3 :: t3
f3 = d3
class alias S a => A a = (C1 a, C2 a) wh
On Thu, May 01, 2008 at 11:57:14PM +0100, Simon Peyton-Jones wrote:
> | > Fair enough. But the strange syntax
> | >
> | > class alias Num a = Eq a => (Additive a, Multiplicative a)
> | >
> | > *does* seem so say that the (Eq a) behaves in a superclass way, and
> | > (Additive a, Multiplicative a)
| > Fair enough. But the strange syntax
| >
| > class alias Num a = Eq a => (Additive a, Multiplicative a)
| >
| > *does* seem so say that the (Eq a) behaves in a superclass way, and
| > (Additive a, Multiplicative a) behave in a class-alias way, as it
| > were. That seems inconsistent with the d
On Thu, May 01, 2008 at 03:42:53PM +0100, Simon Peyton-Jones wrote:
> | Yeah, I disagree here, mainly because I don't want to conflate
> | superclasses with class aliases. I feel they have different uses, even
> | though they can sometimes achieve the same thing.
>
> Fair enough. But the strange
| Yeah, I disagree here, mainly because I don't want to conflate
| superclasses with class aliases. I feel they have different uses, even
| though they can sometimes achieve the same thing.
Fair enough. But the strange syntax
class alias Num a = Eq a => (Additive a, Multiplicative a)
*does* see
On Thu, Apr 24, 2008 at 10:21:03PM +0200, Wolfgang Jeltsch wrote:
> Am Donnerstag, 24. April 2008 21:27 schrieb John Meacham:
> > On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote:
> > […]
>
> > > I also have some remark: Why not write
> > >
> > > > class Eq a => Num a = (Additive a
Simon Peyton-Jones wrote:
Is this the most up-to-date description of the proposal?
http://repetae.net/recent/out/classalias.html
Has anyone looked at my (confusingly named and horribly written) variant?
http://haskell.org/haskellwiki/Superclass_defaults
My idea is to split cla
On Fri, Apr 25, 2008 at 05:37:17PM +0100, Simon Peyton-Jones wrote:
> John
>
> OK here's a question about class alisas. You propose:
>
>class Foo a where
> foo :: a -> [a]
> foo x = []
>class Bar a where
> bar :: a -> a
> bar x = [x]
>
>class alias Foo
John
OK here's a question about class alisas. You propose:
class Foo a where
foo :: a -> [a]
foo x = []
class Bar a where
bar :: a -> a
bar x = [x]
class alias FooBar a = (Foo a, Bar a) where
foobar :: a -> a
foobar x = x
foo x =
Is this the most up-to-date description of the proposal?
http://repetae.net/recent/out/classalias.html
what sounds nice about the class alias proposal is that it is pure
sugar, at least to the extent that type aliases are, but the design
principle behind it seems to be that there should
Am Donnerstag, 24. April 2008 21:27 schrieb John Meacham:
> On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote:
> […]
> > I also have some remark: Why not write
> >
> > > class Eq a => Num a = (Additive a, Multiplicative a)
> >
> > instead of
> >
> > > class Num a = Eq a => (Additive
On Thu, Apr 24, 2008 at 08:48:15PM +0200, Wolfgang Jeltsch wrote:
> Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
> > On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > > Is this the most up-to-date description of the proposal?
> > > http://repetae.net/recent/
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
> On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > Is this the most up-to-date description of the proposal?
> > http://repetae.net/recent/out/classalias.html
>
> There were a few changes proposed in the discussio
Am Mittwoch, 23. April 2008 06:18 schrieb John Meacham:
> On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > Is this the most up-to-date description of the proposal?
> > http://repetae.net/recent/out/classalias.html
>
> There were a few changes proposed in the discussio
Am Dienstag, 22. April 2008 09:33 schrieb Simon Peyton-Jones:
> […]
> One reason I've failed to do so is because I have not come under enough
> pressure! If I thought there were dozens of people slavering at the chops
> for class aliases, that would put it more firmly on my radar.
I would really
In all honesty what I want is a solution to the problems clearly
outlined in the first two sections of his proposal.
People may not be clamouring for this (yet), but that maybe simply
because they've gotten used to the de facto Haskell style of giant type
classes and never seriously asking the
On Tue, Apr 22, 2008 at 09:18:23PM -0700, John Meacham wrote:
> On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> > Is this the most up-to-date description of the proposal?
> > http://repetae.net/recent/out/classalias.html
>
> There were a few changes proposed in the di
On Tue, Apr 22, 2008 at 08:33:53AM +0100, Simon Peyton-Jones wrote:
> Is this the most up-to-date description of the proposal?
> http://repetae.net/recent/out/classalias.html
There were a few changes proposed in the discussion that followed my
announcement that I wanted to make. The one I
| I tried to see the discussion that led to class aliases being rejected
| as a proposal, but could not find links on the Wiki. In fact, in Trac
| (#101) that proposal is still a 'maybe', but with no updates. Is there
| a competing proposal that got accepted?
|
| [Without a mechanism like class a
Jacques Carette wrote:
I tried to see the discussion that led to class aliases being rejected
as a proposal, but could not find links on the Wiki. In fact, in Trac
(#101) that proposal is still a 'maybe', but with no updates. Is there
a competing proposal that got accepted?
[Without a mecha
I would guess that the reason is that it hasn't been implemented yet...
...still it does seem to be a real shame if nothing in this area can
make it into Haskell' (and it's not just Num Monad
inheriting from Functor etc)
...it's a lot less sexy than something like TF, but I think
I tried to see the discussion that led to class aliases being rejected
as a proposal, but could not find links on the Wiki. In fact, in Trac
(#101) that proposal is still a 'maybe', but with no updates. Is there
a competing proposal that got accepted?
[Without a mechanism like class aliases,
37 matches
Mail list logo
