guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#63985] [PATCH RFC 0/5] Generic INI serializer & SRFI-171 for define


From: Maxim Cournoyer
Subject: [bug#63985] [PATCH RFC 0/5] Generic INI serializer & SRFI-171 for define-configuration
Date: Sat, 07 Oct 2023 12:35:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13)

Hi,

Bruno Victal <mirai@makinata.eu> writes:

> On 2023-10-02 19:28, Maxim Cournoyer wrote:
>>> +An example of a simple serializer procedure:
>>> +@lisp
>>> +(define (serialize-boolean field-name value)
>>> +  (let ((value (if value "true" "false")))
>>> +    #~(string-append '#$field-name #$value)))
>>> +@end lisp
>>> +
>> 
>> I know this is adapted from old code, but shouldn't there be a "=" in
>> that string-append, between the field name and its value? […]
>
> I think there's no particular meaning for that isolated snippet but I
> believe the original author did intend for there to be a "=" symbol as
> you have pointed out. I've went ahead and added the “ = ” (with spaces)
> variant instead.
>
>> […] Also, using gexps here seems unnecessary and may confuse the reader.
>
> I don't think so because in general you're going to call
> `serialize-configuration' which returns a G-Expression so it's more or
> less given that using G-Expressions is perfectly valid and using them
> from the outset allows your fields to serialize any kind of value such as
> package objects (for something like `gcc-path = /gnu/store/…'), etc.
>
> Thus, not using G-Exps is more restrictive in terms of what you can
> serialize. It might not make a difference in some cases but I think
> this is a potential source of trouble when someone tries to serialize
> a gexp object with a non-gexp ready serializer. (e.g. performing
> string-append with a string and a package object)

Agreed.

-- 
Thanks,
Maxim





reply via email to

[Prev in Thread] Current Thread [Next in Thread]