GOOPS todo

GOOPS todo

[Andy Wingo]

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

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


Regards,

Andy
-- 
http://wingolog.org/

Re: GOOPS todo

[Ludovic Courtès]

Hi Andy!

Andy Wingo <wingo@pobox.com> writes:

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

(I realize this answers my previous message on `guile-user'...)

Good to see you have idea on this!  :-)

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

Not sure, but a nice thing to have.

> * GOOPS should define a with-accessors macro.

Actually, I don't like it a lot (probably because I wouldn't mind adding
accessors to the global namespace).  Do other CLOS-like systems have
something similar?

> * GOOPS reference should be folded into Guile's reference, as it is now
>   part of Guile.

Not sure about it since it's quite a large document and it's easier to
search it when it's separate.

> * Possibly the worst section of Guile's manual:

I like this one.  :-)

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

I'd be reluctant to this, as it's already complex enough.

Thanks for this instructing (and entertaining) review!

Ludo'.

Re: GOOPS todo

[Andy Wingo]

Heya Ludovic,

On Thu 24 Apr 2008 00:03, ludo@gnu.org (Ludovic Courtès) writes:

>> * GOOPS should define a with-accessors macro.
>
> Actually, I don't like it a lot (probably because I wouldn't mind adding
> accessors to the global namespace).  Do other CLOS-like systems have
> something similar?

So, I poked around in the archives for a good long while to find this
answer that I knew was there ;-), but here 'tis, in this thread:

http://sources.redhat.com/ml/guile/2000-04/msg00010.html

Marius and Mikael's responses are the interesting ones IMO.

>>> * GOOPS reference should be folded into Guile's reference, as it is now
>>   part of Guile.
>
> Not sure about it since it's quite a large document and it's easier to
> search it when it's separate.

You might be right. On the other hand, STKlos has it inline with its
docs: http://www.stklos.org/Doc/html/index.html. And, it would be more
clear at answering the question, "how do I do OO with Guile?". It would
be a lot of work. But I disagree regarding the searchability argument,
the names and indices don't overlap all that much.

Cheers,

Andy
-- 
http://wingolog.org/