John Cowan dropped the following bad news: > >> Dude, you have a hold of the Tar Baby here. R6RS and R7RS libraries > >> can't be the result of a macro, neither as a whole nor in part. All > >> you've done is trade off one set of portability breakers for another. > >
I said: > > Ugh. In that case, maybe we should just drop the > > "readable-kernel-module-contents" > > macro altogether, and just write straight code with weird names to > > reduce possible namespace problems. > > We can include cond-expand guile magic so that it works as-is as a guile > > module. > > > > Alan: Any objections? On Fri, 6 Dec 2013 12:12:51 +0800, Alan Manuel Gloria <almkg...@gmail.com> wrote: > None whatsoever. > > I think Jorg's proposal to make a file (the "shar") that makes the > output based on the detected Scheme implementation is good. We could > even run the file multiple times to generate different outputs, one > for each Scheme supported and detected. > > I propose this system: > > 1. We write as if we own the namespace. Select some suitable soup of > features from R4RS through R7RS, and define it in comments well in the > core implementation file. The core implementation file is then just a > bunch of (define ...) forms, possibly with some hooks on options like > "CL mode" or "Scheme mode". > > 2. Write a bunch of "shar"s, which take the original file and > transform it to code that a particular Scheme implementation-version > accepts. Basically, it just prepends and appends some additional > code, probably just plain text, to the core implementation file. The > shar can put the entire core implementation file within some sort of > (define-library... ) form, if needed. > > 3. If a particular Scheme implementation-version supports parameters, > then the "CL mode" option can be made into a parameter. If not, it > can be a global instead. We document this in, say, a USAGE.Chicken or > USAGE.Guile-1.8 or whatever file. > > For example, a "standard R5RS shar" would just wrap the implementation > file in something like: > > #! /bin/sh > > IN=$1 > OUT=$2 > > cat > $OUT <<PREFIX > (define (readable%is-cl-mode) > readable%cl-mode) > (define readable%cl-mode #f) > > (define readable%whatevers > (let () > PREFIX > cat $IN >> $OUT > cat > $OUT <<SUFFIX > (list sweet-read neoteric-read curly-read) > ) ;let > ); define readable%whatevers > > (define sweet-read (car readable%whatevers)) > (define neoteric-read (cadr readable%whatevers)) > (define curly-read (caddr readable%whatevers)) > SUFFIX Hmm. Generating code is reasonable of course. One problem with the "shar" approach is that common code will be copied into different separate files, and eventually not consistently maintained. I'd like to say "one thing once" as much as possible (for maintenance). A variation would be to create ONE shell script that can generate (to stdout) Scheme code for the variant identified in a parameter; it could "cat" the main code at the right time. Something like: ===== #!/bin/env sh # $1 is the type to generate. case "$1" in GUILE) echo "..." ;; *) echo "..." ;; esac cat kernel.scm ===== A completely different approach is a cpp-like tool. I've cobbled together an awk implementation of cpp-like syntax so you can do this: #ifdef GUILE ... #elseifdef RSCHEME ... #else ... #endif Either one would mean that we only need to say something ONCE if it can be used in multiple circumstances. --- David A. Wheeler ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
