Am 15.11.2013 15:11, schrieb David A. Wheeler: > 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!.
Will go there. I intent to make the code compile for chicken and rscheme and with your help to not break guile. >> 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. Let me put my question differently: do we HAVE TO support some guile version, which does not have guard/raise? Also: rscheme does (by itself) not have guard. The code would have to have three versions at least... But maybe that's not even relevant. It occurs to me that the only use of catch/throw is IMHO stylistic questionable. In general it's seen as bad style if exceptions are caught in the course of normal operation. It might be more appropriate for me to first understand the code - which failed a minute ago. At the moment I suspect here we have such a case. Maybe a slight restructuring could avoid the whole construct. > > >> 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. As to wish lists: at the moment I have no need use for `set-read-mode`. Once I'm there I'll want this thread-safe. I'd turn toplevel variables it modifies into parameter objects. If there are no objections. > > >> 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. Yeah. RScheme also has define-macro only. > >> 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. I've seen that. Back to the wish list. I'd like the code to be flexible and not restrict the user to one keyword syntax. But I also need a way to do just that. I need a keyword syntax implementation, which is independent from the underlying Scheme. This is going to be some massaging. But I'm confident that the changes are not too excessive. Best /Jörg .... ------------------------------------------------------------------------------ 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
