Re: [Readable-discuss] A road block: #:
David A. Wheeler scripsit: John Cowan may know if nested cond-expands port in practice (among systems with cond-expand). They do. See http://trac.sacrideo.us/wg/wiki/CondExpand. for details. -- What asininity could I have uttered John Cowan co...@ccil.org that they applaud me thus? http://www.ccil.org/~cowan --Phocion, Greek orator -- 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] A road block: #:
Am 19.11.2013 05:38, schrieb David A. Wheeler: Am 18.11.2013 15:25, schrieb David A. Wheeler: On Mon, 18 Nov 2013 13:23:32 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. Okay, the source code no longer has #:. The result is extremely magical guile code, to work around some wonkiness in old versions of guile, but the magic is explained in comments. Great if this works in guile, rscheme reads it too. I'll be able to make progress. However I have a problem with another change: while all the Scheme's I know process nested cond-expand forms I recall that srfi-0 explicit does not requites this to be the case and suggest to avoid such use. Should be have these nested cond-expand's? Also: often different Scheme's can share different code parts. Enforcing a single cond-expand with nested cond-expands is not only against srfi-10; I can foresee how this will complicate the code and require quite some repetition and confusing logic in those conditions the cond-expand's dispatch on. Let alone that alternatives, which belong logically together are spread around in the file. That's a nightmare to maintain. Hence: I'd prefer to cluster all cond-expands at the beginning, but have one cond-expand per dispatch reason. Comments? 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] A road block: #:
On Tue, 19 Nov 2013 09:36:50 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: However I have a problem with another change: while all the Scheme's I know process nested cond-expand forms I recall that srfi-0 explicit does not requites this to be the case and suggest to avoid such use. Should be have these nested cond-expand's? I would *expect* it to work, but I don't see any information about nested cond-expands in: http://trac.sacrideo.us/wg/wiki/ImplementationContrasts John Cowan may know if nested cond-expands port in practice (among systems with cond-expand). Also: often different Scheme's can share different code parts. Enforcing a single cond-expand with nested cond-expands is not only against srfi-10; I can foresee how this will complicate the code and require quite some repetition and confusing logic in those conditions the cond-expand's dispatch on. Let alone that alternatives, which belong logically together are spread around in the file. That's a nightmare to maintain. Hence: I'd prefer to cluster all cond-expands at the beginning, but have one cond-expand per dispatch reason. Great rationale, makes sense. Okay, we can try it. My one concern is that we need to try to scope all of this shim stuff so that it *only* affects our module. Anything we define here should not affect names in other modules or the invoker (other than the functionality the invoker imports). I will say that a nontrivial amount of the guile stuff is interrelated, so I fear this approach may make it harder follow the guile portion. But maybe not. The obvious approach is to try and see. 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
[Readable-discuss] A road block: #:
In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. **HALT** error: scan-token:439: #\# cannot be followed by #\: Is there a way in Guile to split source in multiple files? Would it acceptable to split the compatibility section out of the main code for sweet/kernel? Otherwise I don't see how to proceed for rscheme and foresee the same problem around the corner for some other Schemes too. Best Regards /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] A road block: #:
Am 18.11.2013 15:25, schrieb David A. Wheeler: On Mon, 18 Nov 2013 13:23:32 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. **HALT** error: scan-token:439: #\# cannot be followed by #\: Is there a way in Guile to split source in multiple files? Would it acceptable to split the compatibility section out of the main code for sweet/kernel? Otherwise I don't see how to proceed for rscheme and foresee the same problem around the corner for some other Schemes too. I presume the problem is in this guile-specific code: (use-modules ((srfi srfi-69) #:select We can't replace #:select with (symbol-keyword 'select) unfortunately; guile won't recognize it. I suspect what we should do is right there temporarily have guile use prefix keyword notation (:select), using something like (read-set! keywords 'prefix), and then restore whatever was there before. Then other Schemes can read it. If that is possible, great! No comments so far on the possibility to put these things into platform-specific files? /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] A road block: #:
Am 18.11.2013 15:25, schrieb David A. Wheeler: On Mon, 18 Nov 2013 13:23:32 +0100, Jörg F. Wittenberger joerg.wittenber...@softeyes.net wrote: In a first attempt to feed the source to some other Scheme I went ahead and sent it to the rscheme compiler. Doesn't work. It has the same problem as Guile: it will refuse to read certain #sharp syntax. Okay, the source code no longer has #:. The result is extremely magical guile code, to work around some wonkiness in old versions of guile, but the magic is explained in comments. --- 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
