Passing Multi-Valued Variables to Procedures

[btheado]

I'm trying to understand the use of double parenthesis for passing MVV to procedures as documented here:

https://tiddlywiki.com/prerelease/#Multi-Valued%20Variable%20Attribute%20Values

The primary use case for this syntax is passing multi-valued variables through the $transclude pipeline to procedures and functions:

\procedure showItems(itemList)
<$text text={{{ [(itemList)join[-]] }}}/>
\end

<$let items={{{ [all[tiddlers]sort[]] }}}>
<$transclude $variable="showItems" itemList=((items))/>
</$let>

When I experiment with it, the result is the same whether I use ((items)) or <<items>>.

Here is a share site link showing output for the two is identical.

Is there a better example which shows the need for ((items)) syntax?

[saqimtiaz]

That observation makes sense @btheado. In the changes made in #9645 the transclude widget switches to always computing attributes as MVV. @Jermolene are there still scenarios where we need the ((varname)) syntax in attributes?

[btheado]

Thanks, @saqimtiaz. I looked more into the code changes and it looks like this later PR #9663 is the one which made the parens not required.

After that PR, the transclude widget is alway passing asList=true

TiddlyWiki5/core/modules/widgets/transclude.js

Lines 26 to 29 in 02b4c04

	TranscludeWidget.prototype.render = function(parent,nextSibling) {
	this.parentDomNode = parent;
	this.computeAttributes({asList: true});
	this.execute();

and therefore in computeAttributes, it doesn't matter if attribute.isMVV is set in the parse tree or not

TiddlyWiki5/core/modules/widgets/widget.js

Lines 442 to 446 in 02b4c04

	if(options.asList || attribute.isMVV) {
	value = variableInfo.resultList;
	} else {
	value = variableInfo.text;
	}

[saqimtiaz]

@btheado thank you, that is indeed the PR I meant.

[ericshulman]

always computing attributes as MVV

What happens to existing wikitext code that assumed that filtered attributes (i.e., attr={{{ ... }}}) always use the first filter result? Of course, this can be addressed by changing the wikitext code to use attr={{{ ... +[first[]] }}}, but the need for those changes might not be obvious and could potentially lead to lots of unexpected problems.

EDIT: based on my reading of #9645, always using MVV attribute handling is only applied to the $transclude widget, so other widget (in particular $let) are not affected. Can you confirm this?

[saqimtiaz]

@ericshulman the relevant changes are actually in #9663 as @btheado correctly pointed out, and do indeed only apply to the transclude widget.

[btheado]

the need for those changes might not be obvious and could potentially lead to lots of unexpected problems.

From playing around with it, I haven't found cases where in the end you don't need to use the new parens syntax in order to access the multiple values. Which means it should be backwards compatible with 5.3.8

Consider this:

\procedure showItems(itemList)
<$text text={{{ [(itemList)join[-]] [<itemList>] :and[join[_]] }}}/>
\end

<$let items={{{ 1 2 3 4 5 }}}>
<$transclude $variable="showItems" itemList=<<items>>/>
</$let>

which renders as 1-2-3-4-5_1

Based on that I interpret "always computing attributes as MVV" to just mean that you don't lose the ability to access the MVV "lower" in the call stack even though "higher" in the call stack the paren syntax was not used.

[btheado]

Similar to how the transclude widget allows the mvv to be passed to an attribute via angle brackets, it would be nice if function call would allow mvv parameter to be passed via angle brackets.

IOW, I would like it if both of the below show.items function calls return the same value

\function show.items(itemList) [(itemList)join[-]]

<$let items={{{ 1 2 3 4 5 }}}>

<$text text={{{[show.items(items)]}}}/>

<$text text={{{[show.items<items>]}}}/>
</$let>

Currently the first on returns 1-2-3-4-5 and the second one returns 1

With that in place, the parens would not be required for function calls in filters.

Then going further, you could remove the need for the parenthesis in the title operator by instead changing the getvariable[] operator to support returning multiple values for each variable.

IOW, 1 2 3 4 =>myvar [[myvar]getvariable[]join[-]] would return 1-2-3-4-5 instead of 1

If that works, then the MVV functionality can stand on its own without any syntax changes. All the required changes are widgets and operators:

• $let widget and :let filterrun allow setting MVV
• $transclude widget can pass MVV along to procedures
• function[] operator can pass MVV along to functions
• getvariable[] operator can retrieve MVV

Whether and how much of the paren syntax to introduce on top of that base functionality can be a separate decision

[Jermolene]

Hi @btheado I'm seeing an error for the example above. I agree that there is a case to be made for angle brackets in filter arguments to pass through MVVs. I won't be able to work on this immediately and so would welcome a PR if you wanted to tackle it?

[btheado]

Thanks @Jermolene.

I won't be able to work on this immediately and so would welcome a PR if you wanted to tackle it?

I might be able to take a look this weekend.

I'm seeing an error for the example above

Hmm, I don't see an error. Here is a share site link for which I don't see an error.

Any feedback on my original question? I don't understand the need for paren syntax for attributes:

Is there a better example which shows the need for ((items)) syntax?

[Jermolene]

Thanks @btheado.

Hmm, I don't see an error

Entirely my fault, I was inadvertently testing on v5.3.8

Any feedback on my original question? I don't understand the need for paren syntax for attributes:

Apologies, I agree, I think it is redundant now.

[btheado]

I might be able to take a look this weekend.

I have taken a look and have gotten pretty stuck. I thought that changing the if(operand.variable) condition below to being mostly the same as the if(operand.multiValuedVariable) condition would be a good approach:

TiddlyWiki5/core/modules/filters.js

Lines 291 to 309 in 111a168

	} else if(operand.variable) {
	var varTree = $tw.utils.parseFilterVariable(operand.text);
	operand.value = widgetClass.evaluateVariable(widget,varTree.name,{params: varTree.params, source: source})[0] || "";
	operand.multiValue = [operand.value];
	} else if(operand.multiValuedVariable) {
	var varTree = $tw.utils.parseFilterVariable(operand.text);
	var resultList = widgetClass.evaluateVariable(widget,varTree.name,{params: varTree.params, source: source});
	if((resultList.length > 0 && resultList[0] !== undefined) || resultList.length === 0) {
	operand.multiValue = widgetClass.evaluateVariable(widget,varTree.name,{params: varTree.params, source: source}) || [];
	operand.value = operand.multiValue[0] || "";
	} else {
	operand.value = "";
	operand.multiValue = [];
	}
	operand.isMultiValueOperand = true;
	} else {
	operand.value = operand.text;
	operand.multiValue = [operand.value];
	}

i.e. like this:

diff --git a/core/modules/filters.js b/core/modules/filters.js
index 2cfa60914..f36175dcc 100644
--- a/core/modules/filters.js
+++ b/core/modules/filters.js
@@ -288,11 +288,7 @@ exports.compileFilter = function(filterString) {
                                                var currTiddlerTitle = widget && widget.getVariable("currentTiddler");
                                                operand.value = self.getTextReference(operand.text,"",currTiddlerTitle);
                                                operand.multiValue = [operand.value];
-                                       } else if(operand.variable) {
-                                               var varTree = $tw.utils.parseFilterVariable(operand.text);
-                                               operand.value = widgetClass.evaluateVariable(widget,varTree.name,{params: varTree.params, source: source})[0] || "";
-                                               operand.multiValue = [operand.value];
-                                       } else if(operand.multiValuedVariable) {
+                                       } else if(operand.variable || operand.multiValuedVariable) {
                                                var varTree = $tw.utils.parseFilterVariable(operand.text);
                                                var resultList = widgetClass.evaluateVariable(widget,varTree.name,{params: varTree.params, source: source});
                                                if((resultList.length > 0 && resultList[0] !== undefined) || resultList.length === 0) {
@@ -302,7 +298,7 @@ exports.compileFilter = function(filterString) {
                                                        operand.value = "";
                                                        operand.multiValue = [];
                                                }
-                                               operand.isMultiValueOperand = true;     
+                                               if (operand.multiValuedVariable) operand.isMultiValueOperand = true;
                                        } else {
                                                operand.value = operand.text;
                                                operand.multiValue = [operand.value];

But the current operand.variable code can never result in an empty list for operand.multiValue. With the above change, it can now be empty.

Having it empty in some case is no longer backwards compatible. For example, before the change [<doesnotexist>] would return one empty string item whereas after the change it returns no items at all.

This incompatibility is immediately apparent in the tiddlylwiki core as the $:/core/ui/ViewTemplate/title no longer renders the view toolbar buttons. They are just missing from every tiddler in the story river.

I'm not sure what the next step is for this. Maybe it is a failed idea.

[Jermolene]

I have taken a look and have gotten pretty stuck.

Thanks @btheado

Having it empty in some case is no longer backwards compatible. For example, before the change [<doesnotexist>] would return one empty string item whereas after the change it returns no items at all.

Ouch, yes, the behaviour here is horribly counter-intuitive and an enormous constraint.

I'm not sure what the next step is for this. Maybe it is a failed idea.

Perhaps, but it definitely has not been a waste of time. It has clarified that this is one of those annoying conservation of frustration situations.

Maybe the best thing we can do for the moment is to explicitly say in the release notes that we reserve the right to change the behaviour of edge cases and subtleties of MVVs in a subsequent v5.4.x release, at which point MVVs would be given all the usual backwards compatibility guarantees.