Re: Problems with field initialization: Proposal

[Andre van Tonder <andre@xxxxxxxxxxxxxxxxx>]

On Fri, 16 Sep 2005, Michael Sperber wrote:

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