On 19 Jun 2008, at 5:53 pm, Jules Bean wrote:
Richard A. O'Keefe wrote:
- what you get is a reference to a variable (as you do in Scheme)
but loop variables really are variables, not names for values,
so lambdas created in different iterations of the same loop point
so the same loop variable, and do not remember the value it had
when they were created. The proposal explains how to work around
this.
This one trips everyone up in Javascript.
What's going on here is a nasty interaction with the semantics of loops.
In Smalltalk and Scheme (to name two languages with closures and
mutable variables), each iteration of a loop in principle creates a new
variable binding. Scheme example:
(do ((i 0 (+ i 1))
(l '() (cons (lambda (x) (* x i)) l)))
((>= i 10) l))
is equivalent to
let f i l = if i >= 10 then l
else f (i + 1) ((\x -> x * i) : l)
in f 0 []
except for i and l being potentially mutable in Scheme but not Haskell.
The Smalltalk equivalent would be
(0 to: 9) collect: [:i | [:x | x*i]]
in which (a) each iteration creates a *new* i, and (b) method and
block parameters are *not* mutable, because they never are in Smalltalk.
Importing only values into closures would not work for Smalltalk.
Consider the usual implementation of Smalltalk's equivalent of 'fold:
Collection>>
inject: initial into: function
|r|
r := initial.
self do: [:each | r := function value: r value: each].
^r
The mutablity of r here really isn't a problem. Nor is the mutability
of variables _as such_ really the problem in the PHP proposal.
The problem is that it's the *same* variable every time. If PHP
loops introduced new bindings on every iteration, this particular
problem would not exist.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
