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: fibonacci and concurrent recursion (Brent Yorgey)
2. Re: partial application (Keshav Kini)
3. Re: partial application (Keshav Kini)
4. Re: fibonacci and concurrent recursion (Christoffer Buchholz)
5. implicit deletion of ghci history (Christopher Howard)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Dec 2012 15:38:05 -0500
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] fibonacci and concurrent recursion
To: Christoffer Buchholz <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Mon, Dec 03, 2012 at 08:10:00PM +0100, Christoffer Buchholz wrote:
> All right, thanks for clearing up my misconceptions!
>
> I'm trying to understand, but I still don't think I do. Any idea how
> I can get to understand it?
Think about it hard. Read a lot. Play with some examples. Ask
questions.
> When I look at your "illustration" where you named the parts, it
> does seem more clear, but I don't get how e.g. at the third number
> `(tail f)` equals f'' equals 1? f'' clearly equals 1, but `(tail f)`
> would equal 1:1, wouldn't it? Same at the fourth number, f'' clearly
> equals 2, but `(tail f)` would equal 1:1:2, wouldn't it? Or am I
> misunderstand what `f`?
No, in
f = 0 : f'@(1 : f''@(1 : zipWith (+) f' f''))
I mean that
f' = 1 : 1 : zipWith (+) f' f''
and
f'' = 1 : zipWith (+) f' f''
Also, note that 'tail f' cannot be 1:1:2, since that does not even
type check. It is 1:1:2:<some unevaluated expression>, where in
particular the unevaluated expression involves zipWith and refers back
to f' and f''.
-Brent
> On Monday den 3. December 2012 at 16.31, Brent Yorgey wrote:
>
> > Hi Chris,
> >
> > On Mon, Dec 03, 2012 at 04:05:28PM +0100, Christoffer Buchholz wrote:
> > > Hi
> > >
> > > I have been looking at this fibonacci implementation:
> > >
> > > f = 0:1:(zipWith (+) f (tail f))
> > >
> > > and I have been trying to fit it inside my head. I am not quite there
> > > yet, though.
> > >
> > > And it is easy to see that it works, but what I do not understand is how
> > > the two recursive applications progress. How do they evolve concurrently?
> > > For each execution of `f`, `f` will be executed twice. So how does all
> > > these results end up in the same list?
> >
> > f is not 'executed'. And it certainly is not executed twice for each
> > execution, or anything like that.
> >
> > f is simply a *name* for an *expression*. All three occurrences of f
> > in the code above refer to the *same* expression. They do not "evolve
> > concurrently", they simply *are* the same thing. Operationally, they
> > are all represented by pointers to the exact same list structure in
> > memory. Note also that simply referring to an expression does not
> > 'do' anything; when I said 'Hi Chris' above, it did not cause you to
> > be 'executed'. I simply referred to you, and you went on being the
> > same person you were all along.
> >
> > The thing to think about is not execution but the *process of
> > evaluation*. Unlike people, Haskell expressions can be partially
> > evaluated, and the process of evaluation happens on demand.
> > Unfortunately it is very difficult to show the process of evaluation
> > in an email because for this expression it really requires thinking
> > about the expression as a *graph*, and those are hard to draw in an
> > email.
> >
> > At first f looks like this:
> >
> > f = 0 : 1 : zipWith (+) f (tail f)
> >
> > Now, if we demand to know the next element of the list, we need to
> > evaluate the call to zipWith. zipWith, in turn, demands to know the
> > first elements of its arguments. Well, we can see that the first
> > element of f is 0, and the first element of (tail f) is 1. So the
> > next element of the list is (0+1) = 1. At this point f looks like
> > this:
> >
> > f = 0 : f'@(1 : f''@(1 : zipWith (+) f' f''))
> >
> > Here's where a picture would be really helpful. Instead of drawing a
> > graph I have given certain parts of the expression names. You can see
> > that the arguments to zipWith are really just pointers back to
> > subexpressions of f itself. Continuing, the next step would look like
> > this:
> >
> > f = 0 : 1 : f'@(1 : f''@(2 : zipWith (+) f' f''))
> >
> > And so on.
> >
> > I hope that was at least somewhat helpful, though I suspect you will
> > probably still be confused. That's OK though; embrace the confusion
> > and keep asking questions. =)
> >
> > -Brent
> >
> > _______________________________________________
> > Beginners mailing list
> > [email protected] (mailto:[email protected])
> > http://www.haskell.org/mailman/listinfo/beginners
> >
> >
>
>
------------------------------
Message: 2
Date: Mon, 03 Dec 2012 13:04:36 -0800
From: Keshav Kini <[email protected]>
Subject: Re: [Haskell-beginners] partial application
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain
Brent Yorgey <[email protected]> writes:
> On Mon, Dec 03, 2012 at 12:28:08PM +0000, Miguel Negrao wrote:
>> Is there a syntax in Haskell for partial application that would be something
>> like this the following ?
>>
>> f a b c d = a +b+ c+ d
>>
>> g = f _ 1 2 3
>>
>> or the only way to do it is like below ?
>>
>> g = (\x -> f x 1 2 3)
>
> Yes, a lambda is the only way to do it.
In the case where you have fewer (specifically two) variables, you can
also use `flip`::
f a b = a / b
-- g = f _ 2 can be written as:
g = flip f 2
-Keshav
------------------------------
Message: 3
Date: Mon, 03 Dec 2012 13:10:53 -0800
From: Keshav Kini <[email protected]>
Subject: Re: [Haskell-beginners] partial application
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Brent Yorgey <[email protected]> writes:
> On Mon, Dec 03, 2012 at 03:20:41PM +0000, Miguel Negrao wrote:
>>
>> A 03/12/2012, ?s 12:53, Brent Yorgey escreveu:
>> >> Is there a syntax in Haskell for partial application that would be
>> >> something like this the following ?
>> >>
>> >> f a b c d = a +b+ c+ d
>> >>
>> >> g = f _ 1 2 3
>> > Yes, a lambda is the only way to do it.
>>
>> Given how compact haskell?s syntax can be, is there a reason why
>> implementing such placeholders is not a good idea for haskell ?
>
> Yes: it would introduce horrible ambiguity. Consider
>
> (f (g _ 1 2))
>
> Does it mean
>
> (f (\x -> g x 1 2))
>
> or
>
> (\x -> f (g x 1 2))
>
> ? I don't know of any good reason to prefer one over the other. Any
> rule you come up with is likely to have other weird corner cases you
> hadn't considered. As I understand it, Scala actually does have this
> feature, along with lots of confusing, ugly, ad-hoc rules to
> disambiguate situations like the above.
Another data-point: Mathematica also has this feature, if I correctly
understand the above posts [1]. The examples you gave would look like::
(f (g _ 1 2)) ~= f[g[#1, 1, 2]]&
(f (\x -> g x 1 2)) ~= f[g[#1, 1, 2]&]
(\x -> f (g x 1 2)) ~= f[g[#1, 1, 2]]&
So it seems the ambiguity is resolved by having this scope-specifying
symbol '&'.
[1] http://reference.wolfram.com/mathematica/tutorial/PureFunctions.html
-Keshav
------------------------------
Message: 4
Date: Mon, 3 Dec 2012 22:18:39 +0100
From: Christoffer Buchholz <[email protected]>
Subject: Re: [Haskell-beginners] fibonacci and concurrent recursion
To: Brent Yorgey <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
This link that Zbigniev Stanasiuk sent me explains it very well. I think I
understand it know.
The link:
http://stackoverflow.com/questions/6273621/understanding-a-recursively-defined-list-fibs-in-terms-of-zipwith
--
Christoffer Buchholz
On Monday den 3. December 2012 at 21.38, Brent Yorgey wrote:
> On Mon, Dec 03, 2012 at 08:10:00PM +0100, Christoffer Buchholz wrote:
> > All right, thanks for clearing up my misconceptions!
> >
> > I'm trying to understand, but I still don't think I do. Any idea how
> > I can get to understand it?
> >
>
>
> Think about it hard. Read a lot. Play with some examples. Ask
> questions.
>
> > When I look at your "illustration" where you named the parts, it
> > does seem more clear, but I don't get how e.g. at the third number
> > `(tail f)` equals f'' equals 1? f'' clearly equals 1, but `(tail f)`
> > would equal 1:1, wouldn't it? Same at the fourth number, f'' clearly
> > equals 2, but `(tail f)` would equal 1:1:2, wouldn't it? Or am I
> > misunderstand what `f`?
> >
>
>
> No, in
>
> f = 0 : f'@(1 : f''@(1 : zipWith (+) f' f''))
>
> I mean that
>
> f' = 1 : 1 : zipWith (+) f' f''
>
> and
>
> f'' = 1 : zipWith (+) f' f''
>
> Also, note that 'tail f' cannot be 1:1:2, since that does not even
> type check. It is 1:1:2:<some unevaluated expression>, where in
> particular the unevaluated expression involves zipWith and refers back
> to f' and f''.
>
> -Brent
>
> > On Monday den 3. December 2012 at 16.31, Brent Yorgey wrote:
> >
> > > Hi Chris,
> > >
> > > On Mon, Dec 03, 2012 at 04:05:28PM +0100, Christoffer Buchholz wrote:
> > > > Hi
> > > >
> > > > I have been looking at this fibonacci implementation:
> > > >
> > > > f = 0:1:(zipWith (+) f (tail f))
> > > >
> > > > and I have been trying to fit it inside my head. I am not quite there
> > > > yet, though.
> > > >
> > > > And it is easy to see that it works, but what I do not understand is
> > > > how the two recursive applications progress. How do they evolve
> > > > concurrently? For each execution of `f`, `f` will be executed twice. So
> > > > how does all these results end up in the same list?
> > >
> > > f is not 'executed'. And it certainly is not executed twice for each
> > > execution, or anything like that.
> > >
> > > f is simply a *name* for an *expression*. All three occurrences of f
> > > in the code above refer to the *same* expression. They do not "evolve
> > > concurrently", they simply *are* the same thing. Operationally, they
> > > are all represented by pointers to the exact same list structure in
> > > memory. Note also that simply referring to an expression does not
> > > 'do' anything; when I said 'Hi Chris' above, it did not cause you to
> > > be 'executed'. I simply referred to you, and you went on being the
> > > same person you were all along.
> > >
> > > The thing to think about is not execution but the *process of
> > > evaluation*. Unlike people, Haskell expressions can be partially
> > > evaluated, and the process of evaluation happens on demand.
> > > Unfortunately it is very difficult to show the process of evaluation
> > > in an email because for this expression it really requires thinking
> > > about the expression as a *graph*, and those are hard to draw in an
> > > email.
> > >
> > > At first f looks like this:
> > >
> > > f = 0 : 1 : zipWith (+) f (tail f)
> > >
> > > Now, if we demand to know the next element of the list, we need to
> > > evaluate the call to zipWith. zipWith, in turn, demands to know the
> > > first elements of its arguments. Well, we can see that the first
> > > element of f is 0, and the first element of (tail f) is 1. So the
> > > next element of the list is (0+1) = 1. At this point f looks like
> > > this:
> > >
> > > f = 0 : f'@(1 : f''@(1 : zipWith (+) f' f''))
> > >
> > > Here's where a picture would be really helpful. Instead of drawing a
> > > graph I have given certain parts of the expression names. You can see
> > > that the arguments to zipWith are really just pointers back to
> > > subexpressions of f itself. Continuing, the next step would look like
> > > this:
> > >
> > > f = 0 : 1 : f'@(1 : f''@(2 : zipWith (+) f' f''))
> > >
> > > And so on.
> > >
> > > I hope that was at least somewhat helpful, though I suspect you will
> > > probably still be confused. That's OK though; embrace the confusion
> > > and keep asking questions. =)
> > >
> > > -Brent
> > >
> > > _______________________________________________
> > > Beginners mailing list
> > > [email protected] (mailto:[email protected])
> > > http://www.haskell.org/mailman/listinfo/beginners
> > >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20121203/23e51b22/attachment-0001.htm>
------------------------------
Message: 5
Date: Mon, 03 Dec 2012 21:08:33 -0900
From: Christopher Howard <[email protected]>
Subject: [Haskell-beginners] implicit deletion of ghci history
To: Haskell Beginners <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
This may sound like a strange question, but are there any commands or
activities in ghc / ghci / cabal that implicitly delete your ghci
history? A few times in the last few days I've started ghci, to find I
only had about five or ten commands in my history, even though I execute
dozens of commands each day. However, if I quickly close and reopen
ghci, the commands that I just entered are still there.
I can't think of anything unique to my system that would cause this,
unless maybe Emacs is doing something weird with it in Haskell mode.
I'm running Gentoo Linux (amd64) with GHC 7.4.1 and cabal-install 1.16.0.2.
--
frigidcode.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20121203/97ba9612/attachment-0001.pgp>
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 54, Issue 6
****************************************
