Luciana Lima Brito writes: > Hi, > > On Sun, 18 Apr 2021 17:34:13 +0100 > Christopher Baines wrote: > >> I think it might be good to do something, just to narrow the scope. >> The outputs binding is valid for the whole let*, and all the code in >> it, but is only used on three lines, in one single place. Maybe there >> could be a let there that just defines outputs (maybe named >> output-groups so you can use the outputs binding for the overall >> thing). > > I did it. Great :) >> That's a good question, I'd look at the database schema, assuming the >> type of the field is a boolean, the question is whether the field is >> nullable? > > I looked on the database schema, and the "recursive" field is not > nullable, and it is a boolean, so the test I'm doing is working for > this. Cool. >> Hmm, I'm not sure why that is on the HTML page, but I'd generally try >> and keep most bits in the JSON, since it's not as helpful to omit bits >> if they're not that important. > > I added the "common" field for inputs. Ok. >> One other thing I noticed is that the alist for the args is being >> picked apart then reconstructed. Like for the inputs, outputs and >> sources, I'd map over the arguments alist and transform it to the way >> you want it to be. > > This part was a bit more complicated for me to understand. You mean I > should build a function similar to outputs, inputs and sources to map > the arguments, wouldn't it be a lot just to show a vector? As an example, if you have this structure. '((foo . 1) (bar . 2)) and you want the numbers to be strings, you can do something like: (map (match-lambda ((name . number) (cons name (number->string number)))) data) and I think a similar approach for the transformation you're trying to perform to the arguments will more cleanly represent what you're trying to do. One different thing I noticed: ,@(if (not (string? hash-alg)) '() `((hash-algorithm . ,hash-alg))) I'd suggest simplifying this by flipping the different parts of the if, and removing the not.