Open dragoncoder047 opened 1 year ago
I would say that the goal is to adhere to Common Lisp to the extent that uLisp programs should give the same result when run on Common Lisp, but I think it's acceptable for error handling to be different. uLisp doesn't have any concept of named blocks using tagbody and go, so I'm not sure I could detect that invalid (return).
I'm not sure I could detect that invalid
(return)
.
If you want to fix it, I think that the place to do the check would be inside where lambdas get executed (in eval) and bail if RETURNFLAG is set when the progn returns.
Also, while I am less hesitant to try to implement tagbody
and go
in uLisp (because it's basically goto), it probably would have the same approach as how I implemented throw
and catch
(which are also basically goto's but simpler).
Another idea: block
and return-from
are pretty much semantically equivalent to catch
and throw
, except that catch
/throw
evaluate the "tag" argument (so it must be quoted or a keyword) and block
/return-from
don't (so you can't supply the tag in a variable)
The other two things about block
/return-from
(loop
opens a block named nil
, apparently, and blocks are not preserved across call stack entries when defun
's are called) I think could be implemented using a similar technique, with a global variable called ReturningFrom
or something, and check that when returning from blocks, and in the lambda implicit progn in eval()
.
uLisp just stops, no error.
If the goal is to adhere to Common Lisp, this should be fixed. But I frankly like this behavior, because it allows you to define your own "exit" functions that can make decisions, do custom cleanup, etc. and then exit the loop even if it is farther up the call stack.