On 9 Apr 2008, at 17:49, Henning Thielemann wrote:
Additionally I see the problem, that we put more interpretation
into standard symbols by convention. Programming is not only about
the most general formulation of an algorithm but also about error
detection. E.g. you cannot compare complex
On 9 Apr 2008, at 11:26, Jules Bean wrote:
Using 'hugs -98', I noticed it accepts:
instance Monad m = Functor m where
fmap f x = x = return.f
Has this been considered (say) as a part of the upcoming Haskell
Prime?
This forbids any Functors which are not monads. Unless you allow
Hans Aberg wrote:
Using 'hugs -98', I noticed it accepts:
instance Monad m = Functor m where
fmap f x = x = return.f
Has this been considered (say) as a part of the upcoming Haskell Prime?
This forbids any Functors which are not monads. Unless you allow
overlapping instances (which of
On Wed, 9 Apr 2008, Hans Aberg wrote:
I don't know if it is possible to extend the syntax this way, but it would be
closer to math usage. And one would avoid duplicate definitions just to
indicate different operator names, like:
class AdditiveMonoid a where
o :: a
(+) :: a - a - a
as it
On 9 Apr 2008, at 15:23, Henning Thielemann wrote:
I don't know if it is possible to extend the syntax this way, but
it would be closer to math usage. And one would avoid duplicate
definitions just to indicate different operator names, like:
class AdditiveMonoid a where
o :: a
(+) :: a -
On Wed, 9 Apr 2008, Hans Aberg wrote:
Different names result in different operator hierarchies. So a class like
class Monoid (a; unit, mult) where
unit :: a
mult :: a - a - a
must have an instantiation that specifies the names of the operators. In
particular, one will need a
class
On 9 Apr 2008, at 15:23, Henning Thielemann wrote:
I also recognized that problem in the past, but didn't know how to
solve it. In Haskell 98, methods are resolved using the types of
the operands. How would the compiler find out which implementation
of (+) to choose for an expression like
On 9 Apr 2008, at 16:26, Henning Thielemann wrote:
I think a classical example are number sequences which can be
considered as rings in two ways:
1. elementwise multiplication
2. convolution
and you have some function which invokes the ring multiplication
f :: Ring a = a - a
and a
On 9 Apr 2008, at 16:26, Henning Thielemann wrote:
1. elementwise multiplication
2. convolution
and you have some function which invokes the ring multiplication
f :: Ring a = a - a
and a concrete sequence
x :: Sequence Integer
what multiplication (elementwise or convolution) shall be used
On Wed, 9 Apr 2008, Hans Aberg wrote:
On 9 Apr 2008, at 16:26, Henning Thielemann wrote:
1. elementwise multiplication
2. convolution
and you have some function which invokes the ring multiplication
f :: Ring a = a - a
and a concrete sequence
x :: Sequence Integer
what multiplication
On 9 Apr 2008, at 17:49, Henning Thielemann wrote:
Additionally I see the problem, that we put more interpretation
into standard symbols by convention. Programming is not only about
the most general formulation of an algorithm but also about error
detection. E.g. you cannot compare complex
On 9 Apr 2008, at 17:49, Henning Thielemann wrote:
Also (2*5 == 7) would surprise people, if (*) is the symbol for a
general group operation, and we want to use it for the additive
group of integers.
One might resolve the Num binding of (+) problem by putting all
operators into an
G'day all.
Quoting Jules Bean [EMAIL PROTECTED]:
Other solutions, such as class Functor m = Monad m are frequently discussed.
I see no H' ticket for it, though.
Then add it. :-)
You'll probably want to make it depend on Ticket #101, because making
class hierarchies more granular generally
Using 'hugs -98', I noticed it accepts:
instance Monad m = Functor m where
fmap f x = x = return.f
Has this been considered (say) as a part of the upcoming Haskell Prime?
Hans Aberg
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
14 matches
Mail list logo
