I'll give my two cents about some design I've been thinking about. Instead
of trying to derive all instances automatically, the programmer should
explicitly tell them (so the problems about conflicting implementations
would be minimised). I attach a piece of code of what I think could be done:
On Jul 25, 2011, at 4:55 PM, Ryan Ingram wrote:
My guess is that nobody has put forward a clear enough design that solves all
the problems. In particular, orphan instances are tricky.
Here's an example:
module Prelude where
class (Functor m, Applicative m) = Monad m where
return
On Tue, Jul 26, 2011 at 1:01 PM, Alejandro Serrano Mena
trup...@gmail.com wrote:
I'll give my two cents about some design I've been thinking about. Instead
of trying to derive all instances automatically, the programmer should
explicitly tell them (so the problems about conflicting
My guess is that nobody has put forward a clear enough design that solves
all the problems. In particular, orphan instances are tricky.
Here's an example:
module Prelude where
class (Functor m, Applicative m) = Monad m where
return :: a - m a
(=) :: m a - (a - m b) - m b
() :: m a
On Mon, 2011-07-25 at 00:11 -0400, August Sodora wrote:
Out of (perhaps naive) curiosity, what difficulties does allowing such
overriding introduce? Wouldn't the module system prevent the ambiguity
of which implementation to use?
August Sodora
aug...@gmail.com
(201) 280-8138
class A a
I was thinking the reverse. We can already give default implementations of
class operations that can be overridden by giving them explicitly when we
declare instances, so why shouldn't we be able to give default implementations
of operations of more general classes, which could be overridden by
On 25 July 2011 13:50, Sebastien Zany sebast...@chaoticresearch.com wrote:
I was thinking the reverse. We can already give default implementations of
class operations that can be overridden by giving them explicitly when we
declare instances, so why shouldn't we be able to give default
Out of (perhaps naive) curiosity, what difficulties does allowing such
overriding introduce? Wouldn't the module system prevent the ambiguity
of which implementation to use?
August Sodora
aug...@gmail.com
(201) 280-8138
On Sun, Jul 24, 2011 at 11:55 PM, Ivan Lazar Miljenovic
Would it be theoretically possible/convenient to be able to put boilerplate
like this in class definitions?
On Thu, Jul 21, 2011 at 5:58 AM, Felipe Almeida Lessa
felipe.le...@gmail.com wrote:
On Thu, Jul 21, 2011 at 8:31 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
Well, for
On 24 July 2011 00:49, Sebastien Zany sebast...@chaoticresearch.com wrote:
Would it be theoretically possible/convenient to be able to put boilerplate
like this in class definitions?
Not really: what happens for Functors that aren't Monads? Also, for
some Monads there may be a more efficient
Hi cafe!
I feel a bit like I'm speaking out of turn for bringing this up -- and
I'm sure it must have been brought up many times before -- but I hope
there can be something fruitful had from a discussion.
In my travels I've read several people with much better grasp of Haskell
than I have
On 21 July 2011 11:10, Arlen Cuss cel...@sairyx.org wrote:
Hi cafe!
I feel a bit like I'm speaking out of turn for bringing this up -- and
I'm sure it must have been brought up many times before -- but I hope
there can be something fruitful had from a discussion.
In my travels I've read
On Thu, Jul 21, 2011 at 8:31 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
Well, for fmap vs liftM, you have that liftM is automatically defined
for you rather than needing to make the Functor instance, so if you're
quickly defining a Monad for internal use then you can just use
13 matches
Mail list logo
