> 1) Allow a running program to retrieve this same information as a Scheme
> object by calling a procedure, which allows the program to customize
> itself.

Implemented this as:

(import (srfi 176))
(version-alist) => returns the same alist as in the -V output

In light testing it seems convenient enough that nothing more complex is
probably needed.

> 7) Platform support is kind of a mess.  I'd get rid of plain "platform" and
> add "platform-userland".  The number of bits in a platform doesn't really
> tell you enough because different fundamental types can have different
> sizes: I'd go with platform-(memory-)model a la the features list: lp64,
> llp64, ilp32, etc.

> 8) For the sake of unambiguity, private properties should use / or
> something besides - to connect the name(space) with the property name:
> fantastic-scheme/POM.

Here's what I have so far:

$ upscheme -V
(command "upscheme")
(scheme-id upscheme)
(language scheme r7rs)
(features 64-bit little-endian r7rs)
(platform (kernel openbsd) (userland openbsd) (computer x86-64) (endian
little))
(c-type-bits (int 32) (long 64) (float 32) (double 64) (pointer 64)
(size_t 64) (value_t 64))
(c-compiler-version "GCC" "4.2.1 Compatible OpenBSD Clang 5.0.1
(tags/RELEASE_501/final)")
(c-compiler-command "clang")
(c-compiler-flags "-Wall -Werror -Wextra -O2 -D NDEBUG -D
USE_COMPUTED_GOTO -std=gnu99 -Wno-strict-aliasing")
(c-linker-flags "-lm")
(revision "unknown")
(build-date "2019-10-14")
(release "0.0.0")
(release-date "1970-01-01")
(upscheme/stable-specs)
(upscheme/unstable-spec "2019")

The platform 4-tuple is stolen from
<https://wiki.debian.org/Multiarch/Tuples> as faithfully as possible
(currently, not very). If you go to that page, they have done an
excellent job mapping loads of 4-tuples covering numerous platforms. We
should probably just adopt their approach.

So their 4-tuple is (kernel userland computer endian) as above.

The precise CPU/OS ID's are harder. We could start with the ones on that
page, and mapping BSD equivalents to them. That should cover a very
large part of the IDs people will run into in `uname` output and such.

Another indispensable survey site is <http://predef.sf.net/> which lists
tons of C preprocessor macros defined by compilers, CPUs, OSes, etc.

Comments on the above format? The most controversial thing is the added
nesting on the platform tuples and the c-type-bits.

For JVM Schemes like Kawa, there could probably be an equivalent
(java-type-bits ...). I don't know how stable the Java int, long etc.
sizes are.

Based on
<https://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html>
you can switch "int" between signed and unsigned in some situations! In
C, the signedness of "char" is famously undefined; I don't know whether
that is useful information for Scheme. I can't think of any use for it.
"int" signedness may be more useful to know because it says something
about the value range it can store. "char" stores such small values that
nobody uses that type to get any kind of range. It's mainly a synonym
for "byte" and people ignore the signedness.