:cascade filter run prefix in a $set widget's filter - unexpected behaviour

#1

Hello everyone,
I’m stuck on an issue with :cascade filter run prefix used in a filter which is part of a <$set> widget.

Let me show you this little example:

  1. I created an empty test tiddler ‘test’
  2. I defined a field myFilter as [!match[apple]]
  3. then I wrote this code as the tiddler’s text:

Question one: is a banana an apple or a banana? It;s a {{{ banana :cascade[{!!myFilter}] }}}

<$set name='result' filter="apple :cascade[{!!myFilter}]" value='correct' emptyValue='no, they are the same!'>
Question two: is an apple different from itself? <<result>> </$set>

Now the output I could see is this:

Question one: is a banana an apple or a banana? It’s a banana
Question two: is an apple different from itself? correct

which is not completely satisfactory to me. I can easily agree, indeed, that a banana is not an apple, so I have no objection to the answer of question one, but question two’s answer puzzles me, because after all an apple is NOT different from itself! (at least as far as I know about apples)

Coming to the code, banana :cascade[{!!myFilter}] evaluates to banana!match[apple] if I get how :cascade filter run prefix works, and so it outputs, indeed, ‘banana’ as expected.
Filter number two apple :cascade[{!!myFilter}], on the other hand, is none but [apple!match[apple]] in disguise, and so it should evaluate to an empty string, isn’t it? If it is so, then the <$set> widget should assign to its own variable result the value of attribute emptyValue, and the answer of question two should be ‘no, they are the same!’, but unfortunately this is not the case and I can see ‘correct’ as an answer, which is not correct at all but rather wrong.

Now to make a little experiment, if you replace the banana in filter one with an apple, as {{{ apple :cascade[{!!myFilter}] }}} it correctly outputs an empty string, as filter apple!match[apple] is expected to do, so the problem seems to be with the <$set> widget and the assignment to its attributes value and emptyValue.
Is it a bug or I am going mistaken somewhere?

PS since I’m not so sure on filters’ syntax, I also tried this alternative one:

{{{ [banana] :cascade[{!!myFilter}] }}}
filter="[apple] :cascade[{!!myFilter}]"

surrounding apple and banana with square brackets. Whatever syntax is correct (or maybe both are) the result is exactly the same.

PPS I KNOW that a :cascade statement returning just one filter is rather odd, I just wanted to make this example as simple as possible so to better highlight the problem

TiddlyWiki version 5.2.1 browser: Firefox 98.0.2
#2

Instead of using the :cascade filter run to apply the filter stored in the myFilter field, you can use the filter operator, like this:

Question one: is a banana an apple or a banana? Its a {{{ [[banana]filter{!!myFilter}] }}}

<$set name="result" filter="[[apple]filter{!!myFilter}]" value="correct" emptyValue="no, they are the same!">
Question two: is an apple different from itself? <<result>>
</$set>

-e

#3

The cascade filter run prefix is usually used when you have multiple filters to test. If nothing matches, it returns a blank – which is not nothing. So for your particular use case, you would need to check for that blank. So if you were really set on using the cascade, then something like this:

<$set name='result' filter="apple :cascade[{!!myFilter}]+[!is[blank]]" value='correct' emptyValue='no, they are the same!'>
<<result>>
</$set>
#4

thank you very much, I will apply your suggestion, but the point of my post was not so much to find a different way to go as to either single out a bug, if this is the case, or further analyze an unexpected behavior so to better understand how :cascade filter run prefixes and <$set> widgets with filters work and interact.

CG

#5

thanks a lot, what you say makes sense, but seems rather inconsistent with what the documentation says, at least to my eyes…

I quote from https://tiddlywiki.com/static/Cascade%20Filter%20Run%20Prefix.html

If none of the filters return a result for an input title, it is replaced with an empty string.

#6

An empty string ("") is different from a filter that produces no results. The empty string is a result. And yes, it may seem counter-intuitive.

1 Like
#7

thanks, though as far as I see things there is no such thing as ‘a filter that produces no result’ , but rather filters that produce the empty list as a result.
This opens room for the broader issue of how consistently does TW handle empty ‘things’. Moreover, it is legitimate, I think, to pose the question of how tightly (or how loosely) the notion of ‘data type’ fits into TW.

#8

Not true. End a filter with !is[blank] if you must but any filter that does not return a value is a filter not returning a result. Eg when the list widget does not display its content, even default content.

It is importiant to keep in mind tiddlywikis filters key roll is to return tiddler titles however we have extended this to manipulate other strings even numbers or manufacture titles via concatination including with field, tiddler and variable content.

Thus you can see why sometimes you may have a blank output rather than empty. You could possibly find something similar in most programming languages.