Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!decwrl!shelby!portia.stanford.edu!dhinds
From: dhinds@portia.Stanford.EDU (David Hinds)
Newsgroups: comp.lang.modula2
Subject: Re: JPI M2 2.00 - PROCEDURE FUNCTIONS & ERROR CHECKING
Message-ID: <1990Jul24.060519.23417@portia.Stanford.EDU>
Date: 24 Jul 90 06:05:19 GMT
References: <1960.26A95065@puddle.fidonet.org> <90204.213559TRL3@psuvm.psu.edu>
Organization: AIR, Stanford University
Lines: 35

In article <90204.213559TRL3@psuvm.psu.edu> TRL3@psuvm.psu.edu (Tim Larson) writes:
>In article <1960.26A95065@puddle.fidonet.org>,
>
>I have JPI M2 v1 rel. 1.14 (never got 1.17 and haven't opened v2 yet).  I
>got a little curious about this and wrote the following silly example.
>>...
>PROCEDURE IllBehavedFunc(IWantToBehave: BOOLEAN): BOOLEAN;
>BEGIN
>IF IWantToBehave THEN
>RETURN TRUE
>END
>END IllBehavedFunc;
>...
>This example gives no compile-time error, but does generate a run-time
>error.  I would prefer compile-time errors myself, but if the compiler
>cannot catch an error as simple as the above (much less the worse ones
>that could be committed), then the run-time error seems to be the only
>recourse.
>
    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
reaching the end of a procedure without a RETURN statement violates the
syntax of M2 - am I wrong?  If I'm right, then there is no way for the
compiler, in the general case, to determine if the illegal exit might
ever be executed.  Sure, it could test for some trivial cases like the
one in the example, but it seems pointless.  The runtime trap can catch
infinitely more cases of illegal exits than the compiler ever could.  I
guess the compiler could easily enough make sure that a procedure has
at least one RETURN statement that could be reached, but beyond that,
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.

 -David Hinds
  dhinds@popserver.stanford.edu