bug#59423: Invalid 'location' field generated in dovecot configuration

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Thanks for this extra bit of information and for spotting this usage.  I
>> think "location" is likely to conflict for the general purpose
>> 'define-configuration' generated records, so I've renamed the "location"
>> *accessor* to "source-location".
>
> Thank you.
>
> It wasn’t my preferred solution¹ but I think it’s a good one.
>
> ¹ https://issues.guix.gnu.org/59423#15-lineno81
>
>> In the near future I want to migrate more service configurations to the
>> 'define-configuration' machinery, to benefit from its useful
>> self-validating property.  For now I wouldn't feel at ease doing so
>> unless raw record matching (not yet using 'match-record') works the same
>> way, since we still have many occurrences making use of that (often via
>> match-lambda).  For that reason, I prefer to not revert the record
>> layout until we've gotten rid of all the match-lambda matching record
>> fields directly (which will take some time).
>
> Right, especially given that ‘match-record’ was added in 2017.  :-)

Hehe!  I had started adapting all the match-lambda, and got overwhelmed
by the changes needed.  So I think progressively (i.e., small) be easier
to review or revert in case of errors.

> We’ll have to discuss the implications of a possible move to
> ‘define-configuration’.  For example, ‘define-configuration’ cannot
> report missing field values (for fields that lack a default value) at
> macro-expansion time, contrary to plain ‘define-record-type*’.  Anyway,
> future work!

OK.  That's optimization work rather than an impediment to migrate
though, right?  If so, I think the value for users of having errors on
invalid field types outweighs run time efficiency :-).

-- 
Thanks,
Maxim