🚀 go-pugleaf

dhinds@portia.Stanford.EDU (David Hinds) writes:

>In article <90204.213559TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes:
>>In article <1960.26A95065@puddle.fidonet.org>,
[..]
>>
>    I would be very surprised to see a compiler that flagged the above
>routine as an error.  I don't think that leaving the possibility of
[..]

Quite right, a warning is perhaps appropriate.

>the problem is insurmountable. A compiler could require that all execution
>paths end in RETURN statements, but that is still a non-trivial extension
>to the language syntax.

As well as a VERY pointless one, isn't the general case the
Halting Problem ?? 

Anyway, in a lot of code the programmer *knows* that a RETURN will be 
encountered. Even if checks are done manually, that may not result
in a RETURN, e.g.

PROCEDURE FunnyStuff(arg1 : INTEGER) : BOOLEAN;
BEGIN
  IF arg1 < 126 THEN			(* Cath errors.			*)
    InOut.WriteString("ERROR : plane just crashed, tough luck. Bye");
    InOut.WriteLn;
    HALT
  END;
  CASE arg1 OF				(* So this is stupid, so what ? *)
    127 : RETURN TRUE
  | 128 : RETURN FALSE
  END;
END FunnyStuff;

Even if M-2 *does* provoke the programmer to reflect on the programming,
there is no reason for a straight-jacket requirement of a RETURN statement 
that's always reached.. .

	Jens
Jens Tingleff MSc EE, Institute of Computer Science, Copenhagen University
Snail mail: DIKU Universitetsparken 1 DK2100 KBH O
"It never runs around here; it just comes crashing down"
	apologies to  Dire Straits