This page is part of the web mail archives of SRFI 76 from before July 7th, 2015. The new archives for SRFI 76 contain all messages, not just those from before July 7th, 2015.
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