Re: Software landmines (was: Why C++ is successful)

[stt@houdini.camb.inmet.com (Tucker Taft)]

adam@irvine.com wrote:
: ...
: Anyway, here's my main question:  Is it desirable to expand the syntax of
: "exit" to cover cases like this?  I think it might be nice.  I'm thinking that
: code like this could look something like:

:     block_to_do_stuff:
:     begin
:         blah-blah-blah;
:         exit block_to_do_stuff when error-condition-1;
:         keep-going;
:         exit block_to_do_stuff when error-condition-2;
:         still-keep-going;
:         exit block_to_do_stuff when error-condition-3;
:         everythings-still-fine-keep-going;
:         etc.
:     end block_to_do_stuff;

: I think one of the Ada 9X proposals actually had a feature like this, but
: unfortunately it also changed the semantics of "exit" in a way that would
: change the meanings of a lot of Ada 83 code.  Probably, that's why it was
: dropped from the final Ada 95 definition.  

The Ada 9x proposal was "upward consistent" in that it didn't change the 
meaning of any existing programs to a new legal meaning, but it did make 
some of them illegal (those that involved exits from blocks nested in loops,
I believe).

: ... But I think that the exit-block
: feature in my example would be a very useful addition to the next version
: of Ada.  (I'd define it so that this use of "exit" requires a block name,
: so that the semantics of "unnamed" exit statements are unchanged; that way,
: there wouldn't be any upward compatibility problems.)

We also considered this proposal.  Basically, we couldn't find a
"clean" solution that looked like it wasn't just an add-on rather
than something built in from the beginning.  Also, the problem being
solved is relatively minor, and we had bigger fish to fry (mix those
metaphors liberally, please).

: So do the rest of you think it's a useful enough feature to consider adding
: to Ada?

If there were a solution that treated loops and blocks symmetrically,
that would be nice.  But a proposal that only allows exiting from
unnamed loops, while disallowing exiting from unnamed blocks, is
a kludge.  I would prefer something which allowed an unnamed "exit" to be
legal only if there were exactly one block or loop enclosing the point.
If there were more than one, then the exit would have to be named.
This way, adding another level of block or loop to an existing program with
an unnamed exit would never result in an exit going to the wrong place,
but it might result in the program becoming illegal.  This avoids a kind
of "Beaujolais" effect for unnamed exit statements (the "Beaujolais" 
effect is a case where adding or removing a declaration from a "used"
package would change the meaning of a program from one legal interpretation
to another -- Ada 95 doesn't have them, Ada 83 had very few (all obscure),
"used" C++ namespaces have them for sure).

The general Ada principle is to require that the programmer write more
if that will help to make the meaning clear to the reader.  (Note that
sometimes writing *less* makes things clearer to the reader.
The key is to keep the signal to noise ratio high.)  

Unnamed exits should be limited to cases where there is no ambiguity, 
especially if they can exit multiple kinds of constructs.  The C situation is
bad news, where a "break" is used to exit both switch and loop,
and there is no "named" version of it.  I have seen plenty of bugs
where a break was meant to exit a loop, but really only exited the
nearest enclosing switch, or vice-versa.

: 				-- Adam

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA
An AverStar Company