<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Aubrey<div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr">How difficult would it be to put such a strategy into a OldSource --> NewSourcee compiler?</div><div dir="ltr"><br></div></div></blockquote></div><div>If a RETURN statement only influenced the return value, your automatic replacement method would indeed work.</div><div>Unfortunately, the previous RETURN statement is a (hidden) GOTO and hence influenced the control flow drastically.</div><div><br></div><div>FOR i := 1 T0 100 DO </div><div> a[i] := i ;</div><div> IF i > 33 THEN RETURN -1 END</div><div>END;</div><div>RETURN 22</div><div><br></div><div>A non-sensical but valid program. Looking only at the returned value, your „auxilary variable“ automatism would work, but the new code would modify a[35] to a[100]. The old code did not.</div><div><br><div dir="ltr">br<br><div>Jörg</div></div><div dir="ltr"><br><blockquote type="cite">Am 24.10.2022 um 00:52 schrieb Aubrey McIntosh <aubrey.mcintosh@utexas.edu>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><div>I think that Wirth's example cited by Denisof would be easier to comprehend if an aux variable were introduced. I applied this to the min function being discussed as follows:</div><div style="margin-left:40px"> PROCEDURE minTrans (x,y: INTEGER) : INTEGER;<br></div><div style="margin-left:40px"> (*41 bytes*)<br></div><div style="margin-left:40px"> VAR aux: INTEGER;<br> BEGIN IF x < y THEN aux := (x) ELSE aux := (y) END;<br> RETURN aux<br> END minTrans;</div><div style="margin-left:40px"><br></div>More formally, I substituted "aux :=" everyplace "RETURN" existed in the original snippet, and I placed the "RETURN aux" immediately before the Function termination.<br><br></div><div>How difficult would it be to put such a strategy into a OldSource --> NewSourcee compiler?<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 23, 2022 at 5:03 PM Chris Burrows <<a href="mailto:cfbsoftware@gmail.com">cfbsoftware@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Oct 24, 2022 at 2:03 AM <<a href="mailto:thutt@harp-project.com" target="_blank">thutt@harp-project.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The original ETHZ compiler didn't check if you included a return<br>
statement. It actually did something that I find to be really nice --<br>
something that would be handy for others to adopt:<br>
<br>
If you did not have a return statement that was executed in a<br>
procedure returning a value, a trap was raised.<br><br></blockquote><div> </div><div>Better than nothing I suppose, but it is always preferable, if possible, for errors to be detected at compile-time rather than runtime.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I am not a fan of the single return, though it would probably be<br>
beneficial for the GSA IR and code generation. The return causes an<br>
immediate return from the function, but the assignment to the<br>
procedure name means that the control flow will continue through the<br>
function. For many non-trivial functions, with a naive compiler,<br>
this will lead to unnecessary code being executed, and perhaps faults<br>
being raised.<br>
<br>
Consider:<br>
<br>
PROCEDURE ListLength(ptr : List) : INTEGER<br>
VAR r : INTEGER;<br>
BEGIN<br>
IF ptr = NIL THEN<br>
RETURN 0;<br>
END;<br>
r := 0<br>
WHILE ptr # NIL DO<br>
INC(r);<br>
ptr := ptr.next;<br>
END<br>
ListLength := r;<br>
RETURN ListLength;<br>
END ListLength; </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I'm not that familiar with Oberon-07, so maybe there's some nuance I'm missing?<br></blockquote><div> </div><div>In Oberon-07 this would simply be:<br></div><div><br></div><div><font face="monospace"> PROCEDURE ListLength(ptr : List) : INTEGER;<br> VAR r: INTEGER;<br> BEGIN<br> r := 0;<br> WHILE ptr # NIL DO<br> INC(r);<br> ptr := ptr.next;<br> END<br> RETURN r<br> END ListLength;</font><br></div><div><font face="monospace"><br></font></div><div><font face="arial, sans-serif">Regards,</font></div><div><font face="arial, sans-serif">Chris Burrows</font></div><div><font face="arial, sans-serif">CFB Software</font></div><div><font face="arial, sans-serif"><a href="https://www.astrobe.com" target="_blank">https://www.astrobe.com</a></font></div><div><font face="monospace"><br></font></div><div> </div></div></div>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Aubrey McIntosh, PhD</div><div dir="ltr"><br></div></div></div></div></div></div></div></div></div></div>
<span>--</span><br><span>Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems</span><br><span>https://lists.inf.ethz.ch/mailman/listinfo/oberon</span><br></div></blockquote></div></body></html>