[Nix-dev] Re: NixOS: New scheme

[Nicolas Pierron]

On Mon, Dec 22, 2008 at 21:17, Ludovic Courtès <ludo at gnu.org> wrote:
> 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?

Yes, it is needed to ensure that all options that you are using are defined.

>> uniqFlatten:
>> This function takes a list "x" and flatten it with the function
>
> What does "flattening a list" mean here?

let
  a = { foo = ..; };
  b = { bar = ..; require = [a b]; };
  c = { baz = ..; require = [a b]; }
in
  uniqFlatten prop [] [] [c] == map prop.value [a b c]

>> "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?

You are right, we can handle that with a map function.

>> 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'?

That is currently its only use case and I've added some context
information to tell you the importance of this function in this
problem.  This function is generic and may be hard to explain without
an example to support the explanation.

>> 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.  ;-)

zip is common with lists of tuples in other languages, so I have a
similar things for list of sets.  I hope that the following example
will help explain you everything about this function (better than
words):

zip f [
  { foo = a; }
  { foo = b; bar = c; }
  { foo = d;}
]
==
mapAttrs f {
  foo = [a b d];
  bar = [c];
}

So as well as the uniqFlatten remarks about values, the function "f"
could be removed. (I don't have the full laziness spirit yet)
in other functional languages you generally see it as:

zip [1 2 3] [4 5 6] == [(1, 4) (2, 5) (3, 6)]

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.