guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Functional record "setters", a different approach


From: Mark H Weaver
Subject: Re: Functional record "setters", a different approach
Date: Wed, 11 Apr 2012 03:57:00 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

I rushed out my last email because I didn't want anyone else to waste
time working on the same functionality.  Needless to say, this is very
preliminary work.  A few errata in my last email:

>   (define-tagged-inlinable (key value) ... (name formals ...) body ...)

There's a missing pair of parens around "(key value) ..." here.

> The public interface I've created is quite a bit different than what
> we've been discussing so far.  I'm open to changing it, but here's what
> the attached patch currently exports from (srfi srfi-9 gnu):
>
>   (modified-copy <struct-expr> (<field-path> <expr>) ...)
>   (modified-copy-nocheck <struct-expr> (<field-path> <expr>) ...)
>
> where <field-path> is of the form (<field> ...)

The "path" is actually a list of getters, not field names.

>   scheme@(guile-user)> (modified-copy a
>                          ((get-x get-i) 10)
>                          ((get-y) 14)
>                          ((get-x get-j get-y) 12))

Needless to say, I suck at marketing :)  These record definitions are
what I used for testing (taken from srfi-9.test), but this syntax looks
very bad when the getters are named like this.  It looks much better
when the getters have names like the ones Ludovic chose for his
examples, e.g. 'person-age', 'person-address', 'address-street',
'address-city', etc.

> --- a/test-suite/tests/srfi-9.test
> +++ b/test-suite/tests/srfi-9.test
> @@ -29,7 +29,7 @@
>    (x get-x) (y get-y set-y!))
>  
>  (define-record-type :bar (make-bar i j) bar? 
> -  (i get-i) (i get-j set-j!))
> +  (i get-i) (j get-j set-j!))
>  
>  (define f (make-foo 1))
>  (set-y! f 2)

Note that I improved the compile-time error checking to the existing
srfi-9 macros, which called attention to the mistake in srfi-9.test
above.  Previously, our srfi-9 implementation silently accepted
duplicate field names.

     Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]