I think it's even a bit stronger than "to allow implementations to provide features...". On a number of occasions, we made things "undefined" to *encourage* implementations so that, we hoped, this would lead us (and our descendants) to extend the Standard by codifying then-existing practice.

So not only would it not be counter to the Standard for Squeak to take a position on negative bit operations (apologies for the tripple negative), but it might be in the best interest of long-term Smalltalk standardization for Squeak to do so.

glenn

At 08:49 AM 4/23/98 -0700, Allen Wirfs-Brock wrote:

At 10:23 PM 4/22/98 -0700, Dan Ingalls wrote: ...

...

I'm still mildly opposed to bit manipulation on negative numbers, mainly for simplicity, although ANSI compliance is a weak second reason.

ANSI Smaltalk doesn't forbid bit manipulations on negative numbers, it says that the result of such an operation is undefined.

In this context "undefined" means: "If a feature is denoted undefined a conforming implementation may accept a program using the feature, but must document that it does so. A conforming implementation is not required to accept an undefined feature. A program that is dependent upon the use of an undefined feature does not conform to the standard." (section 2 page 7)

"undefined" is a very important concept within the standard. It is one of the main hooks used to allow implementations to provide features that go beyond what is in the standard.

Allen_Wirfs-Brock@instantiations.com