Looking for a nice functional method of merging the second list into the top one to produce the third one
Any ideas?
no, i don’t think that’s what they mean
let me try somthing
Oh, sorry. I didn’t read the thing too well. Is the second element for each sublist always true/false/0?
i think they mean using the second list to change the items in the first list so that it becomes the third list
This is my best effort so far by using @mark4sisb combineIf reporter
It does rely on the sort being stable with the duplicate items coming from the 2nd list being inserted AFTER the same key item.
It does muck up the order (which should be same as the 1st list e.g. QoS, retain then binary mode so it’s not perfect
Looks good 
If you are sure the lists are always key/value pairs with the key always being text (no numbers), then you can do this
This will also add new items if they don’t exist in the first list
Several of the proposed solutions are non-functional. It’s easy to do this non-functionally! If the fields of the second list are always a subset of the fields of the first one (or if you want to ignore any extras) I’d do it functionally this way:
I think the issue is with the if
I actually don’t understand what this test is doing
Why are we checking something against a collapsed join?
I’m really just wondering, is there something wrong with the variadic functionality of the let block?
FYI To others - As I said in my OP - I was looking for a functional solution as most things can be done easier imperatively but I wanted to see if it could be done by mapping
I actually don’t understand what this test is doing
Why are we checking something against a collapsed join?
Because if I just left that input slot empty, the implicit input feature would substitute the list item into it. I just wanted an expression whose value is an empty string. (I wish Jens had chosen something else as the value to return if a dictionary item isn’t found!) In the version with the explicit VALUE parameter I could have left that slot empty, but I wrote it originally with implicit input slots.
I agree that the problem is with the IF, but I still don’t understand why it’s problematic.
Ok.
So I’m thinking that the “trick” of using the collapsed join to produce an empty list (when using implicit input slots) just isn’t cutting it.
The collapsed join is probably accepting the implict parameter
Making an explicit empty text block works
as most things can be done easier imperatively
Wash your mouth out with soap!
Very simple things such as
are easier functionally. So is dealing with tree-structured data:
TREEMAP is my nominee for the world’s most beautiful program.
And join(list) does it without need for custom reporter
Got it, thanks!