Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
>(loop for i from 1 to 10 finally return i)
>The code above "looks reasonable" (to whom?) and "works as
>expected" (by whom?)
I remember myself writing such code.
Maybe CLtL2 was different?
Maybe return in finally is a left-over from the MIT-loop implementation which was widely used some years ago.
I preferred using return in finally instead of (return #) because the former seems like a loop-specific keyword/clause while the latter is the throw-out of the BLOCK construct, which has little to do with loop per se (except that LOOP implicitly creates a block).
Reading CLHS now I realize that RETURN as a LOOP special has no place in FINALLY.
Ok, I dug up CLtLII:
o "The finally construct [...]. An unconditional clause can also follow the loop keyword finally."
o The return construct [...]"
In other words, here you are deliberately throwing out CLtLII out of CLISP. I agree that CLtL1 is history, though.
Is it worth being incompatible with CLtLII like this?
>The code which relies on the current behavior is non-portable an
in ANSI at least.
There seems to be a specific finally return ANSI issue #223:
"14. Moon #26 -- Eliminate the ability to put a LOOP keyword after FINALLY"
>This proposal is follows the CLISP tradition of strict compliance and
>signaling errors in all questionable areas.
There's also some tradition for blindly applying by the letter some debatable/unclear parts of ANSI. :-)
>Unless there is a strong feeling to the contrary,
>I will check in this patch.
Go for it, at least in ANSI mode.
I'm pretty sure some (esp. old) code will break, so it now can be improved.