Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: recursive 'let' ? (Arjun Comar)
2. Re: recursive 'let' ? (Kim-Ee Yeoh)
----------------------------------------------------------------------
Message: 1
Date: Mon, 14 Apr 2014 16:04:32 -0400
From: Arjun Comar <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] recursive 'let' ?
Message-ID:
<CADjRcrW8RojkQfsoQ7fnYgQiGL3FZpS6DdBnwof-_X=jdjb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
John,
That's classic mutual recursion. In your example, the values of b and c
depend entirely on f. For example what if
f = const a
Now b and c are obviously a and its not ambiguous. Similarly, mutually
recursive functions can compute values for b and c.
Do you have a similar issue with a definition like:
b = f a b
or is that fine? If so, why? If not, why not?
On Mon, Apr 14, 2014 at 11:24 AM, John M. Dlugosz
<[email protected]>wrote:
> I don't mind recursive *functions*. It's recursive definition of single
> computed values that looked odd to me. Lazy evaluation makes all the
> difference. Looking at
> b= f a c
>
> c = f a b
> I was thinking, "how can it figure out what b and c need to be?" because
> I'm used to this meaning that it needs to come up with an actual value
> right now.
>
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140414/82b686e9/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 15 Apr 2014 07:57:19 +0700
From: Kim-Ee Yeoh <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] recursive 'let' ?
Message-ID:
<capy+zdt12uc4ekccfqtdcmzaerg3nn-cof8uv-y3utt7f87...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Apr 14, 2014 at 11:24 AM, John M. Dlugosz
<[email protected]>wrote:
> I don't mind recursive *functions*. It's recursive definition of single
>> computed values that looked odd to me. Lazy evaluation makes all the
>> difference. Looking at
>> b= f a c
>>
>> c = f a b
>> I was thinking, "how can it figure out what b and c need to be?" because
>> I'm used to this meaning that it needs to come up with an actual value
>> right now.
>>
>>
To amplify Arjun's point,
b = f a c
c = f a b
is equivalent to
b = f a (f a b)
c = f a (f a c)
and now the mutual recursion that's troubling John vanishes.
They become plain ol' self-recursive functions.
I don't think mutual recursion is harder to make sense of than
self-recursion. I think self-recursion appears easier than mutual
recursion, but that's deceptive. It's actually just as hard!
>
>>
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://www.haskell.org/mailman/listinfo/beginners
>>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20140415/1e86fd18/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 70, Issue 32
*****************************************
