[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problems with field initialization: Proposal



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