[Oberon] Multiple RETURN in a procedure

thutt at harp-project.com thutt at harp-project.com
Mon Oct 24 06:13:15 CEST 2022


Chris Burrows writes:
 >    On Mon, Oct 24, 2022 at 2:03 AM <[1]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;
 >        BEGIN
 >          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;
 >      VAR r: INTEGER;
 >      BEGIN
 >        r := 0;
 >        WHILE ptr # NIL DO
 >          INC(r);
 >          ptr := ptr.next;
 >        END
 >        RETURN r
 >      END ListLength;
 >    Regards,
 >    Chris Burrows
 >    CFB Software
 >    [2]https://www.astrobe.com

Hey, no fair!  You fixed the deliberate issue I created with the check
for NIL with the expectation of a single return.  If there is no way
to return from the middle of a function, I suppose it forces people to
think about code flow thorugh the whole function and to write code
that won't suffer from faults like my versino would have.


 > 
 > References
 > 
 >    1. mailto:thutt at harp-project.com
 >    2. https://www.astrobe.com/

-- 
C, the speed of light, is not just a good idea, it's the law.




More information about the Oberon mailing list