Nevin Pratt wrote:
> 
> Stephan Rudlof wrote:
> 
> 
>> 
>>
>>In other words: I don't like to change to non ANSI behavior to satisfy
>>applications thought to be portable.
>>
> 
> 

> Except that we wouldn't be changing anything to non-ANSI behavior. 
>  After all, the behavior is currently *undefined* in the ANSI standard, 
> therefore any behavior satisfies ANSI

This is correct.
It had better been
  'I don't like to change to some behavior undefined by ANSI to satisfy
applications thought to be portable.'

> 
> 
>>Moreover: changing to non ANSI behavior could *break* other apps, which
>>*are* portable already!
>>
>> 
>>
> 
> 

> If it broke other apps, then *they* would be relying on a particular 
> behavior that is currently ANSI-undefined, and the same argument could 
> be used to argue that *they* should be changed (so they don't rely on 
> that behavior).

Agreed, too.
Here I've been too sloppy, too, because...

> 
> As far as changing the ANSI standard, all we would do here is define 
> what is currently undefined.

this is my point: I don't like to define something, which is defined as
'undefined' by the standard. This opens a trap for programmers to rely on
'undefined' behavior for apps meant as portable (which actually has happened
for Glorp). If afterwards this 'undefined' behavior is changed, they could
be broken (do you know if there isn't any Squeak app (admittedly non ANSI)
expecting the current 'undefined' exception behavior, which you would break
with the change?).

> Also, in the absence of a definition 
> (whether in this area or any other area of the ANSI standard), the only 
> thing anybody really *can* do is to try to look for a defacto standard.

No. Just raise an Exception (allowed) to feedback the problem to the
programmer. Then he is able to avoid this trap.
Otherwise
- you always have to compare multiple Smalltalks if you are faced with such
a problem;
- have to notice the problem first (how, if it silently works for just your
implementation ST?).

These are the reasons why there is a standard, I think.

>  And, since all the commercial Smalltalk implementations seem to have 
> the same behavior here, that sounds like a pretty convincing defacto 
> standard to me.

Assumed you try to develop something portable in Squeak, which should be the
main perspective for us, I think. Then you would encounter an Exception,
would avoid it and it would be portable for *all* ANSI compatible Smalltalks.

Isn't it good?

> 
> So, I remain unconvinced that Squeak being different from the other 
> Smalltalks in this regard isn't just a gratuitous difference for no real 
> gain.

You may be right in just this case at this time (I don't know and Smalltalk
systems tend to evolve).
But as a general rule I'm for Exceptions in case of ANSI undefined behavior
for core classes. Otherwise it becomes harder for people trying to implement
portably.

> 
> But I appreciate your effort to convince me :-)

You're welcome, thanks for reading my comments ;-)


Hopefully I've avoided errors and made my intents more clear now.


Greetings,

Stephan

> 
> Nevin
> 
> 
> 
> 


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3