It's a bit difficult making out what exactly was said by whom because your
	news client doesn't seem to have done any indenting.

The indenting was *definitely* there.
	We agree that it's very useful.  But I'm not as critical as you
	of how well it was written.

	I've built a tool that analyzes the ANSI Smalltalk standard
	type library, so I have seen quite a lot of the document.

What do you mean by "a tool that analyzes the ANSI Smalltalk standard
type library"?  There aren't any types in ANSI Smalltalk; there are
protocols, and there are factories, and there is a way for programmers
to define classes.  Unless "type" = "protocol", there are no types.

	Even though it's not always as clear or as consistent as it
	might have been, I don't think there are many instances where,
	let's say, an implementor building a compliant implementation,
	would be lost for lack of guidance.
	
Well, I've tried to build a compliant implementation, and there are a
couple of places where it is quite impossible to do what the ANSI Smalltalk
standard says, either because it is inconsistent with itself, or because it
is inconsistent with the real world.

	> Because "x_y z" means "x := y z" in Squeak whereas it would have to
	> mean "(x_y) z" in ANSI Smalltalk, where x_y is a single identifier.
	
	x_y z would only be problematic if all three of x, y, and x_y
	were in scope, right?

Having the lexical structure of the language depend on what the programmer
has declared elsewhere doesn't make life easy for compiler writers, and it
doesn't make life easy for people trying to read the code either.  For
example, there was one language I tried to write a compatibility package for
where "x++y" normally meant "+(x,+(y))" but if there was a "++" operator
somewhere else in the program it meant "++(x,y)".  NOT nice.

Bear in mind that we have another thread going at the moment based on the
fact that lexical scoping for global and class variables has led to some
nasty surprises.

Bear also in mind that people don't write perfect code.  If I write
x_y z with the intention that it invoke x_y's z method, but the variables
I have are actually x, y, and xy (not x_y), then I'd rather be told
"x_y doesn't exist" than "sure boss, (x y) z it is".

	In view of the fact that existing Squeak code can't use
	identifiers with underscores in them, it seems to me that _all_
	existing code would still be valid if underscores in identifiers
	would be allowed from now on.

You may well be right.

But I think there is a better way.  Over in the Erlang mailing list,
they're talking about adding a "language version" property to source
files.  For example, there's a scope rule glitch (if you define a local
function with the same name as a built in and you export the function,
then external calls see the local definition but local calls see the
built-in).  If you fix that, it's technically possible that it could
break some modules.  But if a module starts with a language version
property, then the compiler can use the right rules for that version (or
indeed, the right compiler could be selected), and you could annotate the
modules that depend on the bug.

The best thing to do would seem to be to annotate change sets (or whatever,
if anything, replaces them) with the language version that was used for the
method definitions.

After all, Squeak is supposed to support multiple syntaxes, no?

	So, I maintain my position that Squeak could easily support underscores in
	identifiers.
	
	Please tell me if I missed something.
	
Your idea of "easily" is my idea of "in a confusing and error prone way,
by means of twisted code that I would prefer to not write and would refuse
to maintain."

	> No, I mean "incompatible".
	> "Change the value of x" and "Permanently define x" are quite incompatible
	> readings.  They aren't just different, they are contradictory.
	
	When you say 'incompatible', that suggests, I believe, that somehow they
	should, or could be expected to, be 'compatible'. But one is a notation for
	mathematics, the other for computer programs. Why should there be an
	expectation of compatibility?
	
Because the := sign was *copied* from mathematics, of course.
We expect the + - < and = signs to behave much the same as they do
in mathematics.  You might as well argue that "0" is a notation from
mathematics but "0" is a notation for computer programs, so "why should
there be an expectation of compatibility"?

It's just like "=" in Fortran and C.  You can say till you're blue in the
face that the programming notation is different from the mathematical one,
but beginners can't really hear what you're saying, and get very confused
by the fact that the thing that _looks_ like equality really isn't.

	Sure, assignment does have exactly that purpose. But it doesn't make y be
	the value of x, it makes *the value of y* be the value of x.

"x" stood for a variable, "y" for an expression.

By the way, in Bliss, "x = y" _did_ make the value of x be the address of y...
(Thankfully, I've forgotten enough Bliss that I can't remember how the
assignment operator was spelled; but the bugs caused by that little bit of
misplaced "simplicity" were too painful ever to forget.)