* Replace compute-get-n-set

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

  The following would be necessary to remove overhead for matrix
  setting in (math matrix):

  8. (setter proc) --> proc
  9. (proc exp1 ...) --> proc body if body uses formals once or
exp1 ... are atomic

  NOTE: Use slot types if present.

  10. Mark values as newly created/input.  (A function is functional
      also if it sets a newly created value.)  Mark procedures as
      functional/imperative.  Call functional procedures at compile
      time if their value is a constant.

* scm_slot_SCM in C interfac (make sure that the right mark in the
  layout is set)

* Beware of the next-method dispatch problem!

* with-slots, with-accessors

* Update mop.text

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