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: Sat, 10 Nov 2012 14:03:35 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:
> Documentation attached.  Comments?

Thanks!  Looks good to me, modulo a few comments below.

> BTW, why does ‘set-field’ has the record as its 2nd argument instead of
> 1st (unlike ‘set-fields’)?

Good question.  I followed the syntax of 'set-field' from your original
patch, but that argument order did not make sense for 'set-fields'.

On one hand, (set-field (person-address address-city) person "Boston")
matches the order of the corresponding english "set the field
(person-address address-city) of person to Boston", and thus reads a bit
more naturally to my ears.

On the other hand, it would be good for the two syntaxes to be
consistent with each other, and (set-field <record> <field> <value>)
would also be more consistent with things like 'hash-set!',
'vector-set!', etc.

Honestly, I could go either way.  If you think it makes sense to change
the order to (set-field <record> <field> <value>), I'd be glad to make
that change.  Obviously it's now or never :)

> address@hidden Functional ``Setters''
> +
> address@hidden functional setters
> +
> +When writing code in a functional style, it is desirable to never alter
> +the contents of records.  For such code, a simple way to return new
> +record instances based on existing ones is highly desirable.
> +
> +The @code{(srfi srfi-9 gnu)} module extends SRFI-9 with facilities to
> +return new record instances based on existing ones, only with one or
> +more field values address@hidden setters}.  First, the
> address@hidden works like
> address@hidden, except that setters are defined as functional
> +setters.

"except that the fields are immutable and the setters are ..."

[...]

> address@hidden {Scheme Syntax} set-field (field sub-fields ...) record value
> +Return a new record of @var{record}'s type whose fields are equal to
> +the corresponding fields of @var{record} except for the one specified by
> address@hidden
> +
> address@hidden must be the name of the getter corresponding to the field of
> address@hidden being ``set''.  Subsequent @var{sub-fields} must be record

This is the first time that "getter" is used, but it has not been made
clear that you mean what has been called an "accessor" elsewhere in the
doc.  More generally, there is a confusing mixture of the
accessor/modifier and getter/setter terminology.  I wonder if it would
made sense to do some kind of find/replace in this section.

Other than that, it looks great, thanks!

     Mark



reply via email to

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