Matthias Felleisen <xxxxxx@cs.rice.edu> writes:

> So if you were with 100 other people and they all jumped off the cliff, you
> would jump, too?

No, but when you are in the minority position, you need to make a stronger
care that the cliff is there, and that it is dangerous.  I don't think
you've done that.

> I also believe that we should study both the theory and the practice of
> languages. That's what distinguishes us from them. And there were only
> "them" I wouldn't be in CS.

One job of the CS academy is to distill the theory into something
practitioners can use and understand, and least the ones who care and
pay attention.  Thank you for attempting this.

> In a nutshell: W/o set! we can think of Scheme as a language that consists
> of a universe of data, with N disjoint, recognizable subsets, and operations
> on this universe of data. Some operations create data: cons, open-input-file,
> lambda. Others extract data from data. Yet others mutate some datum.

Yes, I see this point

> Set! cannot be explained as an operation on data. Only its *implementation*
> can be explained that way.

I'm missing the point here.  set! can be modeled (explained) using a
"box" model (set! changes the contents of the box), as was done in
Algol68 - and in classical denotational semantics.  Alternatively, you
can bring "frames" into your model, and again you are modifying data.
And of course objects can be modeled using lexical scoping and set!.

In other words, I still don't understand how this distinction is so
fundamental.  Yes, in one way of looking at things, there is a big
difference, but in other valid ways of looking at things, there is not.

The real question is: Does using set! for both variable assignment and
field assignment lead to confusion, programming mistakes,
hard-to-maintain programs, or more difficulty training programmers?
You believe it does, partly (I gather) because it obscures what you see
as a fundamental difference.  But you don't have any real evidence for
that, do you?  My mentioning other programming languages is partly to
show that the problems, if any, don't seem to be major.

> What's in Java? Mutation on objects. An assignment to a private variable is
>   only an abbreviation for this.x = foo;

Well, the extended set! is also only an abbreviation.

> The history of programming languages moves languages away from machine
> concepts and to abstractions. The key idea of abstraction is data
> abstraction, that is, trying to understand all computation in terms of data,
> which is the computational expression of information, and operations on
> data. FP and Scheme include functions in the set of data, which makes the
> world more uniform.

Control abstraction (tail-calls, call/cc) is also quite important to
the history of Scheme.
--
	--Per Bothner
xxxxxx@bothner.com   http://www.bothner.com/~per/