Re: [Readable-discuss] using t-expressions
Am 27.11.2013 02:22, schrieb David A. Wheeler: On Tue, 26 Nov 2013 15:11:39 +0100, Jörg F. Wittenberger wrote: I changed it's signature to match srfi-23 (for know) (: read-error (string rest * - *) Okay, but you'll need to modify the procedure definition to match. Sure. I just did not want to clutter the list with some imature, temporary code. But I tend to prefer a more restrictive, though compatible, syntax in this case (: read-error (string input-port string rest * - *) Please don't. The intent was to be syntactically consistent with error as defined in srfi-23 and R7RS. Someone can always modify the error port to change where it goes. Oh, I presume you mean output-port not input-port there. No, I meant input-port - or rather the fake input port we're reading from. Iff the latter supports getting the position or something, the read-error could report them too. For the moment I just used peek-char to show the problematic character. This signature is compatible with srfi-23 error. It's just a little more specific and should probably itself rely on plain error in the implementation. Whereby I'd require all calls to read-error to pass the port and the last successfully read token in an effort to further improve error messages. Why not just pass last successfully read token as a parameter after the string? That was the intent behind the string after the (fake) input-port. The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) Is there actually any scheme implementation which benefits from this catching? I can't image. Our processing program does, because it tries to process as well as it can. But we could change the interface. I'd feel it might be good to provide a clean up read like `read-to-unindented-line` to help the implementor of a repl. But for the default it just does not feel right to me. Okay. An easy approach would be to raise an exception on error, and add an option to permit the current behavior (catch and retry). That's an interface change, but the SRFI doesn't define specifics on how to handle errors (since Schemes vary in this matter), and it makes sense that people will want to get errors. Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be implemented separately on guile. This one does not look to bad to me: https://www.gnu.org/software/guile/docs/docs-1.8/guile-ref/Error-Reporting.html#Error-Reporting /Jörg -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
Am 25.11.2013 15:14, schrieb David A. Wheeler: On Mon, 25 Nov 2013 12:24:23 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Hi all, I'm just making my first experiences in actually using srfi-110. At this point I find myself forced to make serious changes to the program logic. Beyond what's supported by simply configuring the source code. The worst thing I found that it will complain on the error port when reading badly formatted code and then continue to read. I really, really need it to do what other Scheme readers usually do: error out. Easily done, and there are many ways to do it. The ONLY procedure that throws an exception is read-error: (define (read-error message) I changed it's signature to match srfi-23 (for know) (: read-error (string rest * - *) This allows me to do as better job at error reporting. But I tend to prefer a more restrictive, though compatible, syntax in this case (: read-error (string input-port string rest * - *) Whereby I'd require all calls to read-error to pass the port and the last successfully read token in an effort to further improve error messages. But I'm unsure about this. Any comments? (display Error: (current-error-port)) (display message (current-error-port)) (newline (current-error-port)) (flush-output-port (current-error-port)) (raise 'readable) '()) The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) Is there actually any scheme implementation which benefits from this catching? I can't image. I'd feel it might be good to provide a clean up read like `read-to-unindented-line` to help the implementor of a repl. But for the default it just does not feel right to me. /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
I said: The ONLY procedure that throws an exception is read-error: (define (read-error message) On Tue, 26 Nov 2013 15:11:39 +0100, Jörg F. Wittenberger wrote: I changed it's signature to match srfi-23 (for know) (: read-error (string rest * - *) Okay, but you'll need to modify the procedure definition to match. But I tend to prefer a more restrictive, though compatible, syntax in this case (: read-error (string input-port string rest * - *) Please don't. The intent was to be syntactically consistent with error as defined in srfi-23 and R7RS. Someone can always modify the error port to change where it goes. Oh, I presume you mean output-port not input-port there. Whereby I'd require all calls to read-error to pass the port and the last successfully read token in an effort to further improve error messages. Why not just pass last successfully read token as a parameter after the string? The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) Is there actually any scheme implementation which benefits from this catching? I can't image. Our processing program does, because it tries to process as well as it can. But we could change the interface. I'd feel it might be good to provide a clean up read like `read-to-unindented-line` to help the implementor of a repl. But for the default it just does not feel right to me. Okay. An easy approach would be to raise an exception on error, and add an option to permit the current behavior (catch and retry). That's an interface change, but the SRFI doesn't define specifics on how to handle errors (since Schemes vary in this matter), and it makes sense that people will want to get errors. Guile 1.8 doesn't support srfi-23 or R7RS, so that would need to be implemented separately on guile. --- David A. Wheeler -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] using t-expressions
Hi all, I'm just making my first experiences in actually using srfi-110. At this point I find myself forced to make serious changes to the program logic. Beyond what's supported by simply configuring the source code. The worst thing I found that it will complain on the error port when reading badly formatted code and then continue to read. I really, really need it to do what other Scheme readers usually do: error out. The surrounding Scheme system ought to know what to do with errors. Those Scheme systems I know do all catch the error and print it out on the error port - by default. This is usually done in the repl and allows applications to catch the error for app specific handling. For instance: my application evaluates the code within a sandbox from a web server. Message at the error port are in this context only for errors in the implementation and end up in the error log file. What's even worse: simply complaining and the *continue to read* as if nothing had happened results in strange, stupid and wrong messages from the interpreter caught later. Example: an error in (define x ..) ends up and x unbound. Quite irritating. Should this become yet another config option for the code, or should we simply resort to the more standard behavior and error out via srfi-26 compatible code? Best Regards /Jörg -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] using t-expressions
On Mon, 25 Nov 2013 12:24:23 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Hi all, I'm just making my first experiences in actually using srfi-110. At this point I find myself forced to make serious changes to the program logic. Beyond what's supported by simply configuring the source code. The worst thing I found that it will complain on the error port when reading badly formatted code and then continue to read. I really, really need it to do what other Scheme readers usually do: error out. Easily done, and there are many ways to do it. The ONLY procedure that throws an exception is read-error: (define (read-error message) (display Error: (current-error-port)) (display message (current-error-port)) (newline (current-error-port)) (flush-output-port (current-error-port)) (raise 'readable) '()) The ONLY procedure that catches an exception is t-expr-catch: (define (t-expr-catch port) (init-sweet) (guard (exception ((eq? exception 'readable) (read-to-unindented-line port) (t-expr-catch port))) (t-expr port))) What's even worse: simply complaining and the *continue to read* as if nothing had happened results in strange, stupid and wrong messages from the interpreter caught later. Example: an error in (define x ..) ends up and x unbound. Quite irritating. Well, it actually consumes text until it hits a blank line. Should this become yet another config option for the code, or should we simply resort to the more standard behavior and error out via srfi-26 compatible code? This could even be a run-time configuration option. Does anyone have a preference? --- David A. Wheeler -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
