This is the mail archive of the 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

Per Bothner <> writes:

<sounds of Julie Brown>
MOP fight tonite, doobee do wop, doobee do wop, do wop!

> I have no CLOS experience.  But I won't let that stop me from
> expressing my opinion ...

> * The method precedence order is arbitrary, and (supposedly) "wrong".

Poo poo! It's pretty straightfoward, haha, with the most complex part
being the class precedence topological sort for determining the
specificity of parameter specializers to determine the most specific
applicable method for a given qualifier via a simple left to right
comparison of the congruent lambda lists of each method with the
presence of a parameter specializers named (eql <object>) trumping
everything else.  This is assuming that you are using the standard
argument precedence order for that generic function.  The applicable
methods are then applied according to the specified method combination
for the generic function.

<catch breath>

It's 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

> * I'm not convinced that multi-methods are worth it.  They are more
> difficult to implement efficiently, they make it more difficult to
> figure out what is going on, they remove the modularity advantage
> that conventional object-oriented languages have (that methods are
> associated with their classes).

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.  I don't see how they make things
more difficult, a left to right comparison just doesn't seem that
complex and convoluted to figure out.  As far as methods being
associated with their class, that's not because we have multi-methods,
that's because we have "generic functions".  It's not hard to put your
methods and classes together in a package anyways.

I personally see multi-methods as a requirement for a scheme object

> * I'm concerned that efficient compilation and static analysis
> seem to be difficult.

Indeed.  CLOS is not exactly a compiler optimization geeks wet dream.
But then again, it's not meant to be static by design, so you really
can't blame it.

I would like to see a sheme object system retain most, if not all of
the dynamicism of CLOS tho, but with a simplified and reduced MOP.  I
really find tiny-clos to be a good example of what I want in a scheme
object system, with a few macros wrapped around it, an optimized
implementation, better integration with the usual type system, and
maybe a slightly more flexible method combination mechanism, it would