Christian Stigen Larsen scripsit:

> I think you should add example return values for the (c-memory-model)
> procedure.  The ones in R7RS, appendix B, should do: ilp32, lp64, ilp64,
> etc.

Remember that this is primarily a reporting/logging API, so there's no
reason to standardize what it outputs.  If you want to conditionalize your
code on the C memory model, you should be using `cond-expand`.

> Not a big deal, but is "memory model" the correct term to use?  It looks
> like the terms (64-bit) "data model" and "programming model" are more common
> and give better web searches.

All these terms are heavily overloaded.

> I would also like to know what you think about more types of queries.  Why
> not include some single-valued stuff from the sysconf, sysctl, /proc and
> /sys facilities on Linux/BSD systems?

Well, sysconf is a Posix standard, and I'll look at that.  But there is
nothing standardized about /proc or /sys (sysctl just retrieves stuff in
the /proc/sys directory) and there are literally thousands of entries.
On my 32-bit Linux system, /proc and /sys, even excluding the transient
/proc/<pid> and /proc/self subtrees, have almost 4500 files.  This is the
large language, but not the enormous language!

> E.g., on a multi-threaded implementation I'd like to know how many CPU cores
> I've got to distribute my workload on.

Alas, that does not seem to be a standardized sysconf variable.

> There are many things that would be great to know that are quite trivial to
> get on most systems.  I could make a list of suggestions, if anyone are
> interested.

Please do.  Don't forget to take Windows into account.

>
> I've implemented SRFI-112 in Mickey:
> https://github.com/cslarsen/mickey-scheme/blob/master/lib/srfi/srfi-112.scm

Great!

--
All Gaul is divided into three parts: the part          John Cowan
that cooks with lard and goose fat, the part            http://ccil.org/~cowan
that cooks with olive oil, and the part that            xxxxxx@ccil.org
cooks with butter. --David Chessler