Proposal: extension to `catch` to only catch certain exceptions

[jpco]

Looking at how catch is used, it's quite common to have something similar to

catch @ e type body {
  if {~ $e error} {
    handle-it
  } {
    throw $e $type $body
  }
} {
  commands
}

(error just being an example for illustration). This pattern shows up in the definitions for whatis and while in initial.es as well as the cdpath.es and status.es canonical extension scripts. It would also be required for an es-based definition of $&batchloop which only handles eof. It also appears in the es paper. (It shows up in my .esrc once or twice as well, and in friedman's intense setup a couple of times, for whatever that's worth).

This pattern can add a fair amount of verbosity that doesn't seem strictly necessary. Many languages' exception-handling systems can specify certain types of exception to catch, and something similar could be nice for es, so that the above becomes:

catch error @ {
  handle-it
} {
  commands
}

I am imagining you could also say catch error signal @ {handle-it} {commands} if you want one of a set of exception types. I would probably prefer to spell it catch (error signal) @ {... but that would just be for better legibility; it wouldn't special syntax.

This can be implemented in es today:

fn-catch = $&noreturn @ args {
	if {~ $#args (0 1)} {
		throw error catch 'usage: catch [exceptions] catcher body'
	}
	let (exceptions = ()) {
		$&catch @ {} {
			forever {
				if {~ $#args 2} {throw break}
				exceptions = $exceptions $args(1)
				args = $args(2 ...)
			}
		}
		$&catch @ e rest {
			if {~ $#exceptions 0 || ~ $e $exceptions} {
				$args(1) $e $rest
			} {
				throw $e $rest
			}
		} {
			$args(2)
		}
	}
}

(forever must be used because while works with exceptions, which seems to lead to infinite recursion.) The whole loop could be removed if we could reverse lists like in #82, but that's an aside. This could also all be moved into the $&catch primitive if we wanted that.

[jpco]

Another ergonomic improvement to catch would be if the catcher can be a thunk (if the catcher doesn't care what the exception is). Right now catch {} {throw true} fails because $&noreturn doesn't like to run anything except lambdas. If $&noreturn could run thunks, then catch {} {throw true} would work just fine.

[memreflect]

Your idea appears to be a restricted variant of ANSI Common Lisp's handler-case macro, so you might consider un-restricting it, e.g.

# catch ([exception-type]... handler)... body
# where handler is a thunk (no exception info available) or a lambda

That said, your implementation might not work well if retry is thrown from the body.
Below is a tweaked variant that correctly handles retry if it's not in the list of handled exceptions by throwing it outside of $&catch:

fn-catch = $&noreturn @ args {
	if {~ $#args (0 1)} {
		throw error catch 'usage: catch [exceptions] catcher body'
	}
	let (exec-handler = () ; exceptions = ()) {
		$&catch @ {} {
			forever {
				if {~ $#args 2} {throw break}
				exceptions = $exceptions $args(1)
				args = $args(2 ...)
			}
		}

		$&catch @ e rest {
			if {~ $#exceptions 0 || ~ $e $exceptions} {
				exec-handler = result <={$args(1) $e $rest}
			} {
				exec-handler = throw $e $rest
			}
		} {
			exec-handler = result <={$args(2)}
		}

		$exec-handler
	}
}

Btw, if your code is any indication, accidentally re-throwing retry exceptions caught from the body inside a catcher is a pitfall that's all too easy to fall into.
Every catcher someone writes that executes throw $e ... for unhandled exceptions from the body is susceptible, which is why i strongly dislike the idea of retry exceptions.

Thunks as catchers would definitely be a nice improvement.
As for implementing the above function in $&catch directly, i feel like handling thunks/lambdas should be a part of $&catch, but fn-catch should perform most of the heavy lifting as shown above unless you are considering making it more like CL's handler-case and testing of item types is out of the question (e.g. %closure(...){thunk} is a thunk, but it's also a closure; foo is a word (neither a thunk nor a lambda), but it might also refer to fn-foo as revealed by %whatis foo).

[jpco]

Multiple really good things to think about here, thanks.

Common Lisp's handler-case macro

That does seem even more powerful. And, nicely, in the basic cases it can be compatible with the current catch @ {} {}, as well as the catch foo @ {} {} version that covers the 99% case I care about. It doesn't allow a single catcher for multiple exception types like catch (foo bar) @ {} {}, but that's probably fine.

Incidentally, I didn't even realize this before filing it, but it turns out this whole proposal is backwards-incompatible, since

catch @ {handler} run a command with some args

is valid today, and one of these more sophisticated argument-counting setups would break that. But does anybody make use of this? It seems like a use case we can abandon.

My change doesn't handle retry right

Good find. And I hadn't thought about the idea of removing retry before, but I'm completely on board. As you point out here it's semantics are confusing and cause surprise pitfalls, it's rarely useful, it complicates the implementation of $&catch, and (I believe) the same behavior can always be done with a loop (and maybe a boolean variable) outside the catch.

Implementation

Are you imagining a catch {} {} being done via

• making $&noreturn {} and maybe even $&noreturn blah work, or
• making $&catch only call $&noreturn if the catcher is a lambda?

Also: I don't understand your "testing of item types" bit, could you rephrase it?

[memreflect]

Multiple really good things to think about here, thanks.

Common Lisp's handler-case macro

That does seem even more powerful. And, nicely, in the basic cases it can be compatible with the current catch @ {} {}, as well as the catch foo @ {} {} version that covers the 99% case I care about. It doesn't allow a single catcher for multiple exception types like catch (foo bar) @ {} {}, but that's probably fine.

Technically it supports it by saying foo is a word so it doesn't get executed while (or a b c) means any of a b c, which doesn't translate to es well.
That said, you can find something similar in SRFI 34's guard procedure in Scheme, which i failed to mention.
You can sort of convert usage of guard to es syntax as:

# guard cond-var (condition handler)... body
# note: (...) here just allows freeform organization of a regular list.
#       it is NOT required special syntax like `for` or `let`,
#       so no changes to the parser are required.
guard e (
	{~ $e(1) foo bar}                               # condition1
	{echo foo or bar thrown                         # handler1
	 echo '(not sure which since $e is unavailable)'}

	# there's more to `guard` than just matching a single exception type
	{~ $e(1) signal && ~ $e(2) sig^(int quit term)} # condition2
	{}                                              # handler2

	{~ $e(1) signal}                                # condition3
	@ _ type {echo caught unexpected signal: $type} # handler3

	# else unhandled -- re-throw exception
) {
	# body
}

Incidentally, I didn't even realize this before filing it, but it turns out this whole proposal is backwards-incompatible, since

catch @ {handler} run a command with some args

is valid today, and one of these more sophisticated argument-counting setups would break that. But does anybody make use of this? It seems like a use case we can abandon.

I've never even thought about it, but considering a standalone forever is completely uninterruptible (unlike forever {}), i feel like catch @ {handler} is potentially dangerous as well.
I don't think that case warrants the slightest bit of consideration.

Implementation

Are you imagining a catch {} {} being done via

* making `$&noreturn {}` and maybe even `$&noreturn blah` work, or

* making `$&catch` only call `$&noreturn` if the catcher is a lambda?

Only $&noreturn would be used if the catcher is a lambda.
That is, you'd use something like

Closure *c = getclosure(lp->term);
if (c->tree->kind == nLambda)
	result = prim("noreturn", mklist(lp->term, frombody), NULL, evalflags);
else
	result = eval1(lp->term, evalflags);

Any time getclosure() returns NULL, you'd have a word (an exception type) and only when getclosure() returns non-NULL would you consider it to be a catcher.

Also: I don't understand your "testing of item types" bit, could you rephrase it?

Sorry for not fully explaining the idea.
I was thinking of something like $&type '%closure(foo=bar){echo $foo}' returning a list of one or more types (e.g. (closure block)), with functions like lambdap below:

# this implementation is wrong because $&type should only accept a single string like $&cd
# since it can return multiple items already, but it illustrates the idea.
fn lambdap {~ <={$&type $*} lambda}

if {lambdap @ {echo hello}} {
	echo is a lambda	# executed because {$&type @ echo hello} returns 'lambda'
} {
	echo not a lambda
}

Another option would be an $&istype type1 type2 ... typeN arg primitive returning 0 or 1 that would work like ~ <={$&type $*} type1 type2 ..., which composes better as fn-lambdap = $&istype lambda resulting in lambdap $arg evaluating as $&istype lambda $arg.
Hook functions and such might be a good idea, but that can be discussed later.

Whichever idea you think is best, $&catch can continue executing $&noreturn $catcher $frombody if necessary.
fn-catch would be the one to determine whether to prefix $&noreturn before the handler using if {lambdap $handler} {handler = $&noreturn $handler}, followed by $&catch @ exc {$handler $exc} {$body}.

I realize this is quite a convoluted idea for a shell, so i will understand if you think that's too much abstraction for this simple problem. :)

[jpco]

Ah, interesting, being able to work with "types" like that. I'm not against it, but I think it's a more shell-wide change -- since commands in es are broadly oriented toward argument-counting, rather than argument-type-assessment, adding the ability to do the latter feels like a very "deep" change.

It also seems to me like that change would go along well with the ability to to "crack open" a thunk, lambda, or closure, such that they're no longer indivisible... but then that seems like it would be most useful with first-class environments so that we can actually use the binding part of a closure, and at that point we're really off in a new world. (Of course we wouldn't have to go "all the way" with this stuff immediately, but it's good to have an idea of what the path would look like.)

FWIW, I'm not much of a fan of that guard idea -- at that point the exception handling is at a level of sophistication where a normal catch @ e {if {~ $e ... block seems just as clear and concise.

[memreflect]

Ah, interesting, being able to work with "types" like that. I'm not against it, but I think it's a more shell-wide change -- since commands in es are broadly oriented toward argument-counting, rather than argument-type-assessment, adding the ability to do the latter feels like a very "deep" change.

It also seems to me like that change would go along well with the ability to to "crack open" a thunk, lambda, or closure, such that they're no longer indivisible... but then that seems like it would be most useful with first-class environments so that we can actually use the binding part of a closure, and at that point we're really off in a new world. (Of course we wouldn't have to go "all the way" with this stuff immediately, but it's good to have an idea of what the path would look like.)

Yes, it would definitely be a "deep" change.
In fact, i actually almost mentioned the idea of primitives like $&getbinding name and $&addbinding name value.
At that point, you'd start to wonder if es might be written entirely using primitives, including $&readline, similar to your idea of a main written in es.
Sadly, it's not nearly as simple as it sounds, and it might not even be worth all of the work that would be required.

FWIW, I'm not much of a fan of that guard idea -- at that point the exception handling is at a level of sophistication where a normal catch @ e {if {~ $e ... block seems just as clear and concise.

It's indeed a bit on the convoluted side.
I only wanted to mention it because it's possible to implement a rudimentary version in es already using $&catch, and it's simple to understand the basic idea.