[pure-lang-svn] SF.net SVN: pure-lang:[708] pure/trunk/pure.1.in

[<ag...@us...>]

Revision: 708
          http://pure-lang.svn.sourceforge.net/pure-lang/?rev=708&view=rev
Author:   agraef
Date:     2008-09-05 01:12:59 +0000 (Fri, 05 Sep 2008)

Log Message:
-----------
Update documentation.

Modified Paths:
--------------
    pure/trunk/pure.1.in

Modified: pure/trunk/pure.1.in
===================================================================
--- pure/trunk/pure.1.in	2008-09-05 00:59:21 UTC (rev 707)
+++ pure/trunk/pure.1.in	2008-09-05 01:12:59 UTC (rev 708)
@@ -614,7 +614,7 @@
 .nf
 > foo x = bar \fBwith\fP bar y = x+y \fBend\fP;
 > \fBlet\fP f = foo 99; f;
-{{closure bar}}
+#<closure bar>
 > f 10, f 20;
 109,119
 .fi
@@ -800,7 +800,7 @@
 .nf
 > fibs = 0L : 1L : zipwith (+) fibs (tail fibs) &;
 > fibs;
-0L:1L:{{thunk 0xb5f875e8}}
+0L:1L:#<thunk 0xb5f875e8>
 .fi
 .PP
 Note the `&' on the tail of the list. This turns `fibs' into a stream, which
@@ -819,7 +819,7 @@
 .sp
 .nf
 > take 10 fibs;
-0L:1L:{{thunk 0xb5f87630}}
+0L:1L:#<thunk 0xb5f87630>
 .fi
 .PP
 Hmm, not much progress there, but that's just how streams work (or rather
@@ -843,7 +843,7 @@
 .fi
 .PP
 Well, this naive definition of the Fibonacci stream works, but it's awfully
-inefficient. In fact, it takes exponential running time to determine the
+slow. In fact, it takes exponential running time to determine the
 .IR n th
 member of the sequence, because of the two recursive calls to `fibs' on the
 right-hand side. This defect soon becomes rather annoying if we access larger
@@ -864,10 +864,10 @@
 > \fBstats off\fP
 .fi
 .PP
-It's quite apparent that the ratios between successive running times converge
-to the golden ratio from above (which is of course no accident!). So, assuming
-a fast computer which can produce the first stream element in a nanosecond, a
-conservative estimate of the time needed to compute just the 128th Fibonacci
+It's quite apparent that the ratios between successive running times are about
+the golden ratio (which is of course no accident!). So, assuming a fast
+computer which can produce the head element of a stream in just a nanosecond,
+a conservative estimate of the time needed to compute just the 128th Fibonacci
 number would already exceed the current age of the universe by some 29.6%, if
 done this way. It goes without saying that this kind of algorithm won't even
 pass muster in a freshman course.
@@ -904,11 +904,11 @@
 > \fBclear\fP fibs
 > \fBlet\fP fibs = fix (\ef -> 0L : 1L : zipwith (+) f (tail f) &);
 > fibs;
-0L:1L:{{thunk 0xb58d8ae0}}
+0L:1L:#<thunk 0xb58d8ae0>
 > takel 10 fibs;
 [0L,1L,1L,2L,3L,5L,8L,13L,21L,34L]
 > fibs;
-0L:1L:1L:2L:3L:5L:8L:13L:21L:34L:{{thunk 0xb4ce5d30}}
+0L:1L:1L:2L:3L:5L:8L:13L:21L:34L:#<thunk 0xb4ce5d30>
 .fi
 .PP
 As you can see, the invokation of our `takel' function forced the
@@ -960,7 +960,7 @@
 .sp
 .nf
 > \fBlet\fP rats = [m,n-m; n=2..inf; m=1..n-1; gcd m (n-m) == 1]; rats;
-(1,1):{{thunk 0xb5fd08b8}}
+(1,1):#<thunk 0xb5fd08b8>
 > takel 10 rats;
 [(1,1),(1,2),(2,1),(1,3),(3,1),(1,4),(2,3),(3,2),(4,1),(1,5)]
 .fi


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.