This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: setf.scm


Craig Brozefsky <craig@onshore.com> writes:
> [CLOS's method precedence order is] not arbitary, and I don't see where
> it is wrong.  But I would hesitate to implement it in it's full glory for
> a scheme object system.

By arbitrary I mean that while there is a rule to chose the specific
method, whether it is the "most specific" or "most appropriate" rule
is not something necessarily obvious.  By "wrong" I mean
having read some paper discussing method precedence order.  Now
I don't remember if the paper was about CLOS or Dylan, but I do
remember the paper proposing better rules.  Of course there is
nothing wrong with learning from recent reseach to design a
CLOS-style system but improving on it - if you like CLOS-style
sytems.

> Well, given that it's not uncommon for someone to attempt to abstract
> a process which has dependencies on the types of two or more or it's
> operands, the language might as well support it rather than make
> everyone make their own version.

Consider the one of the classic motivations:  Drawing different kinds of
objects of different kinds of displays/printers.  This is only interesting
if it is extensible in both dimensions:  One can add new graphics objects
as well as new display types.  Now suppose I want to draw something
for with there is no exact match.  Do I go up the hierarchy looking
for the closest matching picture or for the closest matching display
type?  You have to define the rules for what methods somebody has
to add when they add a new display, as well as what methods someone
has to add when they add a new picture type.  My feeling is that
using single dispatch makes it easier to structure and enforce this
structure.  I could be wrong; I really would like to see a paper
discussing the pragmatics and extensibility issues of using
multi-methods to solve a problem like this.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner