[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
- Subject: Re: Comments
- From: NGALL@BBNG.ARPA
- Date: Mon, 23 Dec 1985 14:51:00 -0000
- Cc: common-lisp@SU-AI.ARPA
- In-reply-to: The message of Sun, 22 Dec 85 17:15 EST from MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
- Sender: NGALL@BBNG.ARPA
Date: Sun, 22 Dec 85 17:15 EST
I think the discussion about whether there should be an XOR
function is very much off the mark. I think the criterion for
including any new operator in the language should be one of
1) It is not possible to write it in Common Lisp.
2) It can be implemented MUCH more
efficiently in an implemention dependant way.
3) It requires a lot of programming effort (and is generally useful).
As long as an operator is implementable in Common Lisp, your program
would still be portable.
The only problem that could arise is that your function/macro
is called something that later on becomes defined in Common Lisp, with
different syntax/semantics. But that problem exists with ANY operator
that you define, and packages can deal with it. Thus I see no reason
to include something like XOR. The language is certainly big enough
I would change criterion (3) to
3) It is generally useful and without it, ugly (i.e., opaque) idioms
must be used.
Since (I believe) the point is whether or not "everyone" is going to
implement it anyway, given that it is so useful. If they are, it
should be standardized, regardless of the implementation effort. So,
to me, the question concerning XOR is, will "everyone" use it? Since
I have NEVER been aware of the need for such a construct, I would vote NO.
I recall someone has already asked for the inclusion of the
function MACROEXPAND-ALL. If this hasn't been accepted, I second
the motion on the grounds of criterion 3 above (It requires knowledge
I agree (on the grounds of my revised critterion 3).
I would also like to suggest the addition of the predicate
FILE-STREAM-P, which if true, would return the file pathname.
On the grounds of what criteria?
On the basis of being implementation dependant (criterion 1), I suggest
three more functions:
FUNCTION-ARGLIST, MACRO-ARGLIST, and FUNCTION-NAME.
These should work for system functions as well as user defined ones.
And for all kinds of functions - closures, compiled, interpreted.
I heartily agree (at least about the first one)! I'm desperate for
such right now! I'm writing a profile module now and I'm "advising"
data collection calls around functions. And to make the advising
function as fast as possible I'd like it to have an "equivalent"
For example, currently, I'm forced to write something like:
`(lambda (&rest arglist)
(apply ',original-function arglist)
which is SLOW (in most (?) implementations) due to both the use of
&REST and the use of APPLY.
If I could get the number of req. and opt. args and an indication of
whether or not a &rest arg (implicit or not) is required, I could
write something like the following:
(multiple-value-bind (req-args-count opt-args-count restp)
(if (not restp)
(let ((req-args '())
(dotimes (i req-args-count) (push (gensym) req-args))
(dotimes (i opt-args-count) (push (gensym) opt-args))
`(lambda (,@req-args &optional ,@opt-args)
(declare (inline ,original-function))
`(,original-function ,@req-args &optional ,@opt-args)
<code for the APPLY case (see above)>))
The above code if oversimplified. It assumes that the optional
parameters of the original-function all default to NIL and don't
contain <svar>s. But I hope you get the point.
Thus I recommend a function named PARAMETER-INFO that takes an
arg. of type (SATISFIES FUNCTIONP) and returns three values: the
number of required parameters (an integer), the number of optional
parameters (an integer), and either T or NIL depending on whether any
&REST or &KEYWORD parameters appear in the lambda-list. I believe
this information is retained (in all (?) implementations) even by
P.S. Does anyone know how I could get such info about a compiled
function definition in VaxLisp?!