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 it
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 treating
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 supertype
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 special,
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
f =
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 with
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 'FooBar a' as
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 constraints
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. Do
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 some
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 more
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 dictionary *is*
| 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 = ...
what this
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
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 still
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 summary
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
| signatures
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 to
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
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):
class Additive a
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 we would want to split it up
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 if
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
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)
Note that (i) is
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 that (i) is
= 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
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
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
classes, and
31 matches
Mail list logo
