By what process would this change be implemented? Have the vm raise an error
dialog every time it encounters an underscore? Then in a year or two switch
on the allow underscores in variable names flag? I mean, this sort of change
doesn't happen over nite, right?

Gary Dunn
Open Slate Project
http://openslate.org

On May 13, 2011 6:11 PM, "Jerome Peace" <peace_the_dreamer at yahoo.com> wrote:

Hi all,

Squeak has a lot of problems leaving its past behind.

It has a lot of problems creating a future for itself.

As a bug tracker certain things set of my alarms. If you want to test code
you need to recognize that each preference doubles the number of tests.
Assignments are fundamental to any language. To have two forms of
assignments and the preferences to determine when each is used and shown
doubles the (theoretical) work of proving the code correct.

Underscores are ascii. Backarrows are Utf-8. The use of backarrows glyphs in
character sets where underscores glyphs should be harks back to a character
set that predates ascii and would have no modern description.

In practice having the two forms available means that underscores will
always creep in to code depositories. The effort to eliminate them so that
underscores can be used as characters in variables will continue to fail.

a_b_c_d := airplane .

Will forever mean two different things and be very dangerous code to write.
One form of assignment will suffice and help secure a future for squeak and
smalltalk.

Two forms will forever be a contentious issue. The point of having a
language is exchanging thoughts with others. Squeak needs to be compliant
with smalltalks that consider a_b_c_d a word not four.

Cuis is a very good effort. Juan will stubbornly stick to what comforts him.
Squeak belongs to more than Juan. It needs to reach the future. This
nostalgia about assignments prevents it progress.

I don't write this list often these days. Strong feeling about this
stumbling block prompts this outburst. Deprecate the use of underscore for
assignment. Guide squeak to its future by letting it let go of this portion
of its past.

Yours in curiosity and service, --Jerome Peace
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110513/de991367/attachment.htm