[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposals 1 - 4
- To: cl-technical@SU-AI.ARPA
- Subject: Proposals 1 - 4
- From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
- Date: Mon, 21 Jul 1986 09:54 EDT
- Sender: FAHLMAN@C.CS.CMU.EDU
Just in case you don't want to fetch the proposal file, here are
proposals 1 - 4 with my recommendations.
---------------------------------------------------------------------------
Proposal #1: Error signalling (7/21/86)
This is a proposed change, upward compatible from the user's
point of view:
Create three levels of errors: Class 1 errors must be deteced and
signalled by any legal implementation. Class 2 errors must normally be
detected and signalled, but implementations may choose to omit the error
testing and signalling in code compiled with an OPTIMIZE SAFETY value of
0 or 1; in this case, the behavior if the error occurs is unpredictable,
and perhaps fatal to the Lisp. Class 3 errors are considered to be
errors, but it is left to the discretion of the implementor whether and
under what conditions Class 3 errors are detected and signalled.
There will be a usage note indicating that portable code should not
depend for correct operation on Class 2 errors being signalled, since
under some conditions of compilation they will not be.
Note: CLtL has classes corresponding to Class 1 ("signals an error") and
Class 3 ("is an error"). We intend to propose that certain errors,
including wrong number of arguments to a function, array references out
of bounds, and certain wrong-type errors, be moved from Class 3 to Class
2. However, such proposals will be discussed individually, after an
error system has been adopted. The decision at this point is whether we
should use the three-level error system as the working assumption in
future discussions.
[I (sef) favor this, but suggest that we change "OPTIMIZE SAFETY value
of 0 or 1" to read "OPTIMIZE SAFETY value of 0". It was pointed out
that the default SAFETY is 1, and checking should be required unless the
user specifies otherwise.]
---------------------------------------------------------------------------
Proposal #2: Argument List Information (7/21/86)
Proposed Extension:
(FUNCTION-PARAMETERS <function>)
Takes one argument which must be a function, not a macro or special
form.
Returns the following six values:
1. Number of required parameters in the function's lambda list.
2. Number of optional parameters in the function's lambda list.
3. T if the function's lambda list contains the &REST lambda-keyword;
NIL otherwise.
4. T if the function's lambda list contains the &KEY lambda-keyword;
NIL otherwise.
5. A list of all keywords accepted by the function, in arbitrary order.
This list may be pre-stored, so it should not be destructively
modified by the user.
6. T if the function's lambda list contains the &ALLOW-OTHER-KEYS
lambda-keyword; NIL otherwise.
If return value 4 is NIL, 5 and 6 must also be NIL.
[I (sef) favor this.]
---------------------------------------------------------------------------
Proposal #3: Argument List Information (7/21/86)
Two alternatives to choose from:
#3A:
Proposed extension:
FUNCTION-PARAMETER-RANGE (function)
The argument must be a function, not a macro or special form. Returns
two values, the minimum legal number of arguments and the maximum legal
number of arguments. If the function's argument list contains &rest or
&key, the second return value is NIL, meaning that there is no maximum
number of arguments.
- OR -
#3B:
Modification to proposal #2:
Add an implementation note to FUNCTION-PARAMETER recommending that
implementations detect calls that will not use the 5th value, and that
they compile such calls in a way that will not cons up a keyword list.
[I (sef) favor 3A, but could happily live with 3B.]
---------------------------------------------------------------------------
Proposal #4: Argument Name Information (7/21/86)
Proposed extension:
(FUNCTION-PARAMETER-NAMES <function>)
Takes one argument which must be a function, not a macro or special
form.
This function returns the names of the parameters to a function, as
specified in the argument list, if such information is available. An
implementation may choose to provide this information for all functions,
only for some, or for none. The final return value specifies whether
the information is in fact available. If this is NIL, the other return
values will also be NIL.
Returns four values:
1. A list containing the symbols naming the required parameters, in order.
2. A list containing the symbols naming the optional parameters, in order.
3. A symbol naming the rest parameter, if any.
4. T if the information returned by this function is valid; NIL otherwise.
Note: This function is included primarily for the convenience of users and to
provide a uniform interface for portable debugging tools.
[I (sef) oppose this. After a period of discussion the community was
unable to agree on the format for returning this information, and there
is no compelling reason to standardize this.]
---------------------------------------------------------------------------