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 n
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 generall
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 impli
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 n
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 (e
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 use
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 concre
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 x+
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 (Mono
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:
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 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
ove
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 o
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
ht
14 matches
Mail list logo