Hi all,
Mikael has mentioned on a number of occasions that GOOPS has some
unfinished pieces. I couldn't find any information on this in the
workbook, so I decided to write down a summary of the things that I've
seen. Please add to this list if you know of more things, or if I am
mistaken or miss something fundamental.
I'll be poking at some of these over time, but any help is appreciated!
incompleteness
* Slot access compilation in compute-getter-method /
compute-setter-method assumes that slots are SCM objects, whereas if
they are implemented as subclasses of foreign-slot they are raw
machine words.
* Generic application only works for instances of generic, or for
instances of a couple of other specially blessed classes. This is
because for these classes, the C code knows how the objects will be
laid out in memory, and can access memory directly instead of using
slot-ref. In general in GOOPS (and in MOPs in general) there is a
tension between extensibility and efficiency; the former is expressed
in protocols of generic functions, and the latter in invariants and
possibilities for direct memory access.
The evaluator really needs to be able to do direct memory access, if
possible. So for that reason the existing bits of generic function
dispatch that are wired into eval.c check instances of those blessed
clases, via checks like (SCM_OBJ_CLASS_FLAGS (proc)
SCM_CLASSF_PURE_GENERIC).
This direct memory access also has repercussions in tail recursion;
that if the code to dispatch a method can't bottom out in eval.c, we
lose tail recursion.
So, we need to add support for instances of subclasses of generic,
without losing efficiency. Apparently there is some code for this, see
goops.scm:apply-generic.
* We have no :before or :after methods. I don't know if STKlos had these
either.
* GOOPS should define a with-accessors macro.
cruft
* define-method, if it finds that a variable is defined with its generic
name, then verifies that the value is not #f, with the note *fixme*
Temporary hack for the current module system. This appears to be
completely unnecessary.
* use of the (apply append (map ...)) idiom instead of mapappend or the
like in a few places
* objects.[ch] seems to be an unnecessary abstraction, now that GOOPS is
in the core. It purports to define procedures that deal in classes,
metaclasses, generics, etc., but in fact very little of this code is
used, AFAICT.
documentation
* What is an extended-generic ? Seems to have to do with the module
system's generics merging foo.
* What is an operator ? What is the goal of set-object-procedure! ?
* GOOPS reference should be folded into Guile's reference, as it is now
part of Guile.
* A description of the method dispatch process, including the
optimizations, would be really, really helpful. The interfaces that a
MOP provides are carefully coded around potential optimizations that
are not expressed in the specification, and not immediately obvious
(to me). So some understanding of this negative specification would
really help when hacking on this code.
* Possibly the worst section of Guile's manual:
5.15 Objects
-- Scheme Procedure: entity? obj
-- C Function: scm_entity_p (obj)
Return `#t' if OBJ is an entity.
-- Scheme Procedure: operator? obj
-- C Function: scm_operator_p (obj)
Return `#t' if OBJ is an operator.
-- Scheme Procedure: set-object-procedure! obj proc
-- C Function: scm_set_object_procedure_x (obj, proc)
Set the object procedure of OBJ to PROC. OBJ must be either an
entity or an operator.
-- Scheme Procedure: make-class-object metaclass layout
-- C Function: scm_make_class_object (metaclass, layout)
Create a new class object of class METACLASS, with the slot layout
specified by LAYOUT.
-- Scheme Procedure: make-subclass-object class layout
-- C Function: scm_make_subclass_object (class, layout)
Create a subclass object of CLASS, with the slot layout specified
by LAYOUT.
optimization possibilities
* mutation of the method cache causes a full copy of the cache, so that
it doesn't disturb other threads -- we should look to see what e.g.
CLOS does about this
* method cache code could be rewritten in C (dispatch.scm), although I
have never had a problem with it -- it doesn't show up on my profiles.
nastiness
* method compilation (e.g. the process of going from a define-method to
a procedure -- basically, making sure that next-method does the right
thing) is hacky, involving manual manipulation of the data structure
describing the procedure's environment, calling procedure-source, etc.
Also, the procedure-source call means that you can't make a subr
implement a method. I do not understand the comment in compile.scm
about next-method inlining -- what does this mean?
(Why isn't compile-method run at macro-expansion (e.g. define-method)
time?)
* GOOPS mucks around too
