Paul,
I think using a deduped List instead of a Set implies that the sequence matters, and so the agent would have to do extra work resetting an attribute over changes in order?
I can easily switch the data type to list, but it doesn’t seem as natural. Mostly, I was surprised I couldn’t find a “set(…)” equivalent to “list(…)”.
I just ran some quick tests and it seems as though if you have a Set on the left-hand side of ==, then it coerces the right-hand to a Set for the comparison.
For example, if you have:
$MySet = foo;bar;baz
$MyList = bar;foo;baz;foo
then $MySet == $MyList is true, and $MyList == $MySet is false.
So I’m a bit surprised that your code doesn’t work. That said, I’ve encountered plenty of surprises in Tinderbox action syntax.
My approach is to begin by hard-coding values and gradually replace them with expressions. For example, I might change the $AgentQuery to:
in some cases it’s possible that the hard-coded value works and the expression doesn’t (some expressions need extra parentheses) so I find it easiest to isolate each piece and build up to the final expression.
In this particular case I think you might be getting thrown off by the fact that agents work on aliases of notes. I created a test document and when I changed the query to
Links & aliases have some behaviours, strange against first assumptions, that only make sense through deeper use of the app. IOW - the existing behaviour is for a reason and can’t, for valid technical reasons, suit all use cases.
If joining (the output) of two links() actions I’d be tempted to also put each discrete links() call in parentheses to make it plain to Tinderbox that we’re merging two lists as opposed to some other data type:
Mark & Pat,
turns out the parentheses did make a big difference. I was accidentally getting a string-concatenation. I wouldn’t have spotted it without substituting simple lists.
I’m not sure I want to spend the time figuring out exactly why, but I may have to, for future use.