Hi Ludovic, Ludovic Courtès <l...@gnu.org> writes:
> Ludovic Courtès <l...@gnu.org> skribis: > >> Maxim Cournoyer <maxim.courno...@gmail.com> skribis: > > [...] > >>> No :-). I meant why do we even set a default accessor for the *source >>> location* information (in the (gnu service configuration) macros); it's >>> that one that doesn't seem to get used (or I'm blind to it!), at least >>> via this accessor. If it's not strictly necessary, we can stop >>> producing it, and that would solve the problem. >> >> Like I wrote, I think it’s necessary, even if not used now. > > To complement this answer: key high-level record types usually have a > ‘location’ field: <package>, <channel>, <mapped-device>, <file-system>, > <service-type>, etc. The rationale is that it allows us to report > accurate location info for errors and warnings, to jump to their > definition, and so on. > > For configuration records this is not a common pattern, but the > rationale holds. ‘zabbix-front-end-config’ uses the ‘%location’ field, > but it seems to be the only one so far. 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". 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). I've applied the rename fix to master. -- Thanks, Maxim
