Re: First look at new g-wrap -- it's slow!

[Andy Wingo]

On Wed, 2004-05-12 at 09:31, Andy Wingo wrote:
> I took a first look at the new g-wrap. Yes I know I've been a bit
> derelict. Oh well. Here are my thoughts and concerns.

I think the "Send" button in my mail client makes me think less before
and more after ;)

Regarding the class methods issue. To summarize: We want to generate
code that depends on what type of value we are wrapping. The method
being used to do this now is to pass the type object to the codegen
routines. The value has a type associated with it already, via a slot.
But the value is logically an instance of the type! If you could make it
so that types are subclasses of generic values, you could do away with a
lot of the bookkeeping (and emulation of class methods). For example, I
think the "type" generic could be done away with completely, and
replaced by class-of where necessary. Manually dispatching on type is
not the best OO practice, though -- it should be the methods that
dispatch on type. So I would look hard at any place where you call
`type' on an object. If it seems necessary, perhaps your class hierarchy
is in need of change.

So, proposed hierarchy changes. Imagine a function that you wrap as:
    (wrap-function!
      ws
      #:name 'join_strings
      #:returns '(mchars caller-owned)
      #:c-name "join_strings"
      #:arguments '(((mchars caller-owned) a) ((mchars caller-owned) b))
      #:description "Return a string consisting of a followed by b.")

When this procedure is called, it will store information about the
return type (henceforth `R') as (make mchars #:options '(caller-owned)).
Consider the (proposed) hierarchy of R:
         <gw-type>
             |
mchars - <gw-value>
   |
   R

meaning <gw-type> is the metaclass of <gw-value>, and <gw-value> is the
direct super of mchars. Later, when you go to make the code, you will
have to (slot-set! R 'var ...) and also for 'wrapped-var.

Then to generate the code that takes the c value and makes the scm
value, you just have to call (wrap-value-cg R status-var). The type is
implicit in the R's hierarchy; specifically, R is an instance of mchars.
This also allows you to do away with typespecs. A simple options slot on
<gw-value> will do. This simplifies type definition as well:

(define-class mchars (<gw-value>))

Maybe it should be <mchars> or <gw-mchars>, and maybe mchars should be
the one to define #:options (so that <gw-value> could throw an error if
options are not expected). Dunno.

Regarding the dual-namespace issue: The set of dependencies for a
wrapset is known when the wrapset is derived. Why not just make
#:dependencies take a kwarg, like

 (define-class <miscutils-wrapset> (<gw-guile-wrapset>)
    #:dependencies (list <gw-standard-wrapset>))

Takes care of depends-on! and the dual namespaces in one step. No more
registry. Or if you don't like lists or quasi-quote you could do it like
define-module does, with `#:use-wrapset <foo> #:use-wrapset <bar>' or
something.

What do you think?
-- 
Andy Wingo <address@hidden>