The current code includes: > > ; Default guile stack size is FAR too small > > (debug-set! stack 500000) ...
On 15 Nov 2013 11:53:15 +0100, Jörg F. Wittenberger: > So what is this "debug-set!" - does this have to be called for each > t-expr-catch call? Or would it be enough to call this once in the > initialization of the code? The name of "debug-set!" is misleading. It's a guile-specific call that lets you set low-level configuration values. In particular, the default guile stack size is absurdly small, causing crashes on even relatively simple parses. Yes, it'd be perfectly fine to set it on initialization, not on each invocation. That really should be moved into an "initialize" function, and then the guile-specific version calls debug-set!. > You comment about "old guile" refers to the use of guard/raise at all, > doesn't it? Not just that, it's version numbers of guile. The current stable release of guile is 2.0.9. But the guile on Cygwin is version 1.8.7, and Alan has a case where he has to use guile version 1.6. > I see to solutions: a) cond-expand on guile the definition of t-expr-catch > right where it is b) move this definition into the compatibility section. > The latter would be better to keep the compat-stuff together, the former > would cluster the code according to the logic. I'd prefer the former. How > about you? I want the latter - please move things into the compatibility section. Otherwise the code will over time get very hard to read, because it'll be completely cluttered with "if system1... else if system2....". If the code just calls "init-sweet-expressions" (for example), then the compatibility layers can define what that is for various circumstances. In general I'd like it to be R5RS, R7RS if we need it, and then use various procedure and macro definitions to paper over the differences. > The "raise" I'd suggest to do like > > (define-syntax raise (syntax-rules () ((_ x) (throw x))) > > in the compat section for guile and keep the srfi-34/r7rs compatible code > in the main body. Agree I overall. One nit: old guiles (<2) don't have define-syntax. This is not a problem, we can just use "defmacro" in the guile-specific portability layer, and syntax-rules where needed for other implementations. The kernel.scm code has an example of it, it's not complicated. > So how would this work for guile? Does it have a string->keyword? Or was is > a symbol->keyword? We've already implemented keywords for guile, actually. It's symbol->keyword (good guess!), and in guile keywords begin with "#:". See parse-hash for details. --- 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
