[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GOOPS todo

From: Andy Wingo
Subject: GOOPS todo
Date: Sat, 19 Apr 2008 19:02:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

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!


* 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) &

  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

* We have no :before or :after methods. I don't know if STKlos had these

* GOOPS should define a with-accessors macro.


* 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.


* 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.


* 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)

* GOOPS mucks around too much with the module system. Instead of having
  define-class expand out to a (begin ..) block in which getters,
  setters, and the class are all defined separately, (define-class <foo>
  () (bar #:getter bar)) actually mucks with the module system to define
  the `bar' getter generic.

  Similarly, if a getter was already defined but not a generic, GOOPS
  actually modifies that binding, replacing the original definition with
  the result of calling ensure-generic, potentially modifying imported

* GOOPS uses procedure->memoizing-macro instead of define-macro.

* Relatedly, define-class is only allowed at the top level. There is no
  reason for this, if the module system mucking is fixed to use normal
  macro expansion with the `begin' splice.

* Classes store a pointer to their environment, for no reason.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]