On 17 May 2013 19:11, John Cowan <xxxxxx@mercury.ccil.org> wrote:
> Is everyone happy with this SRFI as well?

Looks good.  I think it might be worth giving non-normative examples
of output for the various procedures.  This shouldn't be construed as
providing some kind of canonical list of OS types (for instance), but
it's not a lot of use if Rhinoceros Scheme returns "Windows" as a
result of (os-type) and Diplodocus Scheme returns "win32".   Even just
specifying "windows", "linux", "macosx" as potentially valid results
for OS-TYPE will improve the usefulness of the SRFI a lot.  i.e.
there's still scope for implementors to break this convention, but if
they don't need to then so much the better.

For instance, the CPU-ARCHITECTURE can't really be interpreted without
knowing the convention used by the OS.  Knowing likely values for the
OS-TYPE means you can at least base your cond-expand clauses on that.
In strict standard terms, programs that relied on this would have
indeterminate results according to the spec, but that wouldn't stop
them being useful.  For 100% reliable behaviour it would only be safe
to cond-expand based on implementation/version combinations, which is
a nightmare to use.

Providing example output would also increase the usefulness of the
SRFI as a reference for users, for instance I currently have no idea
what a likely result of (c-memory-model) would look like (except that
it can be #f).

> In particular, if anyone knows how to emulate uname() on Windows, I
> could add that information.  Of course, Cygwin knows how, but I don't
> much feel like digging through the Cygwin sources to find out.

http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/uname.cc?rev=1.30.10.1&content-type=text/x-cvsweb-markup&cvsroot=src

So the main call seem to be GetSystemInfo(), and it looks like it uses
GetComputerNameA() elsewhere in the source to get the computer name
(which apparently returns the NetBIOS name)...

--
David Banks  <xxxxxx@gmail.com>