On Sun, 17 Nov 2013 14:19:37 +0100, "Jörg F. Wittenberger" > 1. I would believe that this ought to be ((eq? exception 'readable) ...) > Note thee missing question mark.
Whups. You're right, of course. I knew there was a reason for many eyes. :-). I keep switching between Common Lisp and Scheme on this project, so that slipped through. I've changed all the "(eq ...)" to "(eq? ...)" and pushed that to the repo. > My problem with this corner of the code is that I don't understand what > it is supposed to do. ... > 2. The exception handler will somehow catch all exceptions from > read-error, correct? Then it handles them by ignoring the error input > and some following text, still correct? Somehow the error will only > appear on the error port (which is something I'd have to handle somehow > special anyway, since when I'm running this in a server, it will only > garble my error log file. More or less. We could let the exception escape out of the read routine entirely, but since exceptions aren't even standard in R5RS, I suspect a lot of programs aren't really ready for them. So the implementation currently just whines and tries again. All syntax errors call "read-error", which sends output to (current-error-port) and raises 'readable. Procedure "t-expr-catch" uses a guard to catch 'readable; if it catches it, it calls (read-to-unindented-line port) to clean out the input, and then tail-calls t-expr-catch to try again. Only procedures read-error and t-expr-catch actually invoke exception handling, though the rest of the code is written assuming that the exceptions are handled elsewhere. If you want to handle the error information specially, I suggest temporarily changing the current-error-port. If that won't work, let us know! > But also the guard implementation itself looks suspicious to me: > > (define-syntax guard > (syntax-rules () > ((guard > (exception ((eq exception2 value) run-when-true ...)) > body) > (catch value > (lambda () body) > (lambda (key . args) run-when-true ...))))) > > > Besides that it again relies on my assumption that guile must have eq as > alias to eq?, I don't see where the identifier exception2 becomes bound. It does not. The "exception2" should match "exception" but the code doesn't check for that. Indeed, there's an implementation variance; on guile, it's really trapping all exceptions, while on everyone else it'll handle just the exception we generate. Now granted, we probably shouldn't. I was just trying to maintain the original guile semantics on guile, but move guile-specific code into the portability layer. This implementation of "guard" is intended to be used in only one situation, for the code below it. If someone wants to create a more general implementation of "guard" using guile's built-in exception system, or catch only the exception we raise/throw, I'd be glad to have it. --- David A. Wheeler ------------------------------------------------------------------------------ DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
