From: John Williams
Subject: Symbol Properties or Generic Functions
Date: 
Message-ID: <87isyvcp0s.fsf@heisenberg.aston.ac.uk>
I would like advice on what others with more experience consider good
practice in terms of associating specific processing functions to
symbols. 

A common example is that I want, for example when mapping an
s-expression to html, to associate some processing with different
symboles in the s-expression. It seems to me that I can do this in two
ways - either storing the processing function in a symbol property and
having subsequent processing functions look that property up or I can
use a generic function, with methods specialising on the specific
symbol using EQL.

Which of these approaches is generally considered better LISP? It
seems to me that the generic function approach is somehow cleaner code
and does allow the use of method combinations to add to the
functionality in interesting ways. However would it become less
efficient if there were a large number of symbols (for some currently
undefined value of large) compared with looking up a symbol property?

-- 
John Williams   
	

From: Rob Warnock
Subject: Re: Symbol Properties or Generic Functions
Date: 
Message-ID: <iVSdnWxQDM5KLUWgXTWcpA@giganews.com>
John Williams  <··············@aston.ac.uk> wrote:
+---------------
| A common example is that I want, for example when mapping an
| s-expression to html, to associate some processing with different
| symboles in the s-expression. It seems to me that I can do this in two
| ways - either storing the processing function in a symbol property and
| having subsequent processing functions look that property up or I can
| use a generic function, with methods specialising on the specific
| symbol using EQL.
+---------------

A third way: Use an explicit hash table (keyed on the symbols) which
contains the processing information. That way you neither pollute the
property lists of the symbols (which can become a performance issue if
the number of properties per symbol gets large) nor twitch any performance
issues (if any) with your CLOS's implementation of EQL specialization.
The values in the hash table could be simply functions, which makes the
tree walk *really* simple!

	(let* ((tag (car sexpr))	; simple case only
	       (proc (gethash tag *html-proc-table*)))
	  (if proc
	    (funcall proc tag sexpr))
	    (error 'html-bad-tag tag sexpr))

Note that this can be an EQ hash table.


-Rob

-----
Rob Warnock, PP-ASEL-IA		<····@rpw3.org>
627 26th Avenue			<URL:http://www.rpw3.org/>
San Mateo, CA 94403		(650)572-2607
From: Joe Marshall
Subject: Re: Symbol Properties or Generic Functions
Date: 
Message-ID: <adk6pws3.fsf@ccs.neu.edu>
John Williams <··············@aston.ac.uk> writes:

> I would like advice on what others with more experience consider good
> practice in terms of associating specific processing functions to
> symbols. 
> 
> A common example is that I want, for example when mapping an
> s-expression to html, to associate some processing with different
> symboles in the s-expression. It seems to me that I can do this in two
> ways - either storing the processing function in a symbol property and
> having subsequent processing functions look that property up or I can
> use a generic function, with methods specialising on the specific
> symbol using EQL.

There is a third way:  evaluate the s-expression.  The lisp form DEFUN
is used to `associate some processing with symbols in an
s-expression'.  If you do it right, you can even compile it.
From: Bruce Hoult
Subject: Re: Symbol Properties or Generic Functions
Date: 
Message-ID: <bruce-C1DEFC.21284718112002@copper.ipg.tsnz.net>
In article <··············@heisenberg.aston.ac.uk>,
 John Williams <··············@aston.ac.uk> wrote:

> It seems to me that the generic function approach is somehow cleaner 
> code and does allow the use of method combinations to add to the 
> functionality in interesting ways. However would it become less 
> efficient if there were a large number of symbols (for some currently 
> undefined value of large) compared with looking up a symbol property?

If the S-expression containing the html is known only at runtime then 
the two approaches should have much the same speed -- symbol lookup will 
use a hash table, and so will well-implemented singleton dispatch.

Of course, your implementation might not have well-implemented singleton 
dispatch so YMMV.

-- Bruce
From: John Williams
Subject: Re: Symbol Properties or Generic Functions
Date: 
Message-ID: <87y97ngxng.fsf@heisenberg.aston.ac.uk>
Thank you all for your input on this matter. I did a little test
comparison using CMUCL and found that using method dispatch was about
60% slower than either using properties or an EQ hash table. Obviously the
property solution doesn't scale if you have a large number of properties. 

Having considered the problem some more I think method dispatch and
method combinations is extremely powerful and flexible and that these
advantages are likely to outweight the speed issues. Perhaps the
correct solution is to use a macro to hide this as an implementation
detail.


>>>>> "John" == John Williams <··············@aston.ac.uk> writes:

    John> I would like advice on what others with more experience
    John> consider good practice in terms of associating specific
    John> processing functions to symbols.

    John> A common example is that I want, for example when mapping an
    John> s-expression to html, to associate some processing with
    John> different symboles in the s-expression. It seems to me that
    John> I can do this in two ways - either storing the processing
    John> function in a symbol property and having subsequent
    John> processing functions look that property up or I can use a
    John> generic function, with methods specialising on the specific
    John> symbol using EQL.

    John> Which of these approaches is generally considered better
    John> LISP? It seems to me that the generic function approach is
    John> somehow cleaner code and does allow the use of method
    John> combinations to add to the functionality in interesting
    John> ways. However would it become less efficient if there were a
    John> large number of symbols (for some currently undefined value
    John> of large) compared with looking up a symbol property?

    John> -- John Williams
	

-- 
Dr. John A.R. Williams    | http://www.aston.ac.uk/~willijar
Photonics Research Group  | http://www.ee.aston.ac.uk/research/photonics
Electronic Engineering    | http://www.ee.aston.ac.uk/
Aston University          | http://www.aston.ac.uk