Re: Problems with field initialization: Proposal
Andre van Tonder
(16 Sep 2005 18:21 UTC)
|
Re: Problems with field initialization: Proposal
Michael Sperber
(20 Sep 2005 10:07 UTC)
|
Re: Problems with field initialization: Proposal
Andre van Tonder
(20 Sep 2005 15:40 UTC)
|
Re: Problems with field initialization: Proposal Andre van Tonder (20 Sep 2005 16:11 UTC)
|
Re: Problems with field initialization: Proposal Andre van Tonder 20 Sep 2005 16:11 UTC
On Tue, 20 Sep 2005, Andre van Tonder wrote: > In the following examples, both the formals and the parent arguments can > easily be factored out to reproduce the surface syntax of the SRFI, with a > certain loss of expressiveness. Let me also point out some more problems (sorry ;-): Factoring out the formals causing loss of expressivity: ------------------------------------------------------- - We cannot use CASE-LAMBDA for variable arity constructors. - We cannot express (speudocode): (define-type generated-id (fields symbol) (constructor (let ((count 0)) (lambda () (set! count (+ count 1)) (string->symbol ................))))) Factoring out parent arguments causing loss of expressivity: ------------------------------------------------------------ - We cannot call the parent with different arguments depending on the child arguments, e.g. (define-type eq-hash-table (parent hash-table) (constructor (lambda (size hasher) (if (< size 7) (instantiate (eq? (lambda (key) 0) 1)) ; parent arguments (instantiate (eq? hasher size)))))) > In the following examples, INSTANTIATE is a local lexical macro valid in the > constructor clause that does two orthogonal things: By the way, since INSTANTIATE would be a lexical macro, this makes it impossible to write a global procedure that could be reused for more than one record type. A positional interface would be superior in this regard. Cheers Andre