[Haskell-cafe] List Monads and non-determinism

Matt Ford matt at dancingfrog.co.uk
Sat Jul 20 08:50:36 CEST 2013


Hi,

Thanks all for your good help.   I was caught up in sequential thinking about monads so much so that I treated the lambda expressions as separate functions rather than a nested big one. 

That clears up a lot of nagging doubts. 

Cheers,

Matt. 

On 20 Jul 2013, at 00:18, Rogan Creswick <creswick at gmail.com> wrote:

> On Fri, Jul 19, 2013 at 3:58 PM, Matt Ford <matt at dancingfrog.co.uk> wrote:
>> Hi,
>> 
>> Thanks for the help.
>> 
>> I thought >>= was left associative?  It seems to be in the examples from Learn You A Haskell.
>> 
>> I tried to use the associative law to bracket from the right but it didn't like that either...
>> 
>> [1,2] >>= (\x -> (\n -> [3,4])) x  >>= \m -> return (n,m))
> 
> I think the issue is that you need to first take into account the lambdas *then* use what you know about the properties of (>>=).
> 
> I found this stackoverflow answer helpful (http://stackoverflow.com/a/11237469)
> 
> "The rule for lambdas is pretty simple: the body of the lambda extends as far to the right as possible without hitting an unbalanced parenthesis."
> 
>  So, the first lambda runs to the end of the expression:
> 
> [1,2] >>= (\n -> [3,4] >>= \m -> return (n,m))
> 
> Now, there is still a lambda nested inside the first lambda: \m -> return (n,m)
> 
> [1,2] >>= (\n -> [3,4] >>= (\m -> return (n,m)))
> 
> You violated the implied grouping that these new parentheses make explicit when you tried to apply the associative law above.
> 
> Timon's post continues from this point to show the full deconstruction.
> 
> --Rogan
> 
>> 
>> Any thoughts?
>> 
>> Matt 
>> 
>> On 19 Jul 2013, at 23:35, Rogan Creswick <creswick at gmail.com> wrote:
>> 
>>> On Fri, Jul 19, 2013 at 3:23 PM, Matt Ford <matt at dancingfrog.co.uk> wrote:
>>>> I started by putting brackets in
>>>> 
>>>> ([1,2] >>= \n -> [3,4]) >>= \m -> return (n,m)
>>>> 
>>>> This immediately fails when evaluated: I expect it's something to do
>>>> with the n value now not being seen by the final return.
>>> 
>>> You're bracketing from the wrong end, which your intuition about n's visibility hints at.  Try this as your first set of parens:
>>> 
>>>  [1,2] >>= (\n -> [3,4] >>= \m -> return (n,m))
>>> 
>>> --Rogan
>>>  
>>>> 
>>>> It seems to me that the return function is doing something more than
>>>> it's definition (return x = [x]).
>>>> 
>>>> If ignore the error introduced by the brackets I have and continue to
>>>> simplify I get.
>>>> 
>>>> [3,4,3,4] >>= \m -> return (n,m)
>>>> 
>>>> Now this obviously won't work as there is no 'n' value.  So what's
>>>> happening here? Return seems to be doing way more work than lifting the
>>>> result to a list, how does Haskell know to do this?  Why's it not in the
>>>> function definition?  Are lists somehow a special case?
>>>> 
>>>> Any pointers appreciated.
>>>> 
>>>> Cheers,
>>>> 
>>>> --
>>>> Matt
>>>> 
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130720/4ec05891/attachment.htm>


More information about the Haskell-Cafe mailing list