Re: Comments

[NGALL@BBNG.ARPA]

    Date:     Sun, 22 Dec 85 17:15 EST
    From:     MURRAY%umass-cs.csnet@CSNET-RELAY.ARPA
    To:       common-lisp@su-ai.ARPA
    Subject:  Comments
    
    
      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
    the following: 
      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
    already.  

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
    of  special-operators).
    
I agree (on the grounds of my revised critterion 3).

...

    Random Functions:
    
    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"
lambda-list.

For example, currently, I'm forced to write something like:

`(lambda (&rest arglist)
   (start-data-collection)
   (unwind-protect
     (apply ',original-function arglist)
     (stop-data-collection)))

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)
		     (parameter-info original-function)
  (if (not restp)
      (let ((req-args '())
	    (opt-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))
	   (start-data-collection)
	   (unwind-protect
	    `(,original-function ,@req-args &optional ,@opt-args)
	    (stop-data-collection)))) 
      <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
compiled code.

P.S. Does anyone know how I could get such info about a compiled
function definition in VaxLisp?!

-- Nick