[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Environment Query Functions.
- To: email@example.com, common-lisp@SU-AI.ARPA
- Subject: Environment Query Functions.
- From: Christopher Fry <cfry@OZ.AI.MIT.EDU>
- Date: Thu, 1 May 86 04:09 EDT
- In-reply-to: The message of 28 Apr 86 11:36-EDT from "BACH::GREEK" <firstname.lastname@example.org>
I think the watchword is "short and sweet" as far as the environment
query functions are concerned. Here's what we do for VAX LISP.
LISP-IMPLEMENTATION-TYPE is "VAX LISP".
LISP-IMPLEMENTATION-VERSION is something like "V2.0".
MACHINE-TYPE is the machine name, like "DEC VAX 11/780" "DEC VAXstation II".
MACHINE-VERSION is tough to call, so we return the SID register, which
uniquely identifies the CPU. Not so great.
MACHINE-INSTANCE is setable by the system manager/user.
SOFTWARE-TYPE is "VMS" or "ULTRIX".
SOFTWARE-VERSION is whatever the operating system says its version is.
SHORT-SITE-NAME & LONG-SITE-NAME is setable by the system manager/user.
There's a few reasons for these variables:
-to help a user figure out what environment he's in
-to help a program ...
Generally programs care that certain values that ought to be the
same are identical, and certain things that ought to be unique
An example of "the same" is, if 2 different lisps both run on
a VAX 780, then they ought to have identical values for MACHINE-TYPE.
An example of difficulty with cases for uniqueness might come
in the SHORT-SITE-NAME for a
site in Paris, France and Paris, Texas.
[They BOTH might decide to use "ROME Air Force" ! ]
The world is big, and there's lots of hardware/ operating systems
out there, but with a little coordination we could:
Provide reasonable values for these vars that were unique when they need to be
and the same when they need to be.
I propose that a clearinghouse for such names occur at ISI as part of
the validation suite effort.
We need to come up for rules of reasonability for names,
and a mechanism for distributing the Known Nameset
[say every 3 months?] so that people writting portable code
can have at least some chance of doing it right.
Maybe in the process of doing this we'll discover that certain
of the above vars are useless, and/or that a few more should be added.
All the more reason for centralizing the process.