[Readable-discuss] Type declarations
We now have Chicken Scheme type declarations, thanks to the work by Jörg F. Wittenberger. Chicken Scheme type declarations are defined here: http://wiki.call-cc.org/man/4/Types Racket also includes type declaration language: http://docs.racket-lang.org/ts-guide/ Naturally, Racket's system is very similar but syntactically incompatible, continuing the usual Scheme hostility towards portability :-(. For such a beautiful language, ugly Scheme code is sure a common result :-(. Maybe we should use a term other than ":" and let macro systems define them into the local type system. That assumes that type systems like Chicken and Racket accept the results of macros. But *can* we use macros to generate "(: ...)" type declarations? Should we? --- 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
"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=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 Sat, 23 Nov 2013 11:28:22 +0100, "Jörg F. Wittenberger" 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=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
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 Compat
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" >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=63431311&iu=/4140/ostg.clktrk ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
