* Method compilation:

  0. expand macros!
  1. accessors --> @slot-ref|set! | proc call
  2. gf --> code-entry | dispatcher
  3. apply gf --> code-entry | dispatcher
  4. next-method call --> code
  5. next-method reference --> add next-method let

  6. with-slots: slot reference --> @slot-ref|set! | proc call
  7. with-accessord: accessor ref --> -- " --

  NOTE: Use slot types if present.

* Beware of the next-method dispatch problem!

* with-slots, with-accessors

* Update mop.text

* Read and correct documentation.

* Optimizations

** Remove assumptions of single-symbol slot definitions from goops.c.

** Implement top-sort and compute-std-cpl in C, use this during
   bootstrapping and remove Scheme version of compute-std-cpl in
   goops.scm.

** Don't call intern repeatedly in goops.c (see e.g. CALL_GF).

*** Don't forget to invalidate generic function caches
when classes are redefined

MDJ 990821 <djurfeldt@nada.kth.se> Why should we do this?

** Strategy for optimization of the MOP

Terminology: Let subprotocol F mean a series of generic function calls
that starts with a call to generic function F in the MOP.

Ex: The apply-generic is a subprotocol that includes
compute-applicable-methods and sort-applicable-methods.

It is possible to have a fairly extensive MOP and yet have an
efficient implementation for the standard case.

Currently, this is the case with the apply-generic protocol: The class
<generic> has the flag SCM_CLASSF_PURE_GENERIC set.  Instances of this
class follow an efficient C level implementation of the apply-generic
protocol, but instances to subclasses of <generic> use the Scheme
level protocol.

Here is a proposal for a different strategy to achieve the same goal:

Let generic functions belonging to a certain subprotocol be instances
to a subclass <SUBPROTOCOL-generic> of <generic>.  The idea is that
the optimized version of the MOP will be used on instances to all
classes which are "pure" with respect the protocol.  The purity is an
inherited property.

But, if the user specializes a function M which is an instance of
<SUBPROTOCOL-generic> to C, C will no longer be "pure".

Example: Let C be a subclass to <generic>.  Normally a function F
which is an instance of C will be applied using the optimized
apply-generic protocol.  But, if the user specializes
compute-applicable-methods to C, C will no longer be "pure" => F will
be applied using the full MOP.

More concretely, we could allocate an inherited class flag which tells
that a GF belongs to SUBPROTOCOL.  There is also a class flag which
tells that a CLASS is "pure" with respect to SUBPROTOCOL.

When the user specializes a function F to a class C, add-method! will
clear the purity flag of C if F has the SUBPROTOCOL flag set.

This could for example be done by always calling a magic function

  %touch F C

when specializing F to C in the first argument.

It is also necessary to pay attention to the positions of slots so
that instances of "pure" classes have slots on the positions where the
optimized protocols expect to find them.

* MOP

** Clean up the MOP with respect to recent changes

** Make no-applicable-method CLOS-like (args)
