Email list hosting service & mailing list manager

Re: Problems with field initialization: Proposal Andre van Tonder (15 Sep 2005 16:35 UTC)
Re: Problems with field initialization: Proposal Michael Sperber (15 Sep 2005 18:15 UTC)
Re: Problems with field initialization: Proposal Andre van Tonder (15 Sep 2005 20:41 UTC)
Re: Problems with field initialization: Proposal Michael Sperber (16 Sep 2005 07:11 UTC)
Re: Problems with field initialization: Proposal Andre van Tonder (16 Sep 2005 12:56 UTC)
Re: Problems with field initialization: Proposal Michael Sperber (16 Sep 2005 17:12 UTC)
Re: Problems with field initialization: Proposal Andre van Tonder (16 Sep 2005 15:23 UTC)
Re: Problems with field initialization: Proposal Michael Sperber (16 Sep 2005 17:14 UTC)

Re: Problems with field initialization: Proposal Michael Sperber 16 Sep 2005 17:12 UTC

Andre van Tonder <xxxxxx@now.het.brown.edu> writes:

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

I would think the opposite is true:

(define-type foo (a b)
  (fields
    (a (foo-a) a)
    (b (foo-b) b)))

class Foo {
  int a;
  int b;

  Foo(int a, int b) {
    this.a = a;
    this.b = b;
  }
}

Note that, in the constructor, things occur in the exact same order as
in DEFINE-TYPE, and that the association between construction
procedure arguments and fields is by name rather than by position.

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

Primarily because these didn't occur in the concrete examples we
looked at.  (Thanks for writing them up!)  Note that I didn't say the
present spec could handle them straightforwardly, but rather that it
could straightforwardly be generalized to handle them.  One might
imagine two hypothetical generalizations:

- In a field spec, allowing the field names prior to the spec to be
  used as variables in the initialization expression like so:

(define-type foo (a)
  (fields
    (a (foo-a) a)
    (b (foo-b) (f a))))

  (Doesn't cut your mustard, but may cut someone else's.)

- Add a LET clause that introduces a binding into the constructor like
  so:

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

 (Possibly making repeated LET clauses nest.)

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla