[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:

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