unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: "Clément Lassieur" <clement@lassieur.org>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: RFH: Add prosody service
Date: Sun, 04 Dec 2016 22:11:21 +0100	[thread overview]
Message-ID: <87lgvv5rie.fsf@gnu.org> (raw)
In-Reply-To: <87y3zybmsv.fsf@lassieur.org> ("Clément Lassieur"'s message of "Fri, 02 Dec 2016 12:19:44 +0100")

Hello Clément,

Clément Lassieur <clement@lassieur.org> skribis:

>>> B. Common settings should have a default value in prosody-configuration,
>>>    and be disabled by default in the list of virtualhost-configurations.
>>
>> Oh, I see.
>>
>>> I found two ways to solve this:
>>>
>>> 1. One uses "eval" to transform the input of "define-configuration" into
>>>    a list that I can build from other lists.
>>>
>>> 2. The other uses a macro that takes define-configuration's input, plus
>>>    a tag (called target) describing whether it's a global, common, or
>>>    virtualhost specific field.  Then the macro calls
>>>    define-configuration many times, each time with a subset of the
>>>    original input, filtered with a specific tag ("global",
>>>    "virtualhost") plus the "common" tag.
>>>    (Its name is define-all-configurations.)
>>
>> I think you could always write a ‘define-common-configurations’ macro on
>> top of ‘define-configuration’ that would let you specify two default
>> values: one for the global context, and one for the virtual-host
>> contexts.  (Thus, no need for ‘eval’: the code is generated at macro
>> expansion time.)
>>
>> Would that work?
>
> That's kind of what I did here:
> http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01075.html
>
> The macro 'define-all-configurations' defines two default values: one
> for the global context (def) and one for the virtual-host context
> ('disabled).
>
> (The macro I did also changes the doc and the type, depending on whether
> it's a virtualhost or not.)

Sounds good.

>> It would allow you to avoid repeating field definitions, but you’d end
>> up with two almost identical record types that are completely disjoint
>> (no inheritance in particular.)  This may or may not be desirable.
>>
>> For record type inheritance, we’d need SRFI-99 or something equivalent.
>
> Which is not implemented by Guile, is it?

No, though maybe the reference implementation just works.  Alternate,
SRFI-35 and (rnrs records), both available in Guile, support
inheritance.

> So is what I did desirable?  Or maybe should we wait until we have
> something similar to SRFI-99, and use opaque-prosody-configuration only?

What you did looks good.  Whether proper inheritance should be prefer
over the purely syntactic approach you took is something I can’t answer;
I guess it depends on the semantics and expected use of those data
structures.

So if it sounds good to you, we can certainly start with the patch you
have (minus duplication with (gnu services configuration).)

WDYT?

>> So you could define a ‘maybe-string’ type, say, with an associated
>> serializer.
>>
>> How does that sound?
>
> That's also what I did here:
> http://lists.gnu.org/archive/html/guix-devel/2016-11/msg01075.html

Perfect.  :-)

Sorry for the delay, I admit I got lost in the discussion, my bad!

Thanks,
Ludo’.

      reply	other threads:[~2016-12-04 21:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-26 17:15 RFH: Add prosody service Clément Lassieur
2016-11-26 17:20 ` [PATCH] gnu: " Clément Lassieur
2016-11-26 23:41   ` Leo Famulari
2016-11-27 10:04     ` Clément Lassieur
2016-11-26 17:20 ` Clément Lassieur
2016-11-26 21:28 ` Clément Lassieur
2016-11-26 21:30 ` Clément Lassieur
2016-11-28 19:54 ` RFH: " Hartmut Goebel
2016-11-28 21:01 ` Ludovic Courtès
2016-12-02 11:19   ` Clément Lassieur
2016-12-04 21:11     ` Ludovic Courtès [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87lgvv5rie.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=clement@lassieur.org \
    --cc=guix-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).