Andre van Tonder <xxxxxx@now.het.brown.edu> writes:

> Here is an alternative suggestion:
>
>     (define-type hash-table
>       (constructor (lambda (pred hasher size)
>                      (values pred
>                              hasher
>                              (make-vector (nearest-prime size))
>                              0))
>       (fields (pred   immutable)
>               (hasher immutable)
>               (data   mutable)
>               (count  mutable))))
>
>    (define-type eq-hash-table
>      (parent hash-table)
>      (constructor (lambda (pred hasher size)
>                     (values pred
>                             hasher
>                             size
>                             0)))
>      (fields (gc-count mutable)))
>
> This is a little more concise than my previous suggestion, and presumably
> allocating intermediate VALUES is cheaper than allocating intermediate
> supertype instances.

Ok.  Now, you said that you're doing this partly to improve clarity.
The problem this has is that it's no longer visually apparent which
arguments go into the parent constructor and which one into this
type's.  (And this is exactly the kind of thing I can never remember.)
So for clarity, I prefer the solution that's in the draft (especially
as it smoothly extends into some kind of class notation), but I can
see (dimly :-) ) why someone might prefer yours.

You're also doing this to improve on generality, and there it's clear
you score.  However, there's ways to achieve that within the current
framework.  The question (which we also discussed among the R6RS
committee at some length) is whether it's worth the effort.  The
authors of the SRFI came out on the side that it's not, but some
examples might help convince at least me of the general point.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla