| The report doesn't actually mention this translation although it is
| widely used to implement pattern bindings, and in some compilers (not
| GHC) the translation is done before type checking.
|
| What's interesting to me is that perhaps this gives us a way to
| understand what the static
Dan Doel wrote:
If you do want to generalize (.), you have to decide whether you
want to generalize it as composition of arrows, or as functor application.
The former isn't a special case of the latter (with the current Functor, at
least).
By annotating functors with the category they
consider Haskell 98 report, section 4.3.2 Instance Declarations:
The declarations d may contain bindings only for the class methods of C.
It is illegal to give a binding for a class method that is not in scope, but the
name under which it is in scope is immaterial; in particular, it
Hi Simon,
Those additional reasons given are much more compelling, and should
definately go on the wiki. I think the essential point is that it
makes reasoning about the code simpler - regardless of the effect on
implementation.
My main remaining reservation is that:
(x) /= x
[EMAIL PROTECTED]
It is illegal to give a binding for a class method that is not in
scope, but thename under which it is in scope is immaterial; in
particular, it may be aqualified name.
I believe this was a change introduced in H'98 to tidy up the
language. Previously, if a class was imported
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
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 =
Hello,
I think that the H98 change was a good one. Qualified names should
only be used in _uses_ of variables (to disambiguate) and not in
definitions because (hopefully) there is nothing to disambiguate in a
definition.
By the way, method definitions already have a distinction between what
is
Claus Reinke wrote:
i originally filed this as a bug, until Simon PJ kindly pointed
me to the Haskell 98 report, which forces GHC to behave
this way.. i guess i'll remember this oddity for a while, so
i can live with it, but if it is irksome that the report allows
me to refer to a name that is
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
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, Multiplicative
11 matches
Mail list logo
