On Fri, 16 Sep 2005, Michael Sperber wrote:

> Andre van Tonder <xxxxxx@now.het.brown.edu> writes:
>
>> Here is an alternative suggestion:
>>
>>    (define-type eq-hash-table
>>      (parent hash-table)
>>      (constructor (lambda (pred hasher size)
>>                     (values pred
>>                             hasher
>>                             size
>>                             0)))
>>      (fields (gc-count mutable)))
>
> 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.

Well, you just count from right to left.  You could make it apparent by simply
having a comment:

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

or you could use LIST for the parent arguments:

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

> So for clarity, I prefer the solution that's in the draft (especially
> as it smoothly extends into some kind of class notation),

I would like to understand this remark better.  For example, the Java
constructor paradigm seems more similar to my suggestion than the draft.

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

How would you suggest handling, within the current spec, the following:

   (define-type unit-vector
     (constructor (lambda (x y z)
                    (let ((length (+ (* x x) (* y y) (* z z))))
                      (values (/ x length)
                              (/ y length)
                              (/ z length)))))
     (fields x y z))

or

   (define-type rational
     (constructor (lambda (x y)
                    (let ((common (gcd x y)))
                      (values (/ x common)
                              (/ y common)))))
     (fields num denom))

If the spec cannot handle these common cases, is there a clear rationale why
not, and why the distinction is not arbitrary?  Could this rationale perhaps
be included in the spec?

Cheers
Andre