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 at instantiations.com
>
>
>