[Nix-dev] Re: NixOS: New scheme

[Ludovic Courtès]

Hi,

"Nicolas Pierron"
<nicolas.b.pierron at gmail.com> writes:

> On Mon, Dec 22, 2008 at 16:02, Ludovic Courtès <ludo at gnu.org> wrote:
>> "Nicolas Pierron"
>> <nicolas.b.pierron at gmail.com> writes:
>>
>>> The implementation need all other module used to implement it and the
>>> options defined by this module with the attribute named "require"
>>
>> I don't understand this sentence.
>
> Me too, my fault.  The "require" attribute is used to list all
> configuration files that you need to implement your own configuration
> file safely.  The idea is that it imports in your own attribute set
> all configuration that are needed for your implementation.

Understood, thanks.

>>>   require = [
>>>     # options needed for the implementation
>>>     (import ../upstart-jobs/default.nix)
>>
>> This happens to be commented out, e.g., in `upstart-jobs/cron.nix' in
>> `trunk'.  Why would it be needed?
>
> In the trunk, "../upstart-jobs/default.nix" is not yet a valid
> configuration file, therefore this would create a failure.

OK, I see.

>>>     # options defined by this module
>>>     options
>>>   ];
>>
>> Interestingly, options defined by this module are *provided*, not
>> *required*, so why does one need to list them in the `require'
>> attribute?!
>
> This is more like a legacy from the first time I got this idea, which
> is to import sub-configuration files.

So what?  Is it still needed?

> uniqFlatten:
> This function takes a list "x" and flatten it with the function

What does "flattening a list" mean here?

> "prop.next", at the same time it skips elements which have the same
> key (prop.key x) and it returns the list of values (prop.value x).

Why entangle two different functions into one?

> This function handle the "require" attribute inside the "prop.next"
> which retrieves the content of this attribute.

`prop.next' is caller provided, so how can you tell that `uniqFlatten'
handles `require'?

> zip:
> This simple function is used to merge all attribute (configuration)
> sets into one big configuration set.

This makes it sound as though it's equivalent to `//', which it isn't.
Looking at the code, I don't clearly understand what it does.  The
argument names don't help much, to my defense.  ;-)

Thanks for taking the time to explain all this.  Although I'm used to
programming in a strict FP (Scheme), I can hardly grasp this programming
style.  Perhaps it's just that I have to take time to get used to it.
Maybe it's also a sign of lack of clarity.  I find the ubiquitous use of
attributes confusing at times; the syntax is also much more ambiguous
than what I'm used to.

Thanks again,
Ludo'.