[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Standard Feature Identifiers are too low-level
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).
Scheme-reports mailing list