[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Translator



    Date: Sat, 15 Sep 90 11:14 EDT
    From: Kalman Reti <Reti@WESER.sreti.symbolics.com>

	Date: Fri, 14 Sep 90 21:22 EDT
	From: barmar@Think.COM (Barry Margolin)

	    Date: Fri, 14 Sep 90 20:20 EDT
	    From: RWK@fuji.ila.com (Robert W. Kerns)

	    APPLY does not use hash tables.  However, for maximum speed and
	    minimum paging, you should pass actual functions, and not
	    symbols, to apply.  I.e

	    (setf (gethash name *name->function-table*) #'rewrite-function)
	    not
	    (setf (gethash name *name->function-table*) 'rewrite-function)

	However, you should note that this mechanism can be a pain during
	development.  If you redefine REWRITE-FUNCTION after storing the
	function in the table the first way, you will continue to call the old
	definition when you extract it, while the second form will cause the
	current function binding of the symbol always to be used.
That's why I usually write defining forms which do something like
this:

(defmacro define-rewrite (name arglist &body body)
  (let ((rewrite-fun (gensymbol name "-REWRITE")))
    `(progn (defun ,rewrite-fun ,arglist ,@body)
	    (add-rewrite-fun ',name #',rewrite-fun))))

This way, changing the function definition and updating
the table are always done together, and you avoid the
problem.

If one function gets used for many names, you can modify
the defining form to define the many names at once.

However, this isn't ALWAYS convenient, so...

	I campaigned (and won) for automatic coercion of symbols to functions by
	APPLY, FUNCALL, etc. in X3J13 for precisely this reason.  I've seen
	users burned many times when they store a function in a data structure,
	load a patch file that fixes a bug in the function, yet the bug still
	appears.

so if it's not convenient, I recommend using the symbol
during development, and then switching to using the
function during actual usage.  However, I almost never
need to resort to this.

    An intermediate strategy is to store the location of the function cell
    (LOCF #'rewrite-function) and then use LOCATION-CONTENTS in conjunction with
    the APPLY or FUNCALL.  This will get the new definition when a redefinition
    occurs, but will avoid the paging overhead of having to reference the symbol
    (which is likely to be far away from the function cell).

This still adds significant paging overhead unless the function cell
is co-located with the function, which is the case sometimes with
Genera and sometimes not.  (I couldn't give the current criteria).

	I also applaud Genera 8.0's enhancement to the printed representation of
	functions: a function object that isn't the current binding of its name
	symbol has "(Superceded)" in the printed rep.
    I hope, it has "(Superseded)" which is the correct spelling.  ;->  (I just checked,
    it does.)
Yes, this is a big win!