Re: [Readable-discuss] initial support for rscheme
Did I say next week? I should rather do something else, but I can't fight myself. :-/ Bad news this time. Am 22.11.2013 14:59, schrieb David A. Wheeler: On Fri, 22 Nov 2013 10:26:58 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Why all the redefines from body to read-body? We normally use the same name as per the grammar. RScheme idiosyncratic: `body` is already a bound elsewhere within some code required com compile this code. Hence RScheme complains about the semantic error and that redefinition would break things. The only reasonable way I saw was to change the name to avoid the conflict. However by re-considering the case now I understand that the desire to keep `body` there literally to match the grammar. In that case we should macro-define body into read-body for RScheme only. If Rscheme will accept that without complaint, that'd be very nice. Otherwise, I'm happy to rename definitions to make it work... I just want to minimize it, and document why there's a variance when it happens. I'd now rather take back my suggestion to macro-define around: while it would work for the call site, I have no (good) idea how to change the definition. Furthermore bad news regarding the idea to move those cond-expand's into the read-able-module-contents. The problem is not cond-expand, but rscheme accepts define-macro only at top level. The attached patch has a strange name in a way, considering that it contains much more than this. However it also fixes a bug in n-expr-or-scomment. David, could you merge this into the git repo? The next thing I'd try to get around would be making those settings port specific. But I'd rather like to keep those diffs size down. 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] initial support for rscheme
Am 23.11.2013 11:28, schrieb Jörg F. Wittenberger: The attached patch Which attached patch you ask? Here we go. --- kernel.scm.orig 2013-11-23 11:16:19.0 +0100 +++ kernel.scm 2013-11-23 11:17:14.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-output port)) - ; Guile was the original development environment, so the algorithm ; practically acts as if it is in Guile. ; Needs to be lambdas because otherwise Guile 2.0 acts strangely, @@ -455,52 +542,15 @@ (define (type-of x) #f) (define (type? x) #f) - (define (string-keyword s) -(symbol-keyword (string-symbol s))) - ) ; - ; R5RS Compatibility ;
Re: [Readable-discuss] initial support for rscheme
On Sat, 23 Nov 2013 11:28:22 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Did I say next week? I should rather do something else, but I can't fight myself. :-/ Excellent! They're merged in the repo now, although I had to make a number of changes to make guile work. Bad news this time. I'd now rather take back my suggestion to macro-define around: while it would work for the call site, I have no (good) idea how to change the definition. No problem. I don't mind violating the naming convention for portability, as long as we document *why* in a comment. I added such a comment, and accepted your renames. Furthermore bad news regarding the idea to move those cond-expand's into the read-able-module-contents. The problem is not cond-expand, but rscheme accepts define-macro only at top level. Ugh. I see no way to avoid having some leakage into the invoker's namespace in those cases. We can probably rename those things to make them unlikely to matter, e.g., including readable- prefixes in them. We should probably split up the cond-expands so things that HAVE to be expanded outside, for a given implementation, are done... and everyone else has a cleaner interface. The attached patch has a strange name in a way, considering that it contains much more than this. However it also fixes a bug in n-expr-or-scomment. Not a problem, I split it into multiple commits anyway. I ended up doing modifying it so that guile will work. Please test and see if my modifications also work for you! David, could you merge this into the git repo? Done, with mods as noted above. In the longer term we should reorganize it, to limit name leakage, but it may be easier to first make sure it *runs* on these different Schemes. *grumble* Scheme should have had a standard module system, decades ago *grumble*. Using macros to work around the lack of a universally-implemented module system is awkward and imperfect. The next thing I'd try to get around would be making those settings port specific. But I'd rather like to keep those diffs size down. Smaller diffs sounds awesome to me!! --- 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] initial support for rscheme
Jörg F. Wittenberger: The problem is not cond-expand, but rscheme accepts define-macro only at top level. R5RS also limits define-syntax to the top level. R6RS and R7RS relax this, but not everyone's there currently. (See below). We could use cond-expand to define top-level macros if the Scheme implementation provides no alternative. In the other cases, we could provide a cleaner namespace for invokers. We don't define many macros, I only see :, no-values, readable-kernel-module-contents, and let-splitter. We could rename let-splitter to readable-let-splitter, and no-values to readable-no-values, to reduce the risks of namespace issues. I'd hate to use something other :. --- David A. Wheeler P.S.: Here's define-syntax info for R5RS, R6RS, and R7RS: * R5RS states that define-syntax syntax definitions are valid only at the top level of a program (section 5.3, Syntax definitions). This is relaxed later: * In R6RS, Keyword bindings established by define-syntax are visible throughout the body in which they appear, except where shadowed by other bindings, and nowhere else, just like variable bindings established by define. (Section 11.2.2). * R7RS relaxes this restriction; it describes define-syntax and says that syntax definitions can appear at the outermost level or nested within a body (section 5.4, syntax definitions). -- 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] initial support for rscheme
Am 22.11.2013 04:45, schrieb David A. Wheeler: On Thu, 21 Nov 2013 12:29:58 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: 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. Against which file version should I do the patch? Also: might take a moment. I'm a bit busy at the moment. 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. Up, I just noticed that I forgot to add a type declaration here. But that should do the trick. Otherwise I understand that it might be a little harder to read. But I'd claim it's not much harder. And it might be worth the effort. See: First my definition for reference: (: translate-cl (* -- *)) (define translate-cl (let ((qq (string-symbol +++CL-QUASIQUOTE-abbreviation+++)) (uq (string-symbol +++CL-UNQUOTE-abbreviation+++)) (us (string-symbol +++CL-UNQUOTE-SPLICING-abbreviation+++))) (lambda (x) (if common-lisp (case x ((quasiquote) qq) ((unquote) uq) ((unquote-splicing) us) (else x)) x Also, the patched version will calculate 3 values on every entry; No, it does not compute any value upon entry. To the contrary, all those three bindings are computed just once at definition time. That's why I lifted them from the procedures body. 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+++) Yes, I could. But THIS would be one computation for each invocation (of the matching case here). Now this is rather cheap: a hash table lookup per quasiquote/unquote/unquote-splicing which in turn are rare. Why all the redefines from body to read-body? We normally use the same name as per the grammar. RScheme idiosyncratic: `body` is already a bound elsewhere within some code required com compile this code. Hence RScheme complains about the semantic error and that redefinition would break things. The only reasonable way I saw was to change the name to avoid the conflict. However by re-considering the case now I understand that the desire to keep `body` there literally to match the grammar. In that case we should macro-define body into read-body for RScheme only. 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. As I said, busy by now. Maybe next week if things go well. 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] initial support for rscheme
On Fri, 22 Nov 2013 10:26:58 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: Against which file version should I do the patch? Please use the latest version in git repo on develop branch. I've already incorporated some of the changes you just submitted, basically the type annotations and a tweaked version of your translate-cl. It's *easiest* for me if you use git, but you don't need to. If you don't want to install and use git, you can download the current version this way: http://sourceforge.net/p/readable/code/ci/develop/tree/src/kernel.scm?format=raw ... but please let me know when you downloaded it. That will make it is easier for me to integrate if there are other changes. No, it does not compute any value upon entry... You're right, sorry. ... 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+++) Yes, I could. But THIS would be one computation for each invocation (of the matching case here). Now this is rather cheap: a hash table lookup per quasiquote/unquote/unquote-splicing which in turn are rare. Okay. It's not clear to me that this optimization is worth it, but I think with the addition of a type declaration it'll be obvious enough. Let's just add the type declaration and do it as proposed. Why all the redefines from body to read-body? We normally use the same name as per the grammar. RScheme idiosyncratic: `body` is already a bound elsewhere within some code required com compile this code. Hence RScheme complains about the semantic error and that redefinition would break things. The only reasonable way I saw was to change the name to avoid the conflict. However by re-considering the case now I understand that the desire to keep `body` there literally to match the grammar. In that case we should macro-define body into read-body for RScheme only. If Rscheme will accept that without complaint, that'd be very nice. Otherwise, I'm happy to rename definitions to make it work... I just want to minimize it, and document why there's a variance when it happens. As I said, busy by now. Maybe next week if things go well. Okay! I look forward to it. Thanks so much for your time. --- 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] initial support for rscheme
On Thu, 21 Nov 2013 12:29:58 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net 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=63431311iu=/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=63431311iu=/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
I said: '+++CL-QUASIQUOTE-abbreviation+++ On Thu, 21 Nov 2013 22:56:10 -0500, John Cowan co...@mercury.ccil.org 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=63431311iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
