om>> wrote:
>>
>> Following a couple of discussions at ICFP I've put together a
>> proposal for desugaring do-notation to Applicative:
>>
>>
>> http://ghc.haskell.org/trac/__**ghc/wiki/ApplicativeDo<http://ghc.haskell.org/trac/__ghc/wiki/
a do-expression internally.
Cheers,
Simon
On Tue, Oct 1, 2013 at 2:39 PM, Simon Marlow mailto:marlo...@gmail.com>> wrote:
Following a couple of discussions at ICFP I've put together a
proposal for desugaring do-notation to Applicative:
http://ghc.haskell.org
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 is
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, on
On 2013-10-02 20:13, Reid Barton wrote:
> On Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett 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 d
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 Wed, Oct 2, 2013 at 1:50 PM, Edward Kmett 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 dependency on previou
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
:
>
> --
>
> Message: 1
> Date: Wed, 2 Oct 2013 09:12:26 +
> From:
> To: ,
> Cc: marlo...@gmail.com, glasgow-haskell-users@haskell.org,
> simo...@microsoft.com
> Subject: RE: Desugaring do-notation to Applicative
> Message-ID:
>
> Content-
On Wed, Oct 2, 2013 at 12:01 PM, 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.
>
Yes, or ordinary list comprehensions for that matter.
But there is a danger in desugaring to Applicative
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 wrote:
> Following a couple of discussions at ICFP I've put together a proposal for
> desugarin
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 th
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 o
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
e above
>> example we can desugar to
>> >
>> > e1 >>= \x ->
>> > join (\y z -> do { h[y]; ... })
>> > e2 e3
>> >
>> > I think. Again worth documenting if so.
>> >
>> > I don't know whether t
e2 e3
> >
> > I think. Again worth documenting if so.
> >
> > I don't know whether the tuple-version or join-version would be more
> optimisation friendly.
> >
> > Simon
> >
> > | -Original Message-
> > | From: Glasgow
ocumenting if so.
>
> I don't know whether the tuple-version or join-version would be more
> optimisation friendly.
>
> Simon
>
> | -Original Message-
> | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
> | boun...@haskell.org] On Behalf Of Simon Marlow
> | S
l-users
| Subject: Desugaring do-notation to Applicative
|
| Following a couple of discussions at ICFP I've put together a proposal
| for desugaring do-notation to Applicative:
|
|http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
|
| I plan to implement this following the addition of App
Following a couple of discussions at ICFP I've put together a proposal
for desugaring do-notation to Applicative:
http://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo
I plan to implement this following the addition of Applicative as a
superclass of Monad, which is due to take place sh
19 matches
Mail list logo
