Luciana Lima Brito writes: > Hi, > > On Sat, 17 Apr 2021 18:45:14 +0100 > Christopher Baines wrote: > >> Some more things to think about: >> >> - Variable naming, what does the "matched" in matched outputs mean? >> (same goes for the other "matched" things) > > The name matched would refer to the match function, but I changed to > *-values. The names I wanted were "outputs", "inputs" > and "sources", but I already used them. If you have anything in mind, > please let me know. 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). >> - (if (null? ...), I'm unsure if all of those checks are necessary, I >> believe some fields at least will never be "null?". > > I revised it, I think now it's better. > About the "recursive" field, apparently it assumes a string value "t" > or "f", and I convert this to a boolean. Are there other values > possible? 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 think you're getting close to something that's ready to merge >> though. > > One last thing, I see that on the html the commom inputs are ommited. > Does this make sense for the json too? 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. 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.