Re: Functional record “setters”

[Ludovic Courtès]

Hi Andy!

Thanks for your quick feedback!

Andy Wingo <address@hidden> skribis:

>> +                  (define-inlinable (modifier s val)
>> +                    (if (eq? (struct-vtable s) #,type-name)
>> +                        (struct-set! s index val)
>> +                        (throw 'wrong-type-arg 'modifier
>> +                               "Wrong type argument: ~S" (list s)
>> +                               (list s)))))))))
>
> Any better abstraction here?  It can be a big win to just pass the
> vtable to some function, because you avoid emitting code and constants.
> (It will be nice to start to elide some of these checks in the
> optimizer...)
>
> E.g. (throw-bad-struct s 'modifier).

Indeed, will do.

> Same for the getter.  ("Getter" and "setter" are better names IMO,
> because of other uses of the name "accessor" in Guile.)

“Modifier” was already in, but I should unify it, yes.

>>      (syntax-case x ()
>> -      ((_ type-name constructor-spec predicate-name field-spec ...)
>> +      ((_ immutable? type-name constructor-spec predicate-name
>> +          field-spec ...)
>
> I realize this is an internal macro, but it would be nice to support
> keywords (#:immutable), possibly without arguments...

Not sure I understand.  Macros can have keyword arguments?

>> +;; Import (srfi srfi-9)'s private module, so we can use the private
>> +;; `%define-record-type' macro.
>> +(eval-when (compile eval load)
>> +  (module-use! (current-module) (resolve-module '(srfi srfi-9))))
>
> Why not just use (@@ (srfi srfi-9) %define-record-type) ?

Indeed.

>>   (%define-record-type)[functional-accessors]: Mimic `define-inlinable',
>>   but add support for (ACCESSOR obj val), when `%reveal-setter' allows
>>   it.
>
> This is confusing naming.

‘functional-accessors’ and ‘accessors’ produce code for both getters and
setters.

I used “accessor” to mean either “getter or setter”, or just “getter”,
which is what’s confusing, I think.  I’ll improve that.

> I find the set-fields interface a bit strange, FWIW.  Are you happy with
> it, or do you think it could be better?  If you think it's really the
> thing to do, OK.

The goal was to have an interface close to what one would do in
imperative programming, that is:

  person.address.city = "foo";

I think it’s quite successful at it.

Now, I’m open for suggestions.  I don’t have any idea for a better
interface that meets this goal.  For instance, having to spell out the
getter names may look verbose, but I don’t see how it can be avoided.

Any ideas?

Thanks,
Ludo’.