Re: Introspection Marc Nieper-WiÃkirchen 11 Jun 2020 11:55 UTC
Am Mi., 10. Juni 2020 um 23:46 Uhr schrieb John Cowan <email@example.com>: > > I don't see that there's much difference between the protocol conversions lisp->, values->, lisp-values->, and exception->; they should have systematic names. I prefer them to be procedures rather than a mixture of procedures and syntax, and I think the extended -> convention is perfectly fine once it is explained. The particular choices of name components I admit are not very good, and if anyone has different ones, I'll absolutely consider them. As you know, I have some issues with the "values->..." naming as I have already said. Moreover, a systematic name doesn't help that much here because the first argument to the "values->" procedures is very different, namely a producer. I think that should be reflected by the name. And because it means that "values->" isn't the (lossy) inverse in the simplest sense. I have to admit, though, that I currently have no good name in mind, which would match "call-with-values" in the report, which also takes a producer procedure. While my issue with "values->" is a minor one, the naming of "exception->either" is a major one IMHO. As "exception->either" is more of a converse to "either-ref", I wouldn't even put it in the "Conversion" section as it really different from all the other procedures there. And when one puts it into another section for clarity, say "Exceptions", it wouldn't look like a strange mixture between procedures and syntax, and, moreover, we are free to choose a better name. Why don't you like "either-guard"? > The problem with using guard to implement exception->either or anything like it is that it breaks if something inside the thunk/body does a raise-continuable which is to be intercepted by a handler that catches it and returns values to the caller. A guard expression's default action in the absence of an else-clause will change that to a raise instead, which means there is no way back (an attempt to return from the handler will just raise another exception). Using an else-clause is even worse, because then the call/cc makes it outright impossible to return. That's a very good point. So what about the following? (define-syntax either-guard (syntax-rules () ((either-guard pred? . body) (guard (exc ((pred? exc) (left exc)) (else (raise-continuable exc))) (call-with-values (lambda () . body) right))))) In the default case, this will reraise `exc` for the exception handler of the `either-guard` expression. If this exception is caught by that exception handler and this exception handler returns, by definition of `raise-continuable`, the control flow will be back in the `else` clause of the guard, which will then return. Another error will be raised in case the original exception wasn't continuable, otherwise, the control flow will jump to where the continuable exception has been originally raised.