> This looks excellent!  Here's a few small points:

Thanks! I submitted it in great doubt as to whether anyone else cares
about the problem to begin with. For script launchers, package managers
and many other kinds of automation (continuous integration jobs, etc.)
it would make life easier.

I appreciate the detailed comments.

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

Do you intend something along these lines:

(import (srfi 176))

(version-alist)  ; returns the whole merged alist as in the examples

(cadr (assoc 'release (version-alist)))      ; property with one value
(cdr (assoc 'library-path (version-alist)))  ; property with many values

This is probably reasonable. Most implementations likely have native
procedures to get most of the same info from Scheme, but a standard
interface can't hurt.

The Environment Stack pre-SRFI (finished save for a few details) covers
some of the same ground. I can send the draft if there's interest. Your
SRFI 112 (Environment Inquiry) also has the very basics (name/version).

> 2) Make it clear if stand-alone compiled programs written in Scheme may,
> must, should, or should not support this SRFI.  If so,  the compiler will
> have to effectively synthesize the procedure mentioned in #1 at compile
> time.

Interesting. It didn't occur to me that we could prescribe things for
user programs. Since the SRFI mandates flag -V, I think we cannot do
that; Scheme coders should be able to decide which flags their programs
have and what they do. (Well, there is the magic flag -: for Scheme
runtime options in user programs; I guess -:version could print the
Scheme version info. Opinions?)

> 3) Return non-sexp lines as (non-parsable "blah blah blah") rather than
> just discarding them, as there may be valuable information in them.

The current draft doesn't specify a standard reader; only rules for
writers so that readers can get the info they care about. That means
it's fine for readers to preserve information about non-sexp lines.

> 4) Add "compile-command" so that systems like Chicken and Gambit with
> standalone compilers can be accommodated.

You mean if we run `fantastic-interpreter -V` it would be as follows:

(scheme-id fantastic-scheme)
(command "fantastic-interpreter")
(compile-command "fantastic-compiler")

That is nice. The problem is that (command ...) is the canonical name of
the command, whereas a program wanting to compile code would need the
local name. E.g. Gambit's "gsc" compiler is installed as "gsc-gambit" on
FreeBSD, in which case a (compile-command "gsc") would be misleading.

We could have "compile-command" be the installed name instead of the
canonical name. That would be asymmetric with "command"; we can change
the name of one of them to make it more obvious. I think it's useful for
"command" to be the canonical name, since any program running "foo -V"
already knows that "foo" is the installed name.

Finally, there's the problem that the installed binary can be moved.
That's probably not worth worrying about. Any number of other build-time
assumptions can break too if you move files around after installation.

Should the compiler's version info point to the interpreter command?
That's probably not particularly useful.

> 5) Since there is no limit on the length of lines (and modern *ix tools
> impose none), you might as well remove support for multi-line
> S-expressions.  This will encourage people to use the "Hacks for lists"
> style, which should be called "Simplifying complex lists".
>
> 6) Consider removing support for nested lists also for the same reason.
> (Maybe you meant to, but the Specification part doesn't actually say that.

I want to support nesting due to Zawinski's Law of data: Every syntax
attempts to expand until it can represent nested lists. Any syntax which
cannot so expand is replaced by one which can. In my experience, this
law is inescapable and people who defy it are rewarded with duct-tape
and tears (enough to go around for everyone in the vicinity).

Nested lists are discouraged because Unix tools have a hard time parsing
them. But it's like code optimization: avoid it as long as possible, but
it you don't have it ready for those last-ditch efforts, something worse
will take its place.

> 7) Platform support is kind of a mess.

It's not that messy if you ignore the obvious property, "platform" :D It
should probably be renamed to something more obscure since it's in an
implementation-defined format. Suggestions?

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

platform-userland is very nice! Let's add that. The only problem is,
where do we get decent enum values for it? There's nothing reasonable
you can reliably get from `uname` in my experience.

You're completely right about platform-bits. The distinction it's
supposed to make is the lp64/llp64/ilp32 thing. Anyway, native address
width of the CPU is a different question, and a more complex one (for
CPUs like x86-64 that can switch between 16/32/64-bit instruction sets).

platform-userland and platform-bits work together to tell the C/machine
level ABI that the Scheme implementation has been built for.

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

It's a good idea to make the distinction. Maybe slash is the best
delimiter in ASCII. Colon is another possibility. Is dot a portable option?

> This is more controversial because it isn't known at compile time:  what
> about adding uname?

It's perfectly OK for some of the info not to be known at build time.
There are several explicit mentions in the SRFI text that the info can
vary. The feature list is one example: for example, two Schemes support
both R6RS and R7RS; they would have different feature lists for each.
The R6RS mode can't have the `r7rs` feature for example.

So `uname` is no problem from that standpoint. I guess I'd like to add
whichever properties Scheme implementors find useful. All properties are
optional so it's no big deal to have a few extra ones. So if someone
wants a `uname` property for their Scheme, I'll add it.

There's already `platform-os` though, so we'd have to think about the
precise meaning of each, and whether they are different enough that
there should be both.