On 5 September 2011 02:38, Sebastian Fischer fisc...@nii.ac.jp wrote:
These are important questions. I think there is a trade-off between
supporting many cases and having a simple desugaring. We should find a
sweet-spot where the desugaring is reasonably simple and covers most
idiomatic cases.
On 5 September 2011 08:35, Max Bolingbroke batterseapo...@hotmail.com wrote:
(If you do want to support the type checker only generating requests
for an Applicative constraint you could just insist that user code
writes pure instead of return, in which case this would be quite
easy to
Hi Max,
thanks for you proposal!
Using the Applicative methods to optimise do desugaring is still
possible, it's just not that easy to have that weaken the generated
constraint from Monad to Applicative since only degenerate programs
like this one won't use a Monad method:
Is this still
Hi again,
I think the following rules capture what Max's program does if applied after
the usual desugaring of do-notation:
a = \p - return b
--
(\p - b) $ a
a = \p - f $ b -- 'free p' and 'free b' disjoint
--
((\p - f) $ a) * b
a = \p - f $ b -- 'free p' and 'free f' disjoint
--
f $ (a =
On 5 September 2011 13:41, Sebastian Fischer fisc...@nii.ac.jp wrote:
Hi again,
I think the following rules capture what Max's program does if applied
after the usual desugaring of do-notation:
a = \p - return b
--
(\p - b) $ a
a = \p - f $ b -- 'free p' and 'free b' disjoint
--
On Mon, Sep 5, 2011 at 10:19 PM, Thomas Schilling
nomin...@googlemail.comwrote:
a = \p - f $ b -- 'free p' and 'free b' disjoint
--
((\p - f) $ a) * b
Will there also be an optimisation for some sort of simple patterns? I.e.,
where we could rewrite this to:
liftA2 (\pa pb - f ...) a
The problem in the parallel distribution of monadic computations that may
have been Applicative seems to be the operator
But if Monad is defined as a subclass of applicative:
http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
then can be defined as () = (*) and
On 5 September 2011 15:49, Sebastian Fischer fisc...@nii.ac.jp wrote:
On Mon, Sep 5, 2011 at 10:19 PM, Thomas Schilling nomin...@googlemail.com
wrote:
a = \p - f $ b -- 'free p' and 'free b' disjoint
--
((\p - f) $ a) * b
Will there also be an optimisation for some sort of simple
It seems like complication for very slight advantage.
Firstly, so far only UU Parsing and Trifecta appear to have optimized
Applicative instances (does the optimization work for mixed
Monad+Applicative parsers or only if the whole parser is
Applicative?). Secondly if you want Applicative then you
On Sat, Sep 3, 2011 at 19:34, Daniel Peebles pumpkin...@gmail.com wrote:
...
Of course, the fact that the return method is explicitly mentioned in my
example suggests that unless we do some real voodoo, Applicative would have
to be a superclass of Monad for this to make sense. But with the new
Good idea! I'd forgotten about monad comprehensions.
On Sun, Sep 4, 2011 at 3:11 AM, Shachaf Ben-Kiki shac...@gmail.com wrote:
On Sat, Sep 3, 2011 at 19:34, Daniel Peebles pumpkin...@gmail.com wrote:
...
Of course, the fact that the return method is explicitly mentioned in my
example
On Sun, Sep 4, 2011 at 11:34 AM, Daniel Peebles pumpkin...@gmail.com wrote:
I was wondering what people thought of a smarter do notation.
I'd support it (for both do notation and monad comprehensions) once
Applicative is a superclass of Monad.
To me it looks light a slight complication for an
I don't quite understand how this would work. For example, would it work
for these examples?
do x - blah
let foo = return
foo (f x) -- Using an alias of return/pure
do x - Just blah
Just (f x) -- another form of aliasing
do x - blah
return (g x x) -- could perhaps
It's not the same as what you propose, but it's related, so for
discussion, I just want to point out idiom brackets (an analog for
do-notation for Applicative functors) which have been introduced in
some Haskell-related languages. Examples are Idris
On Sun, Sep 4, 2011 at 12:24 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote:
Hi all,
For example, if I write in a do block:
x - action1
y - action2
z - action3
return (f x y z)
that doesn't require any of the
Yeah, I use SHE and her idiom brackets for several of my projects, but there
are many cases in which they're awkward too.
Another consideration about the monad comprehensions is that unbound
(i.e., with no -) statements in a monad comprehension are treated as
MonadPlus guards, so the applicative
These are important questions. I think there is a trade-off between
supporting many cases and having a simple desugaring. We should find a
sweet-spot where the desugaring is reasonably simple and covers most
idiomatic cases.
So I guess it's possible to detect the pattern:
do x1 - foo1; ...;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tasty.
On 04/09/11 12:34, Daniel Peebles wrote:
Hi all,
I was wondering what people thought of a smarter do notation. Currently,
there's an almost trivial desugaring of do notation into (=), (), and
fail (grr!) which seem to naturally imply
On 4 September 2011 12:34, Daniel Peebles pumpkin...@gmail.com wrote:
Hi all,
For example, if I write in a do block:
x - action1
y - action2
z - action3
return (f x y z)
that doesn't require any of the context-sensitivty that Monads give you, and
could be processed a lot more efficiently
With parsers, for example, it amounts to you have a context-free vs. a
context-sensitive language. The functions hidden behind a monadic bind are
effectively opaque to any sort of analysis, whereas the static structure of
an applicative can be analyzed as much as you want. Ed Kmett does this in
20 matches
Mail list logo
