From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FROM_ADDR_WS
	autolearn=no autolearn_force=no version=3.4.5-pre1
Date: 15 Dec 92 20:35:58 GMT
From: news.centerline.com!noc.near.net!inmet!spock!stt@uunet.uu.net  (Tucker Ta
ft)
Subject: Re: Language pitfalls (was Re: FORTRAN bug)
Message-ID: <1992Dec15.203558.18211@inmet.camb.inmet.com>
List-Id: <comp.lang.ada>

In article <1992Dec15.180821.17817@beaver.cs.washington.edu> 
  pattis@cs.washington.edu (Richard Pattis) writes:

> . . .
>Often the base case of a recursive function to manipulate a list looks like:
>
>  IF mumble = NULL THEN
>    RETURN NULL;
>  ELSE ...
>
>What my students sometimes write is
>
>  IF mumble = NULL THEN
>    NULL;
>  ELSE ...
>
>Here the statement NULL replaces the returning of a NULL value (which might be
>better to denote as NIL, at the expense of another reserved word). . . .

Oh boy.  That is a nasty one.  This argues for a "friendly" 
Ada compiler giving a warning about any use of "null;" other
than the idiomatic ones like "when others => null;" or "begin null; end;"
(especially in a function that returns an access type ;-).

In retrospect, one could argue that it would have been better
to have no "null" statement at all (other than simply ";") than
to create a situation allowing this kind of one word error.

>Rich Pattis

S. Tucker Taft    stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138