Hi Maxim,
Maxim Cournoyer <maxim.courno...@gmail.com> skribis:
>> We have this:
>>
>> (define-record-type* #,(id #'stem #'< #'stem #'>)
>> stem
>> #,(id #'stem #'make- #'stem)
>> #,(id #'stem #'stem #'?)
>> #,@(map (lambda (name getter def)
>> #`(#,name #,getter (default #,def)
>> (sanitize
>> #,(id #'stem #'validate- #'stem #'- name))))
>> #'(field ...)
>> #'(field-getter ...)
>> #'(field-default ...))
>> (%location #,(id #'stem #'stem #'-location)
>> (default (and=> (current-source-location)
>> source-properties->location))
>> (innate)))
>>
>> That generates two accessors called ‘namespace-configuration-location’.
>> The second one shadows the first one.
>
> Yes. You didn't address my question directly though, so let me ask it
> again: where is this %location field access (named "location") used?
When doing something like this:
--8<---------------cut here---------------start------------->8---
scheme@(guix-user)> ,m(gnu services mail)
scheme@(gnu services mail)> (namespace-configuration (name "inbox"))
$1 = #<<namespace-configuration> name: "inbox" type: "private" separator: ""
prefix: "" location: "" inbox?: #f hidden?: #f list?: #t subscriptions?: #t
mailboxes: () %location: #f>
scheme@(gnu services mail)> (serialize-configuration $1
namespace-configuration-fields)
name=inbox
type=private
separator=
prefix=
location=#f
inbox=no
hidden=no
list=yes
subscriptions=yes
$2 = #<gexp gnu/services/configuration.scm:123:2 7f196470ac00>
--8<---------------cut here---------------end--------------->8---
… the field is accessed via its accessor,
‘name-configuration-location’. We can kinda see it here:
--8<---------------cut here---------------start------------->8---
scheme@(gnu services mail)> ,pp namespace-configuration-fields
$1 = (#<<configuration-field> name: name type: string getter: #<procedure
%namespace-configuration-name-procedure (s)> predicate: #<procedure string?
(_)> serializer: #<procedure serialize-string (field-name val)>
default-value-thunk: #<procedure 7fce8d866478 at gnu/services/mail.scm:433:0
()> documentation: "Name for this namespace.">
#<<configuration-field> name: type type: string getter: #<procedure
%namespace-configuration-type-procedure (s)> predicate: #<procedure string?
(_)> serializer: #<procedure serialize-string (field-name val)>
default-value-thunk: #<procedure 7fce8d8664a8 at gnu/services/mail.scm:433:0
()> documentation: "Namespace type: @samp{private}, @samp{shared} or
@samp{public}.">
[…]
#<<configuration-field> name: location type: string getter: #<procedure
%namespace-configuration-location-procedure (s)> predicate: #<procedure string?
(_)> serializer: #<procedure serialize-string (field-name val)>
default-value-thunk: #<procedure 7fce8d866538 at gnu/services/mail.scm:433:0
()> documentation: "Physical location of the mailbox. This is in same format
as\nmail_location, which is also the default for it.">
[…]
--8<---------------cut here---------------end--------------->8---
Each <configuration-field> record has a ‘getter’ field that refers to
the accessor. In the case of ‘location’, that’s the “wrong”
accessor—the accessor of ‘%location’.
I hope that addresses your question!
>> What do you think of reverting 44554e7133aa60e1b453436be1e80394189cabd9?
>
> No. If we revert something, it won't be that whole commit, but just the
> moving of the field in the define-configuration produced record.
Yes, that’s what I meant; sorry for the confusion.
>> After that we can work on renaming the ‘location’ field of
>> <namespace-configuration> while preserving backward compatibility.
>
> Why do we have to massage the user facing record
> (namespace-configuration) instead of the underlying mechanics? The
> macro should serve us, not the other way around :-). See my idea to
> simply rename/remove that automatically produced "location" accessor
> which appears unused to me. Would that work?
What would need renaming in this case is the accessor, not the field.
In <https://issues.guix.gnu.org/48284> you proposed renaming the
accessor to *-source-location instead of *-location. That sounds like a
good idea to me. We should get unbound-variable warnings in modules
that use the previous name, so we’ll see if that breaks something.
The only downside is that the convention elsewhere in the code is
-location, not -source-location.
So the other option is to rename ‘location’ in
<namespace-configuration>. That also has the advantage of being less
intrusive.
WDYT?
Ludo’.
