[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] Reorganize to reduce namespace pollution and maximally create library
John Cowan: Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries can't be the result of a macro, neither as a whole nor in part. All you've done is trade off one set of portability breakers for another. Ugh. In that case, maybe we should just drop the readable-kernel-module-contents macro altogether, and just write straight code with weird names to reduce possible namespace problems. We can include cond-expand guile magic so that it works as-is as a guile module. Alan: Any objections? John: I take it that prefixed % is a universally-portable indicator we can use for internal names? Adapting it to X Scheme's notion of a module should be left to X Scheme experts. The notion that you have to be an X Scheme expert to merely define or use a module is absurdly broken. Here's to hoping that R7RS library module notation gets universally implemented, and quickly, so that such nonsense can go to the dustbin of history. This is what I've been doing with my SRFI implementations: plain code, plus a shim file to add stuff from R7RS-small that I need, plus modules for Chicken (R5RS-plus) and Chibi (R7RS), both of which fortunately support include. Yes, it's more complex to use than one all-singing-all-dancing file. But it's much easier to port, even if it does less of the work for you. How about cond-expands at the beginning to handle much of the shimming, followed by clean code, and separate files to create modules and include them? That should be fairly widely available (I hope!). --- 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
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
Re: [Readable-discuss] Reorganize to reduce namespace pollution and maximally create library
David A. Wheeler scripsit: How about cond-expands at the beginning to handle much of the shimming, On Mon, 25 Nov 2013 12:08:47 -0500, John Cowan co...@mercury.ccil.org wrote: As of the last time I looked, cond-expand wasn't supported by Racket, Scheme48/scsh, Larceny, Ypsilon, S7, or Sizzle. It just gets worser and worser. Putting the text in *different* files and leaving them there *also* appears to be non-portable: * R5RS load doesn't guarantee that loading is relative to the directory of the current file (or provide any other guarantee about current directory), and has no include at all. * R7RS does have include (4.1.7. Inclusion), though it merely encourages searching the same directory as the caller of include (and certainly doesn't guarantee searching there FIRST, so it's just begging for security vulnerabilities just like PATH=.:$PATH). Maybe it's time to break out cpp or sed :-(, or use some other tool to generate various files for different Scheme implementations. The configure program already modifies the file anyway, so that might not be insane. At the least, I could put things in different files, and then use cat to create files usable to different systems. I'll note that my Common Lisp implementation just works, and it even overrides the reader. In contrast, a common answer seems to be don't bother trying to write portable Scheme: http://stackoverflow.com/questions/11062320/writing-portable-scheme-code-is-anything-standard-beyond-r5rs-itself I *like* Scheme, but it's starting to feel like an abusive relationship :-). --- 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
