On Fri, Nov 30, 2012 at 02:33:54AM +0100, Ben Franksen wrote:
Brent Yorgey wrote:
On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote:
Tony Morris wrote:
As a side note, I think a direct superclass of Functor for Monad is not
a good idea, just sayin'
class Functor f
Lists! The finite kind.
This could mean Seq for instance.
On Nov 30, 2012 9:53 AM, Brent Yorgey byor...@seas.upenn.edu wrote:
On Fri, Nov 30, 2012 at 02:33:54AM +0100, Ben Franksen wrote:
Brent Yorgey wrote:
On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote:
Tony Morris
On 11/30/12 10:44 AM, Dan Doel wrote:
Lists! The finite kind.
This could mean Seq for instance.
On Nov 30, 2012 9:53 AM, Brent Yorgey byor...@seas.upenn.edu
mailto:byor...@seas.upenn.edu wrote:
Any data type which admits structures of arbitrary but *only finite*
size has a natural
Gershom Bazerman wrote:
On 11/30/12 10:44 AM, Dan Doel wrote:
Lists! The finite kind.
This could mean Seq for instance.
On Nov 30, 2012 9:53 AM, Brent Yorgey byor...@seas.upenn.edu
mailto:byor...@seas.upenn.edu wrote:
Any data type which admits structures of arbitrary but *only
Ben,
Now, on to Bind: the standard finite structure example for Bind is
most probably the substitution thingy ...
Danger of conflating a bunch of things here:
(1) the substitution monadic effect is always also applicative and always
also unital/pointed because monads are always applicative and
On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote:
Tony Morris wrote:
As a side note, I think a direct superclass of Functor for Monad is not
a good idea, just sayin'
class Functor f where
fmap :: (a - b) - f a - f b
class Functor f = Apply f where
(*) :: f (a -
Brent Yorgey wrote:
On Thu, Nov 29, 2012 at 03:52:58AM +0100, Ben Franksen wrote:
Tony Morris wrote:
As a side note, I think a direct superclass of Functor for Monad is not
a good idea, just sayin'
class Functor f where
fmap :: (a - b) - f a - f b
class Functor f = Apply f
Tony Morris wrote:
As a side note, I think a direct superclass of Functor for Monad is not
a good idea, just sayin'
class Functor f where
fmap :: (a - b) - f a - f b
class Functor f = Apply f where
(*) :: f (a - b) - f a - f b
class Apply f = Bind f where
(=) :: (a - f b) - f a
Dan Doel wrote:
On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com wrote:
join IS the most important from the categorical point of view.
In a way it is natural to define 'bind' from 'join', but in Haskell, it
is not always possible (see the Monad/Functor problem).
As I said,
As a side note, I think a direct superclass of Functor for Monad is not
a good idea, just sayin'
class Functor f where
fmap :: (a - b) - f a - f b
class Functor f = Apply f where
(*) :: f (a - b) - f a - f b
class Apply f = Bind f where
(=) :: (a - f b) - f a - f b
class Apply f =
Le Wed, 24 Oct 2012 12:36:52 +0700,
Kim-Ee Yeoh k...@atamo.com a écrit :
On Tue, Oct 16, 2012 at 9:37 PM, AUGER Cédric sedri...@gmail.com
wrote:
As I said, from the mathematical point of view, join (often noted μ
in category theory) is the (natural) transformation which with
return (η
What hiders according with my experience, the understanding of this
generalization are some mistakes. two typical mistakes from my side was to
consider an arrow as a function, and the consideration of m as a kind of
container, which it is not from the point of view of category theory.
a - m b
The particular case from which the former is a generalization:
*instance Monad m = Monoid (a - a) where*
*mappend = (.)*
*mempty = id*
*
*
Here the monoid is defined for the functions within the set of values of
type a. There are no null elements.
2012/10/24 Alberto G. Corona
On Tue, Oct 16, 2012 at 9:37 PM, AUGER Cédric sedri...@gmail.com wrote:
As I said, from the mathematical point of view, join (often noted μ in
category theory) is the (natural) transformation which with return (η
that I may have erroneously written ε in some previous mail) defines a
monad
When I teach my students Haskell's monads, I never put Kleisli into my
mouth. I tell them that monads are for sequencing effects; and the
sequencing is visible clearly in
() :: IO a - IO b - IO b
(=) :: IO a - (a - IO b) - IO b
but not in
fmap :: (a - b) - IO a - IO b
join :: IO
On Mon, Oct 15, 2012 at 11:29 PM, Dan Doel dan.d...@gmail.com wrote:
I'm uncertain where this, compositional means written as the
composition of functions, thing started. But it is not what I, and
I'm sure any others mean by the term, compositional.
You're right. It's a rather recent, as far
Le Tue, 16 Oct 2012 07:35:34 +0530,
damodar kulkarni kdamodar2...@gmail.com a écrit :
@Jake
In my opinion, this is not as nice as the do-notation version, but at
least it's compositional:
That's an important point you have made, as Haskellers value code
composition so much.
If code
Le Tue, 16 Oct 2012 09:51:29 -0400,
Jake McArthur jake.mcart...@gmail.com a écrit :
On Mon, Oct 15, 2012 at 11:29 PM, Dan Doel dan.d...@gmail.com wrote:
I'd be down with putting join in the class, but that tends to not be
terribly important for most cases, either.
Join is not the most
Although I agree that Functor should be a superclass of Monad, the two
methods of the Monad typeclass _are_ sufficient to make any instance into a
Functor in a mechanical/automatic way. The language may not know it, but
return/bind is equivalent in power to fmap/return/join. Apart from bind
being
Le Tue, 16 Oct 2012 11:22:08 -0400,
Daniel Peebles pumpkin...@gmail.com a écrit :
Although I agree that Functor should be a superclass of Monad, the two
methods of the Monad typeclass _are_ sufficient to make any instance
into a Functor in a mechanical/automatic way. The language may not
know
On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com wrote:
join IS the most important from the categorical point of view.
In a way it is natural to define 'bind' from 'join', but in Haskell, it
is not always possible (see the Monad/Functor problem).
As I said, from the
Le Tue, 16 Oct 2012 11:58:44 -0400,
Dan Doel dan.d...@gmail.com a écrit :
On Tue, Oct 16, 2012 at 10:37 AM, AUGER Cédric sedri...@gmail.com
wrote:
join IS the most important from the categorical point of view.
In a way it is natural to define 'bind' from 'join', but in
Haskell, it is not
On Tue, Oct 16, 2012 at 1:19 PM, AUGER Cédric sedri...@gmail.com wrote:
What do you mean by demonstrate? If you do not want to fit the
mathematical presentation, then I have nothing to demonstrate, you have
your point of view, I have mine and they differ. Now, if you want to
I think the
I think the version below (with a Functor or Applicative superclass)
is clearly the right answer if we were putting the prelude together
from a clean slate. You can implement whichever is easiest for the
particular monad, use whichever is most appropriate to the context
(and add optimized
Not sure I really have anything substantial to contribute, but it's certainly
true that if you see
a - m b
as a generalisation of the usual function type, a - b, then return generalises
the identity and
kleisli generalises function composition. This makes the types pretty memorable
(and
damodar kulkarni kdamodar2...@gmail.com wrote:
The Monad class makes us define bind (=) and unit (return) for our
monads.
Why the Kleisli composition (=) or (=) is not made a part of Monad
class instead of bind (=)?
Is there any historical reason behind this?
The bind (=) is not as
Ertugrul Söylemez wrote:
damodar kulkarni kdamodar2...@gmail.com wrote:
The Monad class makes us define bind (=) and unit (return) for our
monads.
Why the Kleisli composition (=) or (=) is not made a part of Monad
class instead of bind (=)?
Is there any historical reason behind this?
The
Le Mon, 15 Oct 2012 15:12:28 +0200,
Benjamin Franksen benjamin.frank...@helmholtz-berlin.de a écrit :
Ertugrul Söylemez wrote:
damodar kulkarni kdamodar2...@gmail.com wrote:
The Monad class makes us define bind (=) and unit (return) for
our monads.
Why the Kleisli composition (=) or
On Mon, Oct 15, 2012 at 7:59 AM, Ertugrul Söylemez e...@ertes.de wrote:
Try to express
do x - getLine
y - getLine
print (x, y)
using only Kleisli composition (without cheating).
In my opinion, this is not as nice as the do-notation version, but at
least it's
On Mon, Oct 15, 2012 at 11:33 AM, Jake McArthur jake.mcart...@gmail.com wrote:
On Mon, Oct 15, 2012 at 7:59 AM, Ertugrul Söylemez e...@ertes.de wrote:
Try to express
do x - getLine
y - getLine
print (x, y)
using only Kleisli composition (without cheating).
My previous
@Jake
In my opinion, this is not as nice as the do-notation version, but at
least it's compositional:
That's an important point you have made, as Haskellers value code
composition so much.
If code composition is the holy grail, why not encourage the monadic
code, too, to be compositional?
On Mon, Oct 15, 2012 at 10:05 PM, damodar kulkarni
kdamodar2...@gmail.com wrote:
@Jake
In my opinion, this is not as nice as the do-notation version, but at
least it's compositional:
That's an important point you have made, as Haskellers value code
composition so much.
If code
32 matches
Mail list logo
