[Oberon] Multiple RETURN in a procedure

Chris Burrows cfbsoftware at gmail.com
Mon Oct 24 00:03:15 CEST 2022

On Mon, Oct 24, 2022 at 2:03 AM <thutt at harp-project.com> wrote:

> The original ETHZ compiler didn't check if you included a return
> statement.  It actually did something that I find to be really nice --
> something that would be handy for others to adopt:
>    If you did not have a return statement that was executed in a
>    procedure returning a value, a trap was raised.
Better than nothing I suppose, but it is always preferable, if possible,
for errors to be detected at compile-time rather than runtime.

>  I am not a fan of the single return, though it would probably be
>  beneficial for the GSA IR and code generation.   The return causes an
>  immediate return from the function, but the assignment to the
>  procedure name means that the control flow will continue through the
>  function.  For many non-trivial functions, with a naive compiler,
>  this will lead to unnecessary code being executed, and perhaps faults
>  being raised.
>  Consider:
>   PROCEDURE ListLength(ptr : List) : INTEGER
>   VAR r : INTEGER;
>     IF ptr = NIL THEN
>        RETURN 0;
>     END;
>     r := 0
>     WHILE ptr # NIL DO
>        INC(r);
>        ptr := ptr.next;
>     END
>     ListLength := r;
>     RETURN ListLength;
>   END ListLength;

I'm not that familiar with Oberon-07, so maybe there's some nuance I'm
> missing?

In Oberon-07 this would simply be:

  PROCEDURE ListLength(ptr : List) : INTEGER;
    r := 0;
    WHILE ptr # NIL DO
      ptr := ptr.next;
    RETURN r
  END ListLength;

Chris Burrows
CFB Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20221024/06bb4182/attachment.html>

More information about the Oberon mailing list