On Wed, 16 Mar 2005 00:36:40 +0100, Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> > >BTW, the fact that a closure refers to a variable itself rather to its >current value can be used to check the true attitude of languages with >respect to functional programming, by observing how they understand >their basic loops :-) > >Python loses: > >>>> closures = [] >>>> for i in range(10): >... def add(x): >... return x + i >... closures.append(add) >... >>>> closures[5](1000) >1009 > [snip] >Scheme wins: > >> (let ((closures (make-vector 10))) > (do ((i 0 (+ i 1))) > ((= i 10)) > (vector-set! closures i (lambda (x) (+ x i)))) > ((vector-ref closures 5) 1000)) >1005 > >and what is perhaps surprising, Perl wins: > >$ perl -e ' > foreach my $i (0..9) { > push @closures, sub {$_[0] + $i} > } > print $closures[5](1000), "\n"' >1005 Smalltalk 'loses' too: closures := Array new: 10. 1 to: 10 do: [:i | closures at: i put: [:x| x + i]]. (closures at: 5) value: 1000 returns 1011 >If you think it's unlikely that one would want to keep a closure >referring to a loop control variable longer than the loop iteration >which has created it, think about the loop body spawning a thread. I'm still not convinced this is really useful, but Scheme's behavior seems more intuitive. -- http://mail.python.org/mailman/listinfo/python-list