Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!hellgate.utah.edu!hamblin.byu.edu!byuvax!byuvm!cunyvm!psuvm!trl3
From: TRL3@psuvm.psu.edu (Tim Larson)
Newsgroups: comp.lang.modula2
Subject: Re: JPI M2 2.00 - PROCEDURE FUNCTIONS & ERROR CHECKING
Message-ID: <90204.213559TRL3@psuvm.psu.edu>
Date: 24 Jul 90 01:35:59 GMT
References: <1960.26A95065@puddle.fidonet.org>
Organization: Penn State University
Lines: 57

In article <1960.26A95065@puddle.fidonet.org>,
Peter.M..Perchansky@f101.n273.z1.fidonet.org (Peter M. Perchansky) says:
>    PROCEDURE function (whatever: WhateverType): ReturnType;
>    BEGIN
>    END function;
>
>    If you compile the above example (filling in whatever, WhateverType, and
>ReturnType with names/types of your chosing), you should get a compile-time
>error.
>
>    JPI M2 1.17 gave you a compile time error if you compiled a module
>containing a procedure which was defined as having a return type/value, but
>did not issue a return.
>
>    JPI M2 2.00 does not give you a compile-time error; it will give you a
>run-time error when you go to executre the said procedure.
>
>    I would like to know the following from all of you:
>
>      1)   The name of your Modula-2 compiler plus its version.
>      2)   Do you receive a compile-time or run-time error for
>           the above procedure?
>      3)   What is your preference and why?

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.

MODULE TestFuncReturn;
IMPORT IO;

PROCEDURE IllBehavedFunc(IWantToBehave: BOOLEAN): BOOLEAN;
BEGIN
IF IWantToBehave THEN
RETURN TRUE
END
END IllBehavedFunc;

BEGIN
IF IllBehavedFunc(TRUE) THEN
IO.WrStr ('Sometimes I act properly.'); IO.WrLn
END;
IF IllBehavedFunc(FALSE) THEN
IO.WrStr ('Sometimes I act up!'); IO.WrLn
END
END TestFuncReturn.

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.

Did rel. 1.17 fix this?  Or is it intractable?

Jes' Curious,
-Tim Larson
trl3@psuvm.bitnet