[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Standard Feature Identifiers are too low-level
On Wed, 04 Jan 2012 12:58:49 EST Marc Feeley <feeley@x> wrote:
> > 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).
Note that there are individual differences in how a particular
feature may be implemented by a Scheme impl or its underlying
OS. Then there are things like `threads', which mean different
things to different people!
IMHO, what *would* help is a standard way of knowing a) the
name and version of the Scheme implementation and b) the host
OS, version and process arch. (and may be endian-ness). It
would be nice if the host OS/version/arch is available at
macro expansion time as well. May be with something like
One problem with Scheme impl. is that access to host features
is partially implemented, if at all. For example, defining
FreeBSD as OS at most says I have definitely *no* access to
non-FreeBSD features and *may* have access to -some- FreeBSD
features! So the next level of elaboration may be to define an
OS (or more generally, environment) specific feature namespace
and not try to unify them across all environments (or assume
the same feature name means the same thing). Users of a
specific OS can then standardize feature names for that OS (if
FYI, my interest is in programming in Scheme on plan9 (but not
exclusively in Scheme). For that I am adding plan9 support to
Chibi-scheme & s9 and am quite aware of OS related issues!
Scheme-reports mailing list