Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Maxim Cournoyer <maxim.courno...@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