> 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.
I *think* awk can be more portable. The nice thing with the separate-processors approach is that we can solicit just the bits we need to concatenate from the various Scheme islands. If we have one file that makes everything, it will eventually become a single large monster that no one likes to touch (assuming widespread usage of this particular implementation of SRFI-110, at least). Separate generators for each implementation-version we claim to support strikes as more maintainable in the long run. I don't expect a lot of code duplication, if we could have a "good enough" set of "things I assume the compatibility layer can do". Oh, and source annotation is a ****er. The style used assumes Guile idioms. In Racket a reader is supposed to return "syntax objects", which wrap a datum and the source location and top-level lexical environment. Syntax objects are either a datum+source loc, or a syntax-cons on syntax objects (or a syntax-vector or a syntax-whatever). It's theoretically possible to use a eq?-key hash table for attach-source-info (key is the datum, value is the source info), wrap sweet-read, and when sweet-read returns a datum, to convert the datum and its sub-datums to syntax objects, attaching the source info to each datum. Instead of exporting sweet-read directly, we just wrap it into an extra layer of (let () ..) that returns sweet-read and friends, then wraps the returned sweet-read into an actual sweet-read that makes the hash table and does the whatever whatever needed to turn them into syntax objects. The hash table does not need to be weak-keyed, since it lives only within the sweet-read invocation. Sincerely, AmkG ------------------------------------------------------------------------------ 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
