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

Re: Problems with field initialization: Proposal

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 Thu, 15 Sep 2005, Michael Sperber wrote:


Andre van Tonder <andre@xxxxxxxxxxxxxxxxxxx> writes:


 As an example, the hash-table example could be expressed:

  (define-type hash-table
    (constructor (k) (lambda (pred hasher size)
                       (k 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 (k) (lambda (pred hasher size)
                       (k pred
                          hasher
                          size
                          0)))
    (fields (gc-count mutable)))


I'm confused about the K argument in the EQ-HASH-TABLE example.  Does
it call the primitive constructor of the underlying record type, or
the construction procedure of the supertype?  If the former, there's
one argument missing.  (And I'd ask how I could reuse the construction
procedure of the supertype.)  If the latter, what's it's return value,
and how do I transform it into an instance of the subtype?
I meant the latter, but I realize now that it would involve an unnecessary allocation and copy of a supertype instance as an intermediate step, which is probably unacceptable. 

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.
In the above, the subtype constructor would call the procedure provided for the supertype with the first three values, which returns four values used to populate the first four fields of the subtype instance. The 5th field is then populated with the last value 0.
This suggestion cannot absorb INIT!, though, as the previous suggestion, so INIT! would still need to be separate. 

Cheers
Andre