Isn't it the case that there could be more than one natural transformation
between functors?
On Tue, Oct 1, 2013 at 10:00 PM, John Wiegley jo...@fpcomplete.com wrote:
Yitzchak Gale g...@sefer.org writes:
In fact, it even makes sense to define it as FunctorIO, with the only
laws
being
On Mon, Oct 07, 2013 at 07:57:23PM +0400, Daniil Frumin wrote:
Isn't it the case that there could be more than one natural transformation
between functors?
Definitely. In addition rwbarton responded to my challenge by finding two
different applicative morphisms between the same applicative,
Daniil Frumin difru...@gmail.com writes:
Isn't it the case that there could be more than one natural transformation
between functors?
Yes, I imagine there would have to be some newtype wrappers to distinguish in
those cases.
--
John Wiegley
FP Complete Haskell tools,
I'm wondering if anyone's run into this problem before, and if there's a
common solution.
In Yesod, we have applicative forms (based originally on formlets). These
forms are instances of Applicative, but not of Monad. Let's consider a
situation where we want to get some user input to fill out a
It's not a solution per se, but it seems to me that there's no need for the
Monad superclass constraint on MonadIO. If that were removed, we could
just have
class LiftIO t where
liftIO :: IO a - t a
and it would Just Work.
On Tue, Oct 1, 2013 at 1:58 AM, Michael Snoyman
Maybe this is needed new typeclass ApplicativeTrans?
2013/10/1 Michael Snoyman mich...@snoyman.com
I'm wondering if anyone's run into this problem before, and if there's a
common solution.
In Yesod, we have applicative forms (based originally on formlets). These
forms are instances of
What about (Compose Form IO) Blog type? Form is Applicative, IO — the same,
their composition should be Applicative as well (one good thing about
Applicatives — they really compose). Take a look at Control.Compose module.
Отправлено с iPad
01 окт. 2013 г., в 10:58, Michael Snoyman
On Tue, 1 Oct 2013 02:21:13 -0500, John Lato jwl...@gmail.com wrote:
It's not a solution per se, but it seems to me that there's no need for the
Monad superclass constraint on MonadIO. If that were removed, we could
just have
class LiftIO t where
liftIO :: IO a - t a
and it would
On Tue, Oct 01, 2013 at 09:29:00AM +0200, Niklas Haas wrote:
On Tue, 1 Oct 2013 02:21:13 -0500, John Lato jwl...@gmail.com wrote:
It's not a solution per se, but it seems to me that there's no need for the
Monad superclass constraint on MonadIO. If that were removed, we could
just have
On 10/01/2013 07:58 AM, Michael Snoyman wrote:
I'm wondering if anyone's run into this problem before, and if there's a
common solution.
In Yesod, we have applicative forms (based originally on formlets).
These forms are instances of Applicative, but not of Monad. Let's
consider a situation
On Tue, Oct 01, 2013 at 09:29:00AM +0200, Niklas Haas wrote:
On Tue, 1 Oct 2013 02:21:13 -0500, John Lato jwl...@gmail.com wrote:
It's not a solution per se, but it seems to me that there's no need for the
Monad superclass constraint on MonadIO. If that were removed, we could
just have
* Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk [2013-10-01
09:20:23+0100]
On Tue, Oct 01, 2013 at 09:29:00AM +0200, Niklas Haas wrote:
On Tue, 1 Oct 2013 02:21:13 -0500, John Lato jwl...@gmail.com wrote:
It's not a solution per se, but it seems to me that there's no need for
From what you've said, it sounds like you can already write:
serverSide :: IO a - Form a
This seems elegant enough to me for your needs. Just encourage it as an
idiom specific to Forms.
myBlogForm = Blog $ titleForm * serverSide getCurrentTime *
contentsForm
Could you abstract
On Tue, Oct 01, 2013 at 12:11:23PM +0300, Roman Cheplyaka wrote:
Shouldn't it be an *Applicative* constraint?
class Applicative t = ApplicativeIO t where
liftIO :: IO a - t a
and require that
liftIO (pure x) = pure x
liftIO (f * x) = liftIO f * liftIO x
Tom Ellis wrote:
Shouldn't it be an *Applicative* constraint?
class Applicative t = ApplicativeIO t where
liftIO :: IO a - t a
and require that
liftIO (pure x) = pure x
liftIO (f * x) = liftIO f * liftIO x
Seems like ApplicativeIO makes more sense than MonadIO, which
Dan Burton wrote:
From what you've said, it sounds like you can already write:
serverSide :: IO a - Form a
This seems elegant enough to me for your needs. Just encourage it as an
idiom specific to Forms.
myBlogForm = Blog $ titleForm * serverSide getCurrentTime *
contentsForm
On Tue, Oct 01, 2013 at 03:17:40PM +0300, Yitzchak Gale wrote:
Tom Ellis wrote:
Shouldn't it be an *Applicative* constraint?
class Applicative t = ApplicativeIO t where
liftIO :: IO a - t a
and require that
liftIO (pure x) = pure x
liftIO (f * x) = liftIO f *
On Tue, Oct 1, 2013 at 12:15 PM, Dan Burton danburton.em...@gmail.comwrote:
From what you've said, it sounds like you can already write:
serverSide :: IO a - Form a
This seems elegant enough to me for your needs. Just encourage it as an
idiom specific to Forms.
myBlogForm = Blog $
On Tue, Oct 1, 2013 at 10:24 AM, Alexey Uimanov s9gf4...@gmail.com wrote:
Maybe this is needed new typeclass ApplicativeTrans?
There's actually no problem with defining a MonadTrans instance for
non-monads. Obviously this can't follow the laws directly (since they're
defined in terms of
In MFow there is a Monad instance for formlets that make a lot of sense.
Apart from using liftIO inside an applicative formlets
it can do it that way also:
myBlogForm = do
t - liftIO getTime
Blog $ titleForm * return t * contentsForm
Which may look contrived, but instead of using
On Mon, Sep 30, 2013 at 11:58 PM, Michael Snoyman mich...@snoyman.comwrote:
I'm wondering if anyone's run into this problem before, and if there's a
common solution.
I ran into it, asked about it on SO, and followed your advice. :)
___
Haskell-Cafe
Yitzchak Gale g...@sefer.org writes:
In fact, it even makes sense to define it as FunctorIO, with the only laws
being that liftIO commutes with fmap and preserves id, i.e., that it is a
natural transformation. (Those laws are also needed for ApplicativeIO and
MonadIO.)
Given that we are
Interesting. It's similar in spirit to basically a safe Coerce typeclass,
but for * - * types.
class Coerce a b where
coerce :: a - b
class Coerce1 f g where
coerce1 :: f a - g a
-- Dan Burton
On Tue, Oct 1, 2013 at 11:00 AM, John Wiegley jo...@fpcomplete.com wrote:
23 matches
Mail list logo
