Doug Way wrote:
>
>The numbers notation was a major concession, but an essential one.
>The language remained impractical without it (although one could
>conceive of surviving if truly forced to write (1 plus: 2) times: 3).
Well, try COBOL for a change ;-). They really do that, like

SUBTRACT A FROM B INTO C.   ( c := b - c ).

>Perhaps no change should be made unless it met that hefty criteria:
>Unless the new notation adds a meaningful functionality not present
>beforehand, or unless the new notation is necessary to  make the
>language practical, perhaps no changes should be made to the
>fundamental elemental syntax.
So far, I have not seen a convincing argument to do something with dot
notation. As fas as I am concerned any identifier is a reference to an
object, i.e. a key in the system dictionary. E.g.:

Smalltalk at: 'SomePackage.SomeClass' asSymbol

is no different from this:

Smalltalk at: 'SomeClass' asSymbol.

I.e. I see no reason (other than performance or the wish to subdivide the
system dictionary in more than one dictionary) to give special meaning to
keys in the system dictionary containing dots. It's just the way we want to
tell the compiler to recognize something at compile-time! I'm an advocate of
the run-time solution:

someClass := 'SomePackage.SomeClass' asClass.

>
>I raise this more to test the idea than to advocate it.  It just
>seems to me that noone has really said the obvious truth: special
>notation for arithmetic is almost sui generis, and probably necessary
>to keep the underlying language from failing the giggle test.  Can
>the same be said for "@" and [.] for indexing, or "." for selection?
I agree. And let's keep in mind that Smalltalk was invented to teach
non-techies how to tell the computer what they want it to do. I can't
imagine teaching a 12-year old the proposed extensions.


Regards, Reinier.