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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports