On 2012-01-03, at 3:51 PM, John Cowan wrote: > Marc Feeley scripsit: > >> 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: [list snipped] >> >> 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. > > In that case, it would be inappropriate for Gambit to expose these > identifiers. The only required identifier is r7rs. The other identifiers > are only specified in order to obviate pointless debates about how to > spell them.
My issue with these feature identifiers is that their semantics is vague. Are they a feature of the compile-time Scheme system, or run-time Scheme system, or something else? What can I infer from the "windows" feature? Is this windows 3.0 or 95 or ...? The only practical use I can see is to determine the filename syntax, but there are better ways to determine this or to isolate from the difference. Also, endianness is not a pure dichotomy (some systems store code one way and data another, some are middle-endian, etc). Are the CPU architectures well defined? What is the set of features of i386? Aren't there differences in sub-variants of i386? So as a programmer, what are the guarantees I have if the feature i386 is on? Can you present a use-case for these feature identifiers? >> 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). > > That's true. However, programs often require low-level portions as well, > in the name of efficiency rather than correctness. But these low-level feature identifiers don't buy me anything (as far as I can see in the R7RS spec)! What can I do more efficiently with them than without (within the R7RS spec)? >> 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). > > Presumably not, however, compiled C code. Yes and no. Compiled code can be serialized as long as it is pre-compiled on both systems. This allows serializing closures which are dynamically created by compiled code. Anyhow, this is not really related to my argument. > Feature testing is not aimed > at mobility, but at portability: it allows programs (and especially > libraries) to compensate for differences between applications. > For mobility, you need to test features at run time; hence the need for > a get-features procedure. I agree, but a more general get-features procedure would be interesting (i.e. one that allows more complex queries than checking features identifiers). Compare (memq 'cpu64 (get-features)) with (> (get-word-width) 32). Marc _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
