(j3.2006) Another late-in-the-day question

[Malcolm Cohen]

Van Snyder wrote:
> It's late in the process to ask such a question as this one.
>
> We extended the <stop-code> to allow scalar constant integer expressions
> and scalar constant character expressions.
>
> Why constant?
>   
So that STOP is always safe.
> It seems we could remove "<constant->" thrice at [187:7-9], and add
> "shall be defined and" before "is made available" at [187:12], without
> causing any trauma either to the standard or a processor.
>
>   
I think that's true enough, but once users get into the habit of writing

   STOP 
translate_message_into_greek(lookup_error_code(diagnose_io_error(find_unit_for_file(filename))))

instead of

   STOP 'Unexpected message sending error'

when the i/o system is borked, the world has not been improved because 
the "nice" version is just going to crash out horribly or recurse 
infinitely with various STOPs trying to diagnose and translate errors.

Another example is where the memory allocator gets broken (perhaps the 
user has scribbled all over its internal data structures); the last 
thing you want to encourage is for the user to call stuff that might 
allocate memory while executing a panicky STOP statement.

So, my feeling is that your suggestion
(a) is no problem for the standard,
(b) is no problem for the implementor,
(c) but provides little useful functionality (see below),
(d) and encourages bad practice.

If the user really wants to do stuff he can just do
   CALL MYSTOP(...)
which will do various horrible things, including writing to 
ERROR_OUTPUT, then doing a vanilla STOP.  I think it is clearer that 
"CALL MYSTOP" is not suitable for a panic stop (than the suggested 
extension which makes STOP potentially not suitable for a panic stop).

That wouldn't make me vote against it, but I wouldn't bother pursuing it 
either.

Cheers,
-- 
...........................Malcolm Cohen, Nihon NAG, Tokyo.