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