Luciana Lima Brito <lubrito@posteo.net> writes:

> Your advices helped me think more clearly.

Great :)

> There was no need to create or modify structures other than what I was
> already changing. I now return an alist instead of a list on the
> derivation-differences-* functions on comparison.scm (for outputs,
> inputs and sources). It helped to simplify the mapping on
> controller.scm. The changes on html.scm were minimal, basically it is
> matching on pairs, instead of single values.
>
> Two questions:
>
> 1 - The match on the html expects 5 values for "outputs", so I had to
> settle on using empty objects on the JSON, when needed, else it would
> break the match on the html. Is it ok?

So, one advantage of alists over lists is that the code is probably less
brittle when adding elements say, since code parsing the list will
probably break with a new element, but this is probably less likely to
happen with an alist.

However, this will happen with an alist if match is used to pick
elements out. I'd suggest using assq-ref or similar to pluck elements
out.

> 2 - Now on controller.scm "outputs", "inputs", "sources", and even
> "arguments" have the same structure, which is an alist of the form:
>
>   ((base . (...))
>    (target . (...))
>    (common . (...)))
>
> and I'm using the same map and match-lambda code to process them,
> wouldn't it be reasonable now to make it a local function?

I'd consider these options first probably:

 - Could the data coming from derivation-differences-data have vectors
   where appropriate already? The HTML code would probably need to be
   adjusted, but I think that's fine.

 - Could this be written in a form like:

   ,@(map (lambda (name)
           ...)
          '(outputs inputs sources arguments))