(import (srfi 176))
(version-alist) ; returns the whole merged alist as in the examples
Just so.
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.
Sure.
Your
SRFI 112 (Environment Inquiry) also has the very basics (name/version).
I'd like to withdraw that one in favor of this one.
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?)
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.
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.
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.
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....
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.
\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.
Fair enough. But still, flush multi-line lists. A LOSE line begins with ( and ends with ), period.
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.
In C, from the various #defines automatically suppliled by the compiler. Elsewhere? Compile a tiny C program, perhaps.
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?
Colon isn't portable because CL. Dot works, but slash is a whole lot more visible.
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.
I meant "uname -a".
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgWe are lost, lost. No name, no business, no Precious, nothing. Only empty.
Only hungry: yes, we are hungry. A few little fishes, nassty bony little
fishes, for a poor creature, and they say death. So wise they are; so just,
so very just. --Gollum