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 Andre van Tonder 15 Sep 2005 16:34 UTC
Andre wrote: > Perhaps another keyword clause > > (constructor <expression>) > > which can be left out for the default constructor. As an example, the hash-table example could be expressed: (define-type hash-table (constructor (k) (lambda (pred hasher size) (k pred hasher (make-vector (nearest-prime size)) 0))) (fields (pred immutable) (hasher immutable) (data mutable) (count mutable)))) (define-type eq-hash-table (parent hash-table) (constructor (k) (lambda (pred hasher size) (k pred hasher size 0))) (fields (gc-count mutable))) All the initialization information is in a single place, and both the parent clause and the field clauses simplify. A record type with the default constructor ordering would simply omit the constructor clause: (define-type point (fields (x mutable) (y mutable))) which is actually a little more concise than the current specification. We don't need the INIT! clause any longer. The last example from the document becomes: (define-type cpoint (parent point) (constructor (k) (lambda (x y c) (set! *the-cpoint* (k x y (color->rgb c))) *the-cpoint*)) (fields (rgb mutable))) So again, all the initialization information is in a single place. Cheers Andre