Bakul Shah scripsit:

> 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
>     #+<implementation>[-<version>]
>     #+<os-name>[-<version>]
>     #+<arch>[-<version>][-<endian>]

That is exactly what we have now in R7RS, but using the cond-expand syntax
rather than CL syntax.  Since there is no standard way to modify Scheme
lexical syntax, we assume that "read" can process code for any Scheme.

> 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!

Not really, unless you mean by "non-FreeBSD features" features that
*cannot* be available on FreeBSD.  What "freebsd" means as a
cond-expand feature is that the run-time environment is FreeBSD.

> 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
> they care).

We are not attempting to specify any environment-specific feature
identifiers.

--
John Cowan  cowan@ccil.org  http://ccil.org/~cowan
Linguistics is arguably the most hotly contested property in the academic
realm. It is soaked with the blood of poets, theologians, philosophers,
philologists, psychologists, biologists and neurologists, along with
whatever blood can be got out of grammarians. - Russ Rymer

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports