On Fri, 16 Sep 2005, Michael Sperber wrote:

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

It has occurred to me that a simple FIELD-VALUES macro could
translate into the VALUES expression of my suggestion, so you can write:

    (define-type eq-hash-table
      (constructor (lambda (pred hasher size)
                     (field-values (parent-arguments pred
                                                     hasher
                                                     size)
                                   (child-fields 0))))
      (fields (gc-count mutable)))

Would this help satisfy your concern regarding clarity?

One could, if one wanted to, go further by making FIELD-VALUES abstract (i.e.,
keeping the number and order of the return values of FIELD-VALUES abstract).
This would allow extensions such as the following, which overrides the parent
constructor (which I notice the draft does not seem to allow):

    (define-type eq-hash-table
      (constructor (lambda (size)
                     (field-values (parent-fields eq?
                                                  primitive-hasher
                                                  (make-vector (nearest-prime 42))
                                                  0)
                                   (child-fields 0))))
      (fields (gc-count mutable)))

Cheers
Andre