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.
Andre van Tonder <andre@xxxxxxxxxxxxxxxxx> 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