[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Early feedback on Guix Home
From: |
Andrew Tropin |
Subject: |
Re: Early feedback on Guix Home |
Date: |
Tue, 20 Jul 2021 14:01:08 +0300 |
Ludovic Courtès <ludo@gnu.org> writes:
> Hi,
>
> (Sorry for the late reply…)
>
> Andrew Tropin <andrew@trop.in> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>>>> Possible action:
>>>>>
>>>>> 1. Change config records to accept file-like objects instead of
>>>>> strings. That way, users can choose to have snippets inlined (in a
>>>>> ‘plain-file’ object) or separate (via ‘local-file’). See for
>>>>> example how ‘tor-configuration->torrc’ does it.
>>>>
>>>> Yeah, there is a ‘slurp-file-gexp’ procedure that let’s one read an
>>>> extenal file, but using existing APIs like ‘local-file’ is probably a
>>>> better idea.
>>>
>>> Yes, it feels more natural. Also, ‘slurp-file-gexp’ returns a gexp (a
>>> code snippet), but as a user you don’t know where that snippet is going
>>> to be inserted; it may not work in some contexts.
>>
>> Acually, the idea behind `slurp-file-gexp` is that you always know where
>> it will be inserted, because it will be inside the specific section of
>> the configuration. Take a look at emacs home-service example:
>> https://git.sr.ht/~abcdw/rde/tree/master/item/gnu/home-services/emacs.scm#L91
>
> What I mean is that, in a general sense, one cannot know whether the
> gexp will be inserted in a place where it’s “valid”. Consider the
> following examples, where the gexp is meant to be inserted in lieu of
> “PLACEHOLDER”:
>
> #~(list '(#$PLACEHOLDER)) ;it’s quoted
>
> #~(let ((call-with-input-file (const #f)))
> #$PLACEHOLDER)
>
> These are “hygiene” problems discussed in the “Code Staging in GNU Guix”
> paper.
>
> All this to say that, from an API viewpoint, I think it’s (1) more
> robust, as I wrote, and (2) clearer to expect file-like objects in such
> places. It’s clearer because users can be expected to have an
> understanding of what ‘local-file’ does, whereas ‘slurp-file-gexp’ is
> more involved.
>
> I hope this clarifies what I had in mind!
>
> Ludo’.
Got the problem. Will take a closer look, when will be preparing this
code for upstreaming and maybe will reconsider the approach or will rise
another discussion on that. Also, need to schedule a reading of your
paper on gexps)
Thank you for clarification!)
signature.asc
Description: PGP signature