Translator

[Reti@Riverside.scrc.symbolics.com]

    Date: Sat, 15 Sep 90 14:41 EDT
    From: RWK@fuji.ila.com (Robert W. Kerns)

	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).
Isn't this generally true in modern releases of Genera?  I thought that's what
the 'optimize functions' phase of disk-save did.  Clearly, my advice was predicated
on my belief that this was true.

	    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!