[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: "common-lisp" <common-lisp@su-ai.ARPA>
- Subject: more comments
- From: "BIZET::VANROGGEN" <email@example.com>
- Date: Tue, 17 Dec 1985 15:50:00 -0000
- Cc: vanroggen
- Reply-to: "BIZET::VANROGGEN" <firstname.lastname@example.org>
1 UNDO is too vague.
I suggest something like either
(UNPROCLAIM '(CONSTANT FOO)) or (PROCLAIM '(NOTCONSTANT FOO))
Same for SPECIAL. We'll need a PROCLAIM CONSTANT too.
But wait--what will it mean to make incompatible proclamations?
As is said in [clarification 56,58], redefining a constant is
an error. Then surely making a constant a variable ought to be
at least as dangerous.
This problem is more general than just wanting to be able to "undo"
a definition--we need to decide how to change definitions. For
example, if one first (PROCLAIM '(FTYPE (FUNCTION STRING INTEGER) FOO))
and then (DEFUN FOO (S I) (DECLARE (TYPE SEQUENCE S) (TYPE FIXNUM I))
...), is the DECLARE in error or does it supersede the proclamation,
or does it just shadow the proclamation for the body of the function?
What if later (DEFUN FOO (A B C) (DECLARE (FLOAT A B C)) ...)?
Or if there's a PROCLAIM to that effect?
I hope we can define some reasonable behavior, but I think there will
always be some conflict between "static" proclamations and the "dynamic"
redefinitions done during program development until some notion of
"state" is introduced.
Also, should DEFVAR update the documentation string even when
the variable already had a value and thus didn't get reset?
47 The problem with the idiosyncratic use of &REST in a function type
specifier is that we really need a more general list-type description
without resorting to arbitrary predicates. Although &REST (INTEGER 0)
is a cute idea, I'm mildly opposed.
60 Yes, "an error" to have two parameters be the same symbol. I assume
"same (EQL) name" isn't really meant here, since the following should
be OK: (DEFUN FOO (PACK1:X PACK2:X) ...)
82 XOR seems to be stretching the analogy between control constructs and
logical operations a bit. BTW, there ought to be a mention of EVERY and
SOME in the descriptions of AND and OR if one wants to apply their
107,144 Would life, the language, and everything be simpler if MACROLET
145 I'd prefer (BODY &OPTIONAL DOCP ENV) for PARSE-BODY where DOCP
defaults to NIL.
145 Is it OK to destroy the non-top-level list provided by &REST? Should
this be different for macros than for functions?
158 No, this should be an error only if the types conflict.
161 Should be OK if there are fewer returned values if they still match
the type specified. (I.e., if NIL is TYPEP the given type).
249 Hmmm. For now we can state that circular lists are "an error", just
so the language can be more precisely defined.
307 Also watch out for a slot named "P".
321 EVAL doesn't need an environment arg--what's wrong with the existing
439 I didn't mean that COMPILE had to save the interpreted definition for
COMPILEDP to potentially return. Rather, +if+ COMPILE had saved it,
COMPILEDP would return it and UNCOMPILE would restore it. Also, COMPILEDP
is supposed to work on names and can be true for macros (and special
forms, though that's not relevant), which distinguishes it from
COMPILED-FUNCTION-P. COMPILEDP should be false for a closure over a
compiled function, but COMPILED-FUNCTION-P should be true.