Hi, "Nicolas Pierron" <[email protected]> writes:
> On Mon, Dec 22, 2008 at 16:02, Ludovic Courtès <[email protected]> wrote: >> "Nicolas Pierron" >> <[email protected]> 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'. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
