I think the standard feature identifiers given in appendix B are too low-level and ill-conceived. They are removing from the high-level nature of Scheme. Specifically I object to:
windows This Scheme implementation is running on Windows. posix This Scheme implementation is running on a POSIX system. unix, darwin, linux, bsd, freebsd, solaris, ... Operating system flags (more than one may apply). i386, x86-64, ppc, sparc, jvm, clr, llvm, ... CPU architecture flags. ilp32, lp64, ilp64, ... C memory model flags. big-endian, little-endian Byte order flags. In the specific case of Gambit-C and probably other Scheme to C compilers, these features are only known when the C code is compiled by a specific C compiler for a particular platform. Indeed it is possible, and a common use-case for me, to compile Scheme code to C, and to ship the C code so that the client can compile the C code in his specific environment (his choice of C compiler, his choice of OS, his choice of hardware, etc). In a sense the C code is a portable assembly language. So these features are not known when cond-expand is expanded. Let me stress that one of the important qualities of a high-level language is that they abstract from lower-level issues (such as processor type, operating system, endianness, etc). This abstraction reduces the conceptual burden when programming and allows code to be portable. It is strange to be able to know with cond-expand what the CPU architecture is, yet nothing in the semantics of Scheme actually depends on the CPU architecture (unless I've missed something when reading the r7rs spec). Same goes for the other features. There is another issue which concerns code mobility. It is currently possible in Gambit-C, and probably other Scheme systems now or in the future, to migrate code from one execution environment to another at run time (think Termite's process migration, or an RPC mechanism). In Gambit-C some code loaded in one instance of Gambit (A) can be serialized and sent over to a different instance of Gambit (B) and executed there. A and B can have entirely different characteristics with respect to the above feature list (CPU architecture, operating system, endianness, word width, etc). Adding the above cond-expand features will hinder this code mobility. It would be nice if some day code mobility was possible between different Scheme implementations. Unfortunately, Scheme code making use of cond-expand will be hard to migrate between instances of different Scheme implementations. So please keep in mind that in general, feature testing with cond-expand prevents code mobility between different Scheme implementations, and in the case of the above list of features it also prevents code mobility between instances of the same Scheme implementation. Marc _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
