Am 17.11.2013 14:52, schrieb David A. Wheeler: > 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!
I'd rather catch the exceptions elsewhere. (Which I do already. Such parser errors would result in a 500 something HTTP reply. Simply ignoring at the error port would be hard. I'd have to add yet another exception handler and after each request I'd have to check whether the error-port has anything and then generate an error reply. A lot of overhead just because of yet another parser. And if I was to simply ignore the error, then the code would continue. Given the (planned) context, where the code will produce a (possibly modified) copy of itself under circumstances, this could result in parts of the code simply missing. Too bad. > >> 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. Ah, I see. Now. ------------------------------------------------------------------------------ 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
