On 14 June 2010 16:27, Eli Barzilay
<eli@x> wrote:
On Jun 14, Brian Harvey wrote:
> language to support teams of 500 lousy programmers.
What I understood from David is that when he uses `map' in his code,
he will never pass it a function that is not his too.
No. I simply never expose an encapsulated list structure to potentially malicious code. That is not the same thing as your understanding. I often provide type-specific map combinators *entirely* so that my encapsulations are not violated. Such is the big win of using a HOmF language like Scheme.
If a user of one of my libraries wants to make their own list of my objects and then clobber its structure that's entirely her own business, but I don't provide access to *my* lists through *my* APIs.
Seems that I need to repeat this a fifth time:
No, you don't. You have advocated a position which actually *removes* the ability to mutate one of the two basic aggregate types in Scheme. This seems rather arbitrary, and wrong-headed (due to knock-on effects) in light of things like breaking mutable a-lists. Scheme is a language which allows free mutation of bindings and primitive objects. Immutable pairs is a big step on a slippery slope to a very different language.
currently (RnRS) Scheme is guessing wrong in >99% of the
cases, and it makes it extremely hard for me to correct it.
This is FUD. The occurrence of the class of bugs for which you have highlighted the potential is *far* (orders of magnitude) lower than this. You have a point, and it is a real problem from a provability standpoint, but practically it just doesn't happen that often. The whole point of using a map combinator is so that you can abstract away from aggregate structure: anyone who is mutating the aggregate structure which is being operated on by the combinator has fundamentally *missed the point* and should be hung, drawn, and quartered (or at least made to fix the damn bug himself).
david