Re: Functional record "setters", a different approach

[ludo@gnu.org (Ludovic Courtès)]

Hi Mark!

And Happy Friday, as our friend would say.  :-)

Mark H Weaver <mhw@netris.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>> Mark H Weaver <mhw@netris.org> skribis:
>>> ludo@gnu.org (Ludovic Courtès) writes:
>>>> I’d still want named single-field setters, for convenience.  For that,
>>>> we probably still need a separate ‘define-immutable-record-type’.
>>>
>>> Agreed.
>>
>> Cool!  Could you integrate it somehow, along with the tests I provided?
>
> Will do.

Thanks!

>>> However, I find the term 'set' misleading, since no mutation is taking
>>> place.  Maybe 'update'?  I dunno, I don't have strong feelings on this.
>>
>> I don’t find ‘set’ misleading because there’s no exclamation mark, and
>> because it’s conceptually about setting a field’s value.  WDYT?
>
> Okay, on second thought I'm inclined to agree.  'set' is a good choice.

[...]

> What do you think?

I’d say ‘set-fields’, no?

(There are actually two common conventions: one is TYPE-METHOD, as in
‘vector-ref’, and another is VERB-NAME, as is ‘make-list’, ‘let-values’.
I tend to prefer the latter, but sometimes the former is more convenient
or clearer.)

[...]

>> Would these checks be alleviated by Andy’s work on peval “predicates”?
>
> Unfortunately, no.  The 'vtable' field of a struct is a mutable field,
> and in fact when a GOOPS class is redefined, the 'vtable' field of
> instances are modified.  This means that it is not safe for the compiler
> to eliminate redundant calls to 'struct-vtable'.

Oh, OK.  That is eviiiil.

>>> For example, for (modified-copy s ((foo-x) 'new)) where 's' contains 10
>>> fields, the expanded code would include 9 separate checks that 's' is
>>> the right type.
>>
>> Couldn’t ‘modified-copy’ be implemented differently so that there’s only
>> one check?  That seems like the most obvious (not necessarily the
>> easiest) way to address the problem.
>
> Yes, and that's exactly what I did.  However, I was only able to
> accomplish this by essentially hacking up my own '<getter>-nocheck'.
>
> If I had used the normal getters in the expansion of 'modified-copy',
> then (modified-copy s ((foo-x) 'new)) would expand to:
>
>   (make-struct <foo> 0
>     (foo-q s) (foo-r s) (foo-s s) (foo-t s) (foo-u s)
>     (foo-v s) (foo-w s) 'new      (foo-y s) (foo-z s))
>
> and each of those getter uses would include a type-check in their
> expansions.  As you suggested, I instead wrap a single check around the
> whole thing and then effectively use (foo-*-nocheck s) instead, by using
> 'struct-ref' directly.
>
> This example is intended to convince you that 'nocheck' variants of
> struct accessors are important as a base upon which to build efficient
> higher-level constructs, at least for our own internal use.

I view it as an important “implementation detail”, but not as an API to
be exposed publicly.

What about keeping it private until we find an actual use case where it
is required outside of (srfi srfi-9)?

Thanks!

Ludo’.