Re: (more) problems with (STATUS FEATURES)

[Kent M. Pitman <KMP at MIT-MC>]

I would like to see a (STATUS DIALECT) introduced (or some similar function,
if people don't like STATUS, then (LISP-DIALECT) would do, I guess) so that
we could do

	(CASEQ (STATUS DIALECT)
	   ((MACLISP) ...)
	   ((LISPM) ...)
	   ((NIL) ...)
	   ((INTERLISP) ...)
	   ((FRANZ) ...)
	   ((IBMLISP) ...)
	   ((LISP1/.5) ...)
	   (T ...))

instead of 

	(COND ((STATUS FEATURE MACLISP) ...)
	      ((STATUS FEATURE LISPM) ...) 
	      ...)

since some of the FEATURE things are already ambiguous. Eg, (STATUS LISPM)
doesn't supply information to the reader about whether the reason for
conditionalizing was one of Operating System, Hardware Configuration, or
Dialect. I think there should be a way of making further distinction so 
that people coming along later can infer information about the intent of
the code they see, instead of the ambiguous coding style that now results.
ie, this is a problem that shows up when you later want to add more 
conditionals to a set of conditionals someone else has written.

Such a change would have to be put into at least LispM, NIL, and Maclisp
to be useful. Does anyone (dis)like this idea? This would help complete fill
out some of the gaps we left when (STATUS FILES) and (STATUS OPSYS) --
or whatever their longer names were -- went in. (STATUS MACHINE) => 
LispM, PDP10, TOPS-20, etc. might also be a useful (subtlely different than
(STATUS OPSYS)) option, as well... 

I don't oppose totally different schemes which people have for handling 
current and target features in a better way. I'm just pointing out that it's
getting painful to understand the semantics of all of the things on the
features list. They really need to start being organized into named slots
as that (STATUS OPSYS), etc. functionality helps to achieve the spirit of,
at least...

-kmp