Re: make-vtable

[Ludovic Courtès]

Hi!

Kevin Ryde <address@hidden> writes:

>> Thus, VTABLE is redundant.
>
> Well, except for the creation (and continued existance) of
> scm_stack_type.

Right.  But the layout that's used for VTABLE is unneeded: VTABLE only
needs REQUIRED_VTABLE_FIELDS.

> Yes, as long as you don't want any extra fields in the vtable (which
> is true for scm_stack_type).  I thought of that for my make-vtable
> func,
>
>     (define make-vtable
>       (let ((vtable-vtable #f))
>         (lambda (fields tail-size . print)
>           (or vtable-vtable
>               (set! vtable-vtable (make-vtable-vtable "" 0)))
>           (apply make-struct vtable-vtable tail-size
>                  (make-struct-layout fields)
>                  print))))
>
> Then wondered if it was worth bothering with.  I guess if it's used by
> stacks.c too then it should share.  (The name `struct-vtable' is taken
> by a func, but some other global name ...)

I think it'd be useful and easier to understand.  Or maybe something
like:

  (define %root-vtable
    (make-vtable-vtable "" 0))

  (define (make-vtable layout printer)
    ;; LAYOUT must be a symbol.  We only pass a two-element init list
    ;; (corresponding to REQUIRED_VTABLE_FIELDS) because the second
    ;; field is of type `s' and gets automatically initialized.
    (make-struct %root-vtable 0 layout printer))

(And it really works!)

Both of which could (should?) be documented _before_ `make-vtable-vtable'
is even mentioned.  :-)

> I think the problem is if you want extra fields in the vtables.

Actually, one rarely needs it, just like one rarely needs to sub-class
<class>.  So it's a nice thing to have, but not something that should
make one's life harder.

> Maybe
> a third level of table descriptor could do that (as opposed to
> self-vtabling roots).

Because of the `s' field in REQUIRED_VTABLE_FIELDS, all vtables returned
by `make-vtable-vtable' are "self-vtabling".  I think it'd be clearer if
there were only one self-vtabling vtable (`%root-vtable') from which all
vtables would directly or indirectly inherit.  Thus,
REQUIRED_VTABLE_FIELDS would rather be "prprpw".

But I guess this is more of a cosmetic issue.

Thanks,
Ludo'.