Re: [Readable-discuss] initial support for rscheme
I said: > > '+++CL-QUASIQUOTE-abbreviation+++ On Thu, 21 Nov 2013 22:56:10 -0500, John Cowan wrote: > Some Schemes may have problems with this kind of symbol, one that > begins with a character that can begin a number (+, -, and ... are > exceptions). Neither R5RS nor R6RS permits them. Yeah, and I knew better too. In any case, I think this should be fine: (string->symbol "+++CL-QUASIQUOTE-abbreviation+++") --- 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=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
David A. Wheeler scripsit: > '+++CL-QUASIQUOTE-abbreviation+++ Some Schemes may have problems with this kind of symbol, one that begins with a character that can begin a number (+, -, and ... are exceptions). Neither R5RS nor R6RS permits them. Most Schemes simply say anything that's not a number is a symbol, but you can't count on that. -- That you can cover for the plentifulJohn Cowan and often gaping errors, misconstruals, http://www.ccil.org/~cowan and disinformation in your postsco...@ccil.org through sheer volume -- that is another misconception. --Mike to Peter -- 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=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] initial support for rscheme
On Thu, 21 Nov 2013 12:29:58 +0100, "Jörg F. Wittenberger" wrote: > The attached diff makes the whole thing compile under rscheme too (and > run some simple tests). > No changes where made, which where not strictly necessary to that end. Excellent! Thanks so much for your work! I have a few comments and questions below... please modify after taking a look at the comments and resubmit. > I'm sure you'll take issues with the positioning of cond-expand'ed stuff. :-). > I tried for now to keep the compatibility layer before the actual > module. But that might leak definitions (like the rudimentary guard > implementation) outside, which would have to be avoided. For this to we > would have to move the whole section into the body of > `readable-kernel-module-contents`, right? Correct. To the extent that we *can*, I think we need to move things inside the macro that creates the module to minimize leakage. So if you would please maximally move the macro definitions inside the module creation macro, that'd be great. I'm pretty sure we cannot put the "create a module" macro inside the module. Guile's "define-module" lets us scope things, but I doubt that approach will work everywhere else. I don't see how to avoid that. But if we have to leak names, hopefully it'll be just be a single "readable-kernel-module-contents" macro, which is rather unlikely to conflict elsewhere :-). Someday in the great grand future all Scheme implementations will implement a standard module system. Then we wouldn't have the problem... but today is not that day. I really don't like how "translate-cl" was changed. I strongly prefer: (define (translate-cl x) over: (define translate-cl ... (lambda (x) ... )) because it's MUCH easier in the first format to determine that this is a procedure that accepts exactly one parameter. Also, the patched version will calculate 3 values on every entry; the case should compute and return ONLY what it needs to compute. I presume that this isn't working: '+++CL-QUASIQUOTE-abbreviation+++ but you could replace *just* that with this format, yes?: (string->symbol "+++CL-QUASIQUOTE-abbreviation+++") Why all the redefines from "body" to "read-body"? We normally use the same name as per the grammar. We could do that if it's important to port to rscheme, I just want to know why before making the change. I presume you had a reason; if so, we need to document why this is an exception to the naming convention. Basically, just add a comment at the definition of "read-body" to explain why the naming convention is NOT being followed. Could you resend the patch, per those comments? Overall this looks really promising. --- 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=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] initial support for rscheme
The attached diff makes the whole thing compile under rscheme too (and run some simple tests). No changes where made, which where not strictly necessary to that end. I'm sure you'll take issues with the positioning of cond-expand'ed stuff. I tried for now to keep the compatibility layer before the actual module. But that might leak definitions (like the rudimentary guard implementation) outside, which would have to be avoided. For this to we would have to move the whole section into the body of `readable-kernel-module-contents`, right? Best Regards /Jörg --- kernel.scm.orig 2013-11-21 12:19:00.0 +0100 +++ kernel.scm 2013-11-21 12:20:03.0 +0100 @@ -176,6 +176,97 @@ (define-module (readable kernel))) (else )) +; Chicken compatible type annotations. Ignored on other platforms. +(cond-expand + (chicken + (define-type :reader-proc: (input-port -> *)) + (define-type :reader-token: (pair symbol *)) + (define-type :reader-indent-token: (list string *)) + (define-syntax no-values (syntax-rules () ((_) (void + ) + (rscheme + (define-macro (: . x) #f) + (define-macro (no-values) (values)) + ) + (else + (define-syntax : (syntax-rules () ((_ . rest) #f))) + (define-syntax no-values (syntax-rules () ((_) (if #f #t + )) + +; Implementation specific extension to flush output on ports. +(cond-expand + (guile ; Don't use define-syntax, that doesn't work on all guiles + (define (flush-output-port port) ; this is the only format we need. +(force-output port))) + (chicken + (define-syntax flush-output-port +(syntax-rules () ((_ port) (flush-output port) + (else )) + +; Special cases for those Scheme implementations which do that not +; support define-syntax. +; Note that guile is a large special case further down. + +(cond-expand + (rscheme + + (define-macro (readable-kernel-module-contents exports . body) +`(begin ;; (export ,@exports) + ,@body)) + + (define-macro (let-splitter (full first-value second-value) expr . body) +`(let* ((,full ,expr) + (,first-value (car ,full)) + (,second-value (cadr ,full))) + . ,body)) + ) + (else +; assume R5RS with define-syntax + +; On R6RS, and other Scheme's, module contents must +; be entirely inside a top-level module structure. +; Use module-contents to support that. On Schemes +; where module declarations are separate top-level +; expressions, we expect module-contents to transform +; to a simple (begin ...), and possibly include +; whatever declares exported stuff on that Scheme. +(define-syntax readable-kernel-module-contents + (syntax-rules () +((readable-kernel-module-contents exports body ...) + (begin body ... + ; There is no standard Scheme mechanism to unread multiple characters. + ; Therefore, the key productions and some of their supporting procedures + ; return both the information on what ended their reading process, + ; as well the actual value (if any) they read before whatever stopped them. + ; That way, procedures can process the value as read, and then pass on + ; the ending information to whatever needs it next. This approach, + ; which we call a "non-tokenizing" implementation, implements a tokenizer + ; via procedure calls instead of needing a separate tokenizer. + ; The ending information can be: + ; - "stopper" - this is returned by productions etc. that do NOT + ; read past the of a line (outside of paired characters and strings). + ; It is 'normal if it ended normally (e.g., at end of line); else it's + ; 'sublist-marker ($), 'group-split-marker (\\), 'collecting (<*), + ; 'collecting-end (*>), 'scomment (special comments like #|...|#), or + ; 'abbrevw (initial abbreviation with whitespace after it). + ; - "new-indent" - this is returned by productions etc. that DO read + ; past the end of a line. Such productions typically read the + ; next line's indent to determine if they should return. + ; If they should, they return the new indent so callers can + ; determine what to do next. A "*>" should return even though its + ; visible indent level is length 0; we handle this by prepending + ; all normal indents with "^", and "*>" generates a length-0 indent + ; (which is thus shorter than even an indent of 0 characters). + + (define-syntax let-splitter +(syntax-rules () + ((let-splitter (full first-value second-value) expr body ...) +(let* ((full expr) + (first-value (car full)) + (second-value (cadr full))) + body ... + )) + (cond-expand ; - ; Guile Compatibility @@ -243,10 +334,6 @@ (debug-set! stack 50) (no-values)) -; Implementation specific extension to flush output on ports. -(define (flush-output-port port) ; this is the only format we need. - (force-out
