John Cowan wrote:
"In Scheme all functions are lambdas": but they don't have the
restrictions of Python lambdas.
Maybe one could say:
In Scheme all functions are lambdas and all lambdas are functions.
They have the power of regular Python functions and the usefulness of
Python lambdas, at the same time.
SRFI-1 provides append!, but note that you must capture the return
values of destructive (!) list functions; you can't just rely on the
side effects. There is no guarantee that append! will actually side-
effect its arguments; you are just permitting it to do so.
Here I would add a generic explanation on the conceptual difference
between Python's and Scheme's "destructive operations", more than a
list of behaviours. Let's see if I can come up with something:
A Python list is a single object. Its destructive or in-place
operations (such as sort or append) simply operate on the whole object
and modify it in-place. Scheme "values" that are also single objects
(such as strings, pairs, or hash tables) behave in the same way.
A Scheme list, on the other hand, is a chain of simpler objects
(pairs) so you typically don't have operations that modify the "whole"
list in-place. Both Scheme's "destructive" and "non-destructive" list
operations return a new list with the requested changes. This new
list (the return value of the operation) will have to be used
somewhere to be of use, even if just by re-assigning it to the same
variable:
(set! some-list (reverse! some-list)) ;same as: some_list.reverse()
The difference between non-destructive and destructive operations is
that the destructive sort may build the new list by recycling the
pairs that make up the old chain. A destructive operation is often
more optimized, but you should only use it when: 1. you are
reassigning the return value to the same variable, see above, or 2.
you won't use that variable anymore, after the operation.
This strange paradigm comes from Scheme's emphasis on functional
programming. A Scheme programmer doesn't expect a variable (such as
"some-list" above) to change its immediate, direct value, unless he
explicitly "set!"s it to a new value. The functional programming
style completely avoids "set!", or variable assignment, and that is
why this paradigm makes sense.
-Tobia
_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users
