>> (import (srfi 176))
>> (version-alist)  ; returns the whole merged alist as in the examples
>
> Just so.

OK, I'll add it. Though I'd like to get a third opinion from somebody.

>> Your SRFI 112 (Environment Inquiry) also has the very basics (name/version).
>
> I'd like to withdraw that one in favor of this one.

Wow, thanks! I've used 112 as a FFI learning exercise.

I think you could make that a recommendation but not a requirement.  "User
> programs compiled by xxx Scheme should output the same things as the
> implementation itself if given the option -:version.

That's a very nice way to solve it. I'll add that text.

>> The current draft doesn't specify a standard reader; [...]
>> it's fine for readers to preserve information about non-sexp lines.
>
> No, but your sample readers (which will quickly become the usual readers)
> shouldn't throw such lines away.  Make it so they don't and document the
> meaning of it.

Fair enough. I'll do that.

> 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.
>
> Yes, I just meant the canonical name.  But arguably it isn't necessary,
> since a program is either running under the interpreter, in which case
> "command" should be the interpreter, or it's compiled, in which case
> "command" should be the compiler....

True. I guess there may be a case where an interpreted programs wants to
compile some other program, but seems quite niche.

> Hmm, maybe this feature isn't very useful after all.  What did you have in
> mind having anyone do with it?  It's probably not enough to execute
> anything.

Yeah, it's not meant to be executed. Just to identify the program.
Assume a third-party program knows how to use the interface of Gambit's
"gsc" command for example. Then it can find an executable like
"gsc-gambit" or whatever the name is on some system, and be confident
that since the version info says (command "gsc") it can use that command
with the "gsc" interface. Likewise, "csi" can be installed as "csi",
"csi4", "csi5", "chicken-csi" or something else; all of them would have
(command "csi").

At some point when implementing <https://github.com/lispunion/lila/>, I
realized it's best to just gather a big list of all known command names
ever, and try running all of them with version flags to find out who
they say they are. It's not worthwhile to keep a table of which command
names are for which implementation; it's redundant and there will be
command name conflicts you won't take into account. This detector shows
how good the situation already is:
<https://misc.lassi.io/2019/lisp-impl-version.c>. If we can get all that
assurance without a standardized flag and output format, imagine how
easy it is with one.

The (scheme-id ...) and (command ...) are meant to completely
disambiguate a particular program. E.g. the classic name conflict would
be handled like this:

(command "scheme")
(scheme-id mit-scheme)

vs

(command "scheme")
(scheme-id chez-scheme)

> Fair enough.  But still, flush multi-line lists.  A LOSE line begins with (
> and ends with ), period.

[continued in the other thread]

>> platform-userland
>> where do we get decent enum values for it?
>
> In C, from the various #defines automatically suppliled by the compiler.
> Elsewhere?  Compile a tiny C program, perhaps.

Those can be done, but it's only half the battle. Userland ABI values
are not as standardized as CPU architectures or OS names. Would GNU
tuples have something we could go on? And GNU and BSD do not always like
each other's identifiers so there may have to be translation :-| Fun times.

> Colon isn't portable because CL.  Dot works, but slash is a whole lot more
> visible.

True. I'll change it to slash in the next draft.

> I meant "uname -a".

Like the current `platform` property, it's almost unparseable. Do you
intend it only for display purposes in logs and bug reports?

As a separate issue, `uname -a` contains the machine name (uname -n)
which is mildly sensitive/personal/organizational information compared
to the other stuff. I deliberately left the username and computer name
out of the spec, though I'm not sure that's the right call.