Here's a rough sketch of the implementation.

- NSInvocation is used to invoke methods, based on a design suggestion from
  the list, and the design of the Ruby and Gauche bridges.  Advantages:
  does not use libffi, parses arguments and return types for
  you. Disadvantages: NSInvocation has some annoying behavior and also a
  critical flaw.

  - The critical flaw is that NSInvocation cannot send to target 'super'.
    super of course is not the superclass of 'self', but the superclass of
    the class where the executing method is defined.  To hack around this,
    when a method is defined I search for any overridden supermethods and
    define a new selector with prefix 'classname:super:...' pointing to the
    supermethod.  Executing methods are then provided with their classname
    via a closure, and a macro transform can convert a @[super ...] call
    to the appropriate selector.
    
    Using objc_msgSendSuper would obviate this hackery, and it dynamically
    considers the class structure.  (However, the above solution does give
    us exact supermethod signatures, which it seems cannot reliably be
    obtained at runtime.  This is used for correct type conversion.)

- FFI is required for method proxies.  Originally, I passed a function with
  an IMP signature-- (id (*)(id self, SEL _cmd, ...)) -- and used va_args
  to obtain its arguments.  This was unreliable.  Double and float values
  were not passed correctly to va_args, and trying to parse the stack
  directly was not possible.  Return types were also problematic; returning
  a double is impossible through a 4-byte return type, and doing the
  reverse is a crapshoot.  I was forced to use libffi, but it works
  perfectly.  Also, the FFI closures are useful.

  - The Scheme procedure is passed thru the FFI closure.
  - Method return and argument types are passed thru the closure (as strings).
    I tried to use NSMethodSignature, but methodSignatureForSelector: did
    not reliably find our signature, but sometimes that of a supermethod.

- All Objective C invocations are marked as safe: because any one could
  potentially call back into a Scheme class at some arbitrary point.  I
  don't like this, but don't understand enough to implement it better.

- Type conversion is done is Scheme, with many conversions ultimately
  relying on the type conversion performed by foreign-lambda calls.  This
  is easier to understand than my first attempt in pure C, but probably
  slow.  In the end, now that I have dragged in a bunch of pure C functions
  for the FFI type handling, I've cluttered up the source anyway.

- Overall it is just slow.  Not much optimization has been done.

- I like the way Felix had simple calls go through a foreign-lambda instead
  of the lazy-ffi layer.  Before restoring this functionality I need to
  make sure memory management will still work correctly with selectors such
  as alloc.

- Memory management is a topic unto itself and I need to collect my
  thoughts on it.  I am not sure if the current approach will last, as I
  have nagging feelings about certain cases I have not tested.

