Thanks for all the comments. I've updated the wiki page, in particular
to make it clear that Applictive do-notation would be an opt-in extension.
Cheers,
Simon
On 02/10/13 16:09, Dan Doel wrote:
Unfortunately, in some cases, function application is just worse. For
instance, when the result
On 02/10/13 17:01, Dag Odenhall wrote:
What about |MonadComprehensions|, by the way? The way I see it, it's an
even better fit for |Applicative| because the |return| is implicit.
It would happen automatically, because a Monad comprehension is
represented using the same abstract syntax as a
Wonderful!
On Fri, Oct 11, 2013 at 11:57 AM, Simon Marlow marlo...@gmail.com wrote:
On 02/10/13 17:01, Dag Odenhall wrote:
What about |MonadComprehensions|, by the way? The way I see it, it's an
even better fit for |Applicative| because the |return| is implicit.
It would happen
I think there are 2 use cases:
* explicit ado is best, it communicates the intent of the writer and can
give better error messages
* we want users to write code in a do style and the implementer to make it
applicative if possible
So we probably need to accommodate 2 use cases with 2 extensions,
I thought the whole point of Applicative (at least, reading Connor’s paper) was
to restore some function-application-style to the whole effects-thing, i.e. it
was the very point *not* to resort to binds or do-notation.
That being said, I’m all for something that will promote the use of the name
That isn't the only point. Applicative is also more general than Monad, in
that more things are Applicatives than they are Monads, so this would
enable to use a limited form of do-notation in more code. Also, Applicative
interfaces are more amenable to some static optimizations, since the
effects
Unfortunately, in some cases, function application is just worse. For
instance, when the result is a complex arithmetic expression:
do x - expr1; y - expr2; z - expr3; return $ x*y + y*z + z*x
In cases like this, you have pretty much no choice but to name intermediate
variables, because the
What about MonadComprehensions, by the way? The way I see it, it's an even
better fit for Applicative because the return is implicit.
On Tue, Oct 1, 2013 at 2:39 PM, Simon Marlow marlo...@gmail.com wrote:
Following a couple of discussions at ICFP I've put together a proposal for
desugaring
On Wed, Oct 2, 2013 at 12:01 PM, Dag Odenhall dag.odenh...@gmail.comwrote:
What about MonadComprehensions, by the way? The way I see it, it's an
even better fit for Applicative because the return is implicit.
Yes, or ordinary list comprehensions for that matter.
But there is a danger in
:
--
Message: 1
Date: Wed, 2 Oct 2013 09:12:26 +
From: p.k.f.holzensp...@utwente.nl
To: iavor.diatc...@gmail.com, dag.odenh...@gmail.com
Cc: marlo...@gmail.com, glasgow-haskell-users@haskell.org,
simo...@microsoft.com
Subject: RE: Desugaring do-notation to Applicative
Message
That is admittedly a pretty convincing example that we may want to provide
either a LANGUAGE pragma or a different syntax to opt in.
As a data point in this space, the version of the code I have in scheme
calls the version of 'do' that permits applicative desugaring 'ado'. A port
of it to Haskell
On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett ekm...@gmail.com wrote:
That is admittedly a pretty convincing example that we may want to provide
either a LANGUAGE pragma or a different syntax to opt in.
I suppose the Applicative desugaring can reliably be disabled by adding a
syntactic
Perhaps an alternative for this could be extending McBride's idiom brackets:
https://personal.cis.strath.ac.uk/conor.mcbride/pub/she/idiom.html
with a form of top-level let, something like:
(| let x = expr1
y = expr2
z = expr3
in x*y + y*z + z*x |)
=
pure (\x y z - x*y + y*z
On 2013-10-02 20:13, Reid Barton wrote:
On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett ekm...@gmail.com wrote:
That is admittedly a pretty convincing example that we may want to provide
either a LANGUAGE pragma or a different syntax to opt in.
I suppose the Applicative desugaring can
What happens when there are some monad things that precede the applicative bit:
do { x - e1
; y - e2[x]
; z - e3[x]
; h[y]
... }
does this convert to
do { x - e1
; (y,z) - (,) $ e1 * e2
; h[y]
...
I assume so, but it would be good to say.
Also worth noting that join can
The soundness of this desugaring depends on the Applicatives and Monads
following some of the laws. I think that's OK, personally, but this assumption
should be made loudly somewhere, and the feature should be opt-in. As far as I
know, GHC currently makes no assumptions about lawful class
At least Control.Category has RULES that exploit the category laws for
optimization. Whether this counts as *GHC* making assumptions, I don't
know. :-)
On Tue, Oct 1, 2013 at 10:39 PM, Richard Eisenberg e...@cis.upenn.eduwrote:
The soundness of this desugaring depends on the Applicatives and
Hello,
I talked to Simon PJ about this at ICFP, and the use case that I'm
interested in is the one where we infer an `Applicative` constraint instead
of `Monad` for things of the form:
do { x1 - e1; x2 - e2; ...; pure (f x1 x2 ...) }
as long as the `xs` do not appear in the `es`. I am
18 matches
Mail list logo
