= Class Aliases =
This is a proposal for a language extension which will hopefully mitigate the
issues holding back evolution of the standard prelude as well as provide
useful class abstraction capabilities in general.
It's main goals are to
* remove the false tension between the granularity of
On Wed, 12 Oct 2005, John Meacham wrote:
ideally we would want to split it up like so (but with more mathematically
precise names):
Might it also be reasonable to provide less mathematical names for some
classes, and possibly allow users to let the compiler know which ones they
find more re
On Thu, Oct 13, 2005 at 01:14:19AM +0100, Philippa Cowderoy wrote:
> On Wed, 12 Oct 2005, John Meacham wrote:
>
> >ideally we would want to split it up like so (but with more mathematically
> >precise names):
> >
>
> Might it also be reasonable to provide less mathematical names for some
> class
Am Donnerstag, 13. Oktober 2005 02:00 schrieb John Meacham:
> [...]
At a first look, this looks really nice.
> We allow new constructs of this form (the exact syntax is flexible of
> course):
>
> > class alias (Foo a, Bar a) => FooBar a where
> >foo = ...
>
> what this does is declare 'FooB
On Thu, Oct 13, 2005 at 12:08:27PM +0200, Wolfgang Jeltsch wrote:
> > We allow new constructs of this form (the exact syntax is flexible of
> > course):
> >
> > > class alias (Foo a, Bar a) => FooBar a where
> > >foo = ...
> >
> > what this does is declare 'FooBar a' as an alias for the two c
John Meacham <[EMAIL PROTECTED]> writes:
> = Class Aliases =
>
> This is a proposal for a language extension which will hopefully mitigate
> the issues holding back evolution of the standard prelude as well as provide
> useful class abstraction capabilities in general.
I like your proposal a lot
> One thought: how will class aliases interact with type inference?
> e.g. if a declaration contains only a call to 'foo', should we infer
> the constraint Foo a, or FooBar a? Can there ever be a situation where
> choosing the more specific dictionary could leave us without a 'bar'
> method at som
Andres Loeh <[EMAIL PROTECTED]> writes:
> The way I understand the proposal, there are no FooBar dictionaries
> ever. John said that this can be translated by a source-to-source
> translation, so internally, a FooBar dictionary *is* a Foo and a
> Bar dictionary.
Ah yes, I was misled by the syntax
On Thu, Oct 13, 2005 at 12:46:21PM +0200, Andres Loeh wrote:
> > One thought: how will class aliases interact with type inference?
> > e.g. if a declaration contains only a call to 'foo', should we infer
> > the constraint Foo a, or FooBar a? Can there ever be a situation where
> > choosing the mo
On Thu, Oct 13, 2005 at 11:48:17AM +0100, Malcolm Wallace wrote:
> Andres Loeh <[EMAIL PROTECTED]> writes:
>
> > The way I understand the proposal, there are no FooBar dictionaries
> > ever. John said that this can be translated by a source-to-source
> > translation, so internally, a FooBar dictio
| This is a proposal for a language extension which will hopefully
mitigate the
| issues holding back evolution of the standard prelude as well as
provide
| useful class abstraction capabilities in general.
A short summary would be "type synonyms for class constraints". You'd
definitely want the
On Thursday 13 October 2005 12:22, John Meacham wrote:
> On Thu, Oct 13, 2005 at 12:08:27PM +0200, Wolfgang Jeltsch wrote:
> > > We allow new constructs of this form (the exact syntax is
> > > flexible of
> > >
> > > course):
> > > > class alias (Foo a, Bar a) => FooBar a where
> > > >foo = ..
On Thursday 13 October 2005 13:21, Simon Peyton-Jones wrote:
> If so, than rather than invent a whole new mechanism, why not simply
> extend the existing superclass mechanism to allow a single instance
> decl to declare instances for several classes? For example, one add
> to Haskell 98 the follow
> I've considered this before, but never done anything about it because
> superclasses are so close. Specifically, what is the difference between
>
> (i) class (C a, D a) => CD a
> and
> (ii) class alias CD a = (C a, D a)
The difference is that (i) is, in a sense, generative - because
you st
On Thu, Oct 13, 2005 at 12:21:41PM +0100, Simon Peyton-Jones wrote:
> | This is a proposal for a language extension which will hopefully
> mitigate the
> | issues holding back evolution of the standard prelude as well as
> provide
> | useful class abstraction capabilities in general.
>
> A short s
John
Replying just to you to avoid spamming everyone.
| in particular,
|
| (CD a) => a and (C a,D a) => a are distinct types. this means that
| you cannot use the aliases as abreviations or alternate names, which
is
| a very nice side effect. with fine grained class hierarchies, type
| signature
Simon Peyton-Jones wrote:
> I've considered this before, but never done anything about it because
> superclasses are so close. Specifically, what is the difference between
>
> (i) class (C a, D a) => CD a
> and
> (ii) class alias CD a = (C a, D a)
>
> Note that (i) is Haskell 98.
I was about
On Oct 12, 2005, at 8:00 PM, John Meacham wrote:
[longish proposal for class aliases]
Very nicely done, by the way.
== Notes ==
* class aliases are also able to introduce new superclass
constraints, such as
in the Num example we also want to enforce a (Eq a, Show a)
superclass
c
On Oct 12, John Meacham wrote:
>
> [...]
>
> > class Num a where
> > (+), (*):: a -> a -> a
> > (-) :: a -> a -> a
> > negate :: a -> a
> > fromInteger :: Integer -> a
>
> ideally we would want to split it up like so (but with more mathematically
> precise names):
Paul Govereau wrote:
Of course, if we
allow union and subtraction, then why not addition, intersection,
complement (ok, maybe not complement).
Class definitions (including constraints and defaults) are essentially
(syntactic) theory signatures (as in Institutions, from Goguen,
Burstall, an
On Thu, Oct 13, 2005 at 01:41:14PM -0400, Paul Govereau wrote:
> On Oct 12, John Meacham wrote:
> >
> > [...]
> >
> > > class Num a where
> > > (+), (*):: a -> a -> a
> > > (-) :: a -> a -> a
> > > negate :: a -> a
> > > fromInteger :: Integer -> a
> >
> > ideally
On Thu, Oct 13, 2005 at 01:46:14PM +0200, Benjamin Franksen wrote:
> Using '=' instead of '=>', you could even leave out the 'alias':
>
> class FooBar a = (Foo a, Bar a) where ...
true. for the purposes of discussion I think I will keep using the
'alias' so it is clearer what is going on. but
On Thu, Oct 13, 2005 at 10:18:24AM -0400, Jan-Willem Maessen wrote:
> >* incidental but not earth-shattering benefits include being able to
> > declare an instance for a class and all its superclasses at once,
> > smarter defaults when you are combining related classes, and much
> > nicer type s
Udo Stenzel writes:
> Simon Peyton-Jones wrote:
> > I've considered this before, but never done anything about it
> > because superclasses are so close. Specifically, what is the
> > difference between
> >
> > (i) class (C a, D a) => CD a
> > and
> > (ii)class alias CD a = (C a, D a)
> >
>
I have revised the proposal and put it on the web here:
http://repetae.net/john/recent/out/classalias.html
changes include a new, clearer syntax, some typo fixes, and a new
section describing how class aliases interact with superclasses.
I will update that web page with any new devolpments.
G'day all.
Quoting Simon Peyton-Jones <[EMAIL PROTECTED]>:
> I've considered this before, but never done anything about it because
> superclasses are so close. Specifically, what is the difference between
>
> (i) class (C a, D a) => CD a
> and
> (ii) class alias CD a = (C a, D a)
>
> Note tha
Am Donnerstag, 13. Oktober 2005 12:22 schrieb John Meacham:
> [...]
> although perhaps
>
> > class alias FooBar a = (Foo a, Bar a) where ...
>
> since the new name introduced usually appears to the left of an equals
> sign.
Yes, exactly.
> This also solves the problems of where to put new sup
Am Donnerstag, 13. Oktober 2005 15:58 schrieb Udo Stenzel:
> [...]
> Further, if classes with no methods have no use currently, this "universal
> instance" could be compiler generated whenever a class without methods is
> declared.
This does mean that you want to treat classes without methods spe
Am Donnerstag, 13. Oktober 2005 15:43 schrieb Simon Peyton-Jones:
> John
>
> Replying just to you to avoid spamming everyone.
Hmm, you did write to the list as well...
> [...]
> I don't agree. What do you mean by "distinct types"? In H98 both of
> these are ok:
>
> f :: CD a => ty
>
Wolfgang Jeltsch wrote:
> This does mean that you want to treat classes without methods special,
> doesn't
> it?
Not quite, I'm actually not sure if I want this, I just noted that it
was possible. :) As David Menendez pointed out, empty classes probably
aren't that useless.
Anyway, not treatin
On Thu, Oct 13, 2005 at 05:51:36AM -0700, John Meacham wrote:
> On Thu, Oct 13, 2005 at 12:21:41PM +0100, Simon Peyton-Jones wrote:
> > Anyway, my main point is: would a smaller change not suffice?
>
> I do not think it suffices.
>
> We could extend the supertyping relationship some more to make
Am Donnerstag, 27. Oktober 2005 13:18 schrieb Ross Paterson:
> [...]
> extend the class syntax with an annotation on the assumptions (! for now),
> to allow
>
> class (Show a, !Additive a, !Negative a, !Multiplicative a) =>
> Num a where
> fromInteger :: I
On Thu, Oct 13, 2005 at 05:53:15PM -0700, John Meacham wrote:
> I have revised the proposal and put it on the web here:
>
> http://repetae.net/john/recent/out/classalias.html
>
> changes include a new, clearer syntax, some typo fixes, and a new
> section describing how class aliases interact wit
33 matches
Mail list logo
