Re: [Readable-discuss] Supporting SRFI-110 in chicken (Joerg Wittenberger)
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 50) ... 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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Supporting SRFI-110 in chicken (Joerg Wittenberger)
Am 14.11.2013 21:02, schrieb David A. Wheeler: I said: If you could help us integrate the rest of your changes into the code, that'd be great. Sure. Which one are missing by now? Here's what I think is missing. I'm hoping you'll join the mailing list soon, and that we can discuss these publicly. These shouldn't be hard, but we need to *not* bust guile support. In fact, we include support for some fairly old versions of guile, because that's what some people have. Sure! especially now that GNUmake supports guile too. In fact I'll have to install it on my machine one day. NOTE: First patch hunk - we've switched to flush-output-port, but we need to address throw vs. raise. --- srfi-110.orig.scm 2013-11-07 14:13:43.0 +0100 +++ srfi-110.test.scm 2013-11-13 11:30:31.0 +0100 @@ -2009,13 +2020,19 @@ ; Call on sweet-expression reader - use guile's nonstandard catch/throw ; so that errors will force a restart. (define (t-expr-catch port) - +#| ; Default guile stack size is FAR too small (debug-set! stack 50) (catch 'readable (lambda () (t-expr port)) - (lambda (key . args) (read-to-unindented-line port) (t-expr-catch port + (lambda (key . args) (read-to-unindented-line port) (t-expr-catch port))) +|# + (guard + (ex ((eq? ex 'readable) (read-to-unindented-line port) (t-expr-catch port)) + (else (raise ex))) + (t-expr port)) +) ; - ; Write routines 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? You comment about old guile refers to the use of guard/raise at all, doesn't it? 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? 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. @@ -173,7 +173,17 @@ ; define the module ; this ensures that the user's module does not get contaminated with ; our compatibility procedures/macros -(define-module (readable kernel +(define-module (readable kernel))) + (chicken + (define string-keyword + (let ((kwprefix (string (integer-char 0 + (lambda (tok) + (##sys#intern-symbol + (if (eq? 0 (##sys#size tok)) + : + (##sys#string-append kwprefix tok)) + ) + (else )) (cond-expand ; - ; Guile Compatibility @@ -1268,10 +1280,11 @@ ((char=? c #\| ) ; Read |...| symbol (like Common Lisp and R7RS draft 9) (get-barred-symbol port)) - (#t ; Nothing else. Must be a symbol start. - (string-symbol (fold-case-maybe port - (list-string - (read-until-delim port neoteric-delimiters))) + (else ; Nothing else. Must be a symbol start. + (let ((s (fold-case-maybe port (list-string (read-until-delim port neoteric-delimiters) + (if (eq? (string-ref s (sub1 (string-length s))) #\:) + (string-keyword (substring s 0 (sub1 (string-length s + (string-symbol s)) ; - ; Curly Infix So how would this work for guile? Does it have a string-keyword? Or was is a symbol-keyword? /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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Supporting SRFI-110 in chicken (Joerg Wittenberger)
Jörg F. Wittenberger scripsit: Sure! especially now that GNUmake supports guile too. In fact I'll have to install it on my machine one day. Just don't try to do anything else that day. Guile 2.x is the slowest to install of all my Schemes (though admittedly I don't try to install Racket or Larceny from source). -- John Cowanhttp://www.ccil.org/~cowan co...@ccil.org Please leave your valuesCheck your assumptions. In fact, at the front desk. check your assumptions at the door. --sign in Paris hotel --Cordelia Vorkosigan -- 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=63469471iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
