"Tim Peters" <tim.one@home.com> writes: I'd add finite maps to the list, aka associative arrays ("dictionaries" in Python). Viewing a finite map as a subset of the product of the key and value sets isn't particularly illuminating, and especially not in a programming context. Yes, finite maps and functions should be added to the constructors of the data definition list. Omitted by accident. But, on recursion vs iteration you don't seem to know much about Scheme: Heartily agreed. Where Python parts company is in believing that *all* iteration is better expressed via recursion, and in particular iteration over lists. The notion that for element in list: do something with element 1. Here is why this match that I am talking about matters: datatype list = null | cons of int * list ^ | | | ------------------------------ I am using ML notation to spec a datatype, and the backpointer shows the self-reference in the data definition. Now compare this to the function definition: f(some_list) = (cond [(null? some_list) ...] [(cons? some_list) ... (first some_list) ... f(rest(some_list))]) ^ | | | -------------------------------------------------------------- Number of function clauses: 2, because there are 2 clauses in the data def Selectors in second clause: 2, because there are 2 fields in the data def Recursion in the second clause: yes, because there is self-ref in the data def Recursion on the second selector: yes, because ... Now show me how to explain this with a for-loop. Now show me how to tell kids that all this generalizes to dd's with 10 clauses and 22 self-refs? 2. Scheme abstracts uniformly with lambda (Python doesn't). So, of course we teach that the same pattern for list-processing comes up over and over again. And then we show how to abstract: using map and for-each. From then on students understand that (for-each (lambda (element) (display element) (newline)) list-of-elements) is perfectly okay. But, they also understand how to abstract for a data def with 22 clauses and 10 self-references. 3. You write more stuff on reductionist view of programming. I didn't advertise a reductionist view. I said that one teaches matching of data defs and functions first, and then one moves on to abstractions. The reason is that students understand the why and learn to do things on their own rather than copy patterns and play monkey at the keyboard. Having said all that one can teach some of these things in Python of course. (If Python had abstracted in a uniform fashion, that would be easier of course.) Having said all that, I must admit that I don't think of R5RS but my own Scheme. -- Matthias