No problem. I think there is no difference from recursion point of view! But let one of developers perhaps @jeremyruston reply this specific question.
Side note: Like @Scott_Sauyet I believe @Mark_S just jocking with “You know why function is called function? Because it’s recursive! 
”
Man, I wish somebody had replied that to me right away. Because this was turning into a real “cognitive overload” nightmare for me. Better late than never.
I think the OT and the resulting banter is a result of the ambiguity in the terms adopted in 5.3.0 which I tried to influence during its design, the following terms are all quite similar in English and quite specific in TiddlyWiki and carry with them baggage inherited from other languages.
For those involved with the development of parametrised transclusions it may all appear self evident, but for most users it will not. The “horse has bolted” on this naming, but now we need to provide informed overviews and definitions to assist in adoption and understanding.
I understand the question “Why is Function Called Function?” but would suggest the safest answer is “because it was chosen”. Similarly with other new terms. For example “Why is Procedure Called Procedure: perhaps because it not a called macro?”
Now we need to construct an understanding of what these terms meaning within TiddlyWiki and how we use them.
Here is my attempt
.filteroperator”\define macros.Ways to remember these may be;
Finally, with the exception of widgets, all of the above exist as variables so we typically use the form <<variable>> or <<macroname>>,
<$macrocall $name=macroname widget.<$transclude $variable="proceedurename" widget<$proceedurecall or $call widget.What do you think?
Perhaps these names show their heritage from programming languages in general, but they are not specific to particular languages. While not universal, they are extremely common programming terms. I’m still not well-versed enough in the parameterized transclusion to know exactly how well these constructs match the common names, but for perspective, here’s a programmer’s view of what the terms mean. (Caveat: I’m a working programmer, not a programming language experts; their views may be slightly different.)
A function is a callable snippet of code that accepts parameters and returns one or more values.
A procedure is a callable snippet of code that accepts parameters and performs some actions.
A macro is a reusable snippet of code that will be substituted in place of its name before the code is run. It may also accept parameters, whose values may also become part of the expanded source code.
A widget is an encapsulated bit of data and behavior, generally associated with a graphical user interface. Parameters might be used in their creation, but are less central to them.
A parameter is the association of a name used in a callable snippet of code with the value passed when that snippet is invoked.
Functions and procedures are ephemeral. Although they can be called over and over, they don’t hold any state. (This is not technically true – see closures – but is close enough for these purposes.) The difference between them is that procedures are about taking actions, and functions about returning values; but many languages (including JS) conflate these two notions. Macros are a bit different, as at runtime, after the substitution has occurred, their expansions become part of the source code. And widgets are different still, as they hold run-time state and have observable UI behaviors.
Again, it’s not clear enough to me how closely the new TW terms associate with these notions, but I think macro and widget are already close matches; I would expect function and procedure to do so too, but haven’t learned enough to confirm that.
Although I find these new tricks in TiddlyWiki very confusing, I see how the great majority (or everybody except me) will appreciate functions because it helps with conciseness.
To illustrate the difference (between function in the OP and the snippet below), showing why most should appreciate functions over macros (I much prefer this approach because of the verbosity; it is clearer to me what is going on):
\define eff(date) [!is[system]]:filter[get[created]split[]first[4]join[]compare:number:gt[$date$]]
<$macrocall $name="list-links" filter=<<eff 2022>>/>
So far, from what I’m seeing, I’m not sure functions and procedures in TW ought to be defined that way.
Each of them (function, procedure, macro) seems to be a reusable snippet of text that will be substituted in place of its macro/function/procedure reference before a tiddler is rendered. A macro/function/procedure reference may also include parameters, whose values will become part of (or play a part in) the resulting substitution .
(Which doesn’t surprise me because TiddlyWiki is a transclusion heavy-weight champ.)
The only difference I’m seeing is in the ways they are constructed and where/how they are applied.
There’s probably nothing inherently horrible about framing an understanding of functions and procedures in TW as one would with an imperative programming language, but that might make troubleshooting problems awkward/challenging. When doing something extraordinarily complex, whatever behavioural expectations one may have (from an imperative programming language perspective) could be confounded a bit if one isn’t thinking with a (pristine?) “transclusions-grounded” mindset.
But all of these thoughts of mine could be complete bunk if I’m completely misunderstanding functions and procedures. For all of the ranting/raving and fawning over them, I really don’t get it.
No need to use $macrocall, you can use subfilter like below
<<list-links "[subfilter<eff 2022>]">>
If this date is given through a variable or transcluded from a tiddler field how your macro will work?
Assume the date is stored in mydate field in current tiddler. The function will handle this easily like below
<<list-links "[.f{!!mydate}]">>
I never use the list-links macro. Whenever I need something like that, I build the thing that does what I need and works how I need it to work. (and displays all of the pieces I need to see to understand what I’m looking at; it it has all of the puzzle pieces that are in my head, I recognise it; if it is missing pieces, then it does not match what is in my head, and I get into paralysis by analysis trying to figure out what is missing.)
Multiple cognitive problems over here, so how I process and organise things will never make sense to anybody else. When I don’t see all of the pieces in a way that I can process (that matches the intertwingled mess in my head), I do not understand what I’m looking at.
For the giggles though, just because it is a fun exercise…
Assuming the tiddler containing the following TWscript is the one with the “mydate” field with a value of 2020:
\define effList(date)
<$macrocall $name="list-links" filter="[tag[HelloThere]]:filter[get[created]split[]first[4]join[]compare:number:gt[$date$]]"/>
\end
!! One
<$macrocall $name="effList" date={{!!mydate}}/>
!! Two
<<effList 2020>>
<<effList 2020>> is much easier on my head (easier to remember syntax) than <<list-links "[.f[2022]]">>
<$macrocall $name="effList" date={{!!mydate}}/> is verbose, but the syntax is still much easier for me to remember than <<list-links "[.f[2022]]">>
I am not trying to discourage folk from getting all hyped-up on these new TW features. The features just do not offer anything of benefit to me. They are just gumming up the works in respect to how I process and recognise things.
If anything, I’m largely frustrated because I want to get excited, but it is all a semantically overloaded cognitive gong-show for my abilities.
I hope that in time, once we digest the meaning and values we may have some methods that can help. There are features within the current version such as subfilters, which are only improving from 5.3.x, that stand to make thinking about filters simpler.
Anything is possible at any time.
However, mine are dysfunction-avoiding necessities. I only make a switch/upgrade when it hurts too much not to switch/upgrade.
If anybody takes a deep-into-the-weeds look at anything I’ve done, I use only a particular subset of TW features in 5.2.3 and earlier, because I much prefer master a small subset of features that let me do all I need, rather than be distracted by too many choices and be master of none.
Travel light (use only what’s necessary, and ignore the rest) and use the “simplest” features (to me: the core “rudiments”, they are the fundamental blocks from which all other things can be built.)
I like to learn and embrace new things, but my too-long-for-one-lifetime list has way more wildly interesting and useful stuff in it.
@Charlie_Veniot and all
I understand, I will only encourage you to look at something new if I think it may help you. As I have said before these issues tend to be on a spectrum, one of which I may also be on, perhaps just at the other end 
et al
In this particular case I am interested in what we may call “named filters”, or “named filter operators”. That is, design a simple filter or operator and give it a name. Then later reuse it and if necessary combine with others, such that they remain simple.
Oh for sure, if and when it helps me do something that hurts too much to do otherwise, then I’ll be on the latest TW like white on instant rice.
I’m not a fan of subfilter, and will only use it if I really don’t have any choice.
The sample TWscript I presented, I see the parts clearly. "[subfilter<eff 2022>]" is too messy for me (the syntax is too busy.)
I need to use $macrocall. It makes sense to me. The parts of it are clear (well delineated, non-distracting.)
I do not process things like anybody I know of. I’ve carefully curated the TiddlyWiki features to the ones that work well for me and I have banished those that don’t fit the way I operate (they are sticks in my wheels and mud for my wheels to get stuck in).
A wonderful example by @xcazin has been given in GitHub which is quite interesting.
See
\function .frame(begin:"[[",end:"]]")
[addprefix<begin>addsuffix<end>]
\end
<$list filter="""[[Hello].frame[]]
[[Hello].frame[<<],[>>]]
[[Hello].frame[{{],[}}]]
[[Hello].frame[`],[`]]
[[Hello].frame['],[']]
[[Hello].frame["],["]]
""">
<$text text=<<currentTiddler>>/><br>
</$list>
Produces
[[Hello]]
<<Hello>>
{{Hello}}
`Hello`
'Hello'
"Hello"
The .frame custom filter operator created by function, wraps your input into given chars.
To give a try
Give your example, if you made a different example
This will be nice worked into an editor toolbar button.
A minor change turns a function into an operator by having a period “.” anywhere in the name, not just a leading period. As a result I threw this togather on the prerelease.
\function .has.changed() [all[shadows+tiddlers]haschanged[]]
`{{{ [.has.changed[]] }}}`
{{{ [.has.changed[]] }}}
<hr>
* `{{{ [<.has.changed>] }}}` {{{ [<.has.changed>] }}}
* `<<.has.changed>>` <<.has.changed>>
* `<$text text=<<.has.changed>>/>` <$text text=<<.has.changed>>/>
This illustrates how even a function can be referenced as a variable, like a macro.
Notes
<<.has.changed>> returns the plain text result and it is no different from using the text widget.
<$text text={{{ [<.has.changed>] }}} />Wether or not you concider the new function a function in a programing sence it must be emphasised it is as far as TiddlyWiki filters are concerned. It is not a generic function, but it is one that unleashes filters as functions not to mention making custom filter operators with parameters.
A discussion was taking place here among @jeremyruston, @Arlen22, and me regarding the use of functions. (see [BUG] Functions Eat Newline Characters · Issue #9052 · TiddlyWiki/TiddlyWiki5)
It seems functions donot respect the newline character, for example goto https://tiddlywiki.com (5.3.6) and enter below script into an empty tiddler
<$let newline= {{{[charcode[10]]}}}
data="a 10; b 20; c 30"
ptable={{{ [<data>split[;]] :map:flat[enlist-input[]join[|]addprefix[|]addsuffix[|]] :and[join<newline>]}}} >
<$transclude $variable=ptable $mode=block/>
</$let>
This correctly creates a table like
Then modify the above code and convert ptable variable into a function as below
\function ptable() [<data>split[;]] :map:flat[enlist-input[]join[|]addprefix[|]addsuffix[|]] :and[join<newline>]
<$let newline= {{{[charcode[10]]}}}
data="a 10; b 20; c 30" >
<$transclude $variable=ptable $mode=block/>
</$let>
which results in
|a|10| |b|20| |c|30|
It seems the function eats the newline character.
Hi @kookma the confusion arises because the output of functions is not wikified when displayed with the <<fn>> syntax. Here is a simple example:
\function a() @@test@@
\procedure b() @@test@@
<<a>>
<<b>>
@kookma , this works for me.
\function ptable() [<data>split[;]] :map:flat[enlist-input[]join[|]addprefix[|]addsuffix[|]] :and[join<newline>]
<$let newline={{{[charcode[10]]}}}
data="a 10; b 20; c 30"
result=<<ptable>>
>
<$transclude $variable=result $mode=block/>
</$let>
The output of functions is not wikified when displayed with the <<fn>> syntax.
I don’t know much about wikitext. If I want to understand how it works I either just play around until it works or I read the javascript parser to figure out how it works. So I don’t have much wikitext experience.
What I do know is that {{{ ... }}} is a filter parameter syntax, and the result of running that filter is assigned to the variable ptable in your first example. So when we get to the transclude widget, it’s looking at the result of having run that filter, not at the filter string itself.
<$let newline= {{{[charcode[10]]}}}
data="a 10; b 20; c 30"
ptable={{{ [<data>split[;]] :map:flat[enlist-input[]join[|]addprefix[|]addsuffix[|]] :and[join<newline>]}}} >
<$transclude $variable=ptable $mode=block/>
</$let>
In the same way, if you want to extract that filter out into a function, you need to run the function by setting a second variable to <<ptable>> in order to get the result of the filter the same way {{{ … }}} did inline. So by the time $transclude sees it in my example, it’s again the result of running that filter.
\function ptable() [<data>split[;]] :map:flat[enlist-input[]join[|]addprefix[|]addsuffix[|]] :and[join<newline>]
<$let newline={{{[charcode[10]]}}}
data="a 10; b 20; c 30"
result=<<ptable>>
>
<$transclude $variable=result $mode=block/>
</$let>
If you replace function with procedure in your second example, it literally just prints the filter string. I would have expected function to do that as well.
\procedure ptable() [<data>split[;]] :map:flat[enlist-input[]join[|]addprefix[|]addsuffix[|]] :and[join<newline>]
<$let newline= {{{[charcode[10]]}}}
data="a 10; b 20; c 30" >
<$transclude $variable=ptable $mode=block/>
</$let>
That was the thought process I used. I still am not exactly sure what people mean by saying the output of functions is not wikified, or that dom nodes are not included. But if I directly call the macro beside the transclude widget, you also get the undesired result.
Since the original filter result (not the filter itself) was being assigned to a variable using $let, moving that code into a function would require also assigning the result to a variable instead of attempting to transclude it. I guess it is a quirk of functions that when passed a filter, they run it??? I guess that’s why procedures were introduced.
So unlike Jeremy and Scott, I’m not recommending to use procedures because I can’t get them to execute the filter in the same was as the {{{ ... }}} does inline or the function does when used in the same way.
Searching “triple curly braces” on tiddlywiki.com may give you more information.
Thank you for the clarification, Arlen. I am accustomed to using varname={{{ some filter }}} to bypass the costly wikified process suing $wikify. When filters are involved, I attempted to replace the lengthy triple curly brackets with semantic shorter functions, which worked effectively. As always, I used the functions with variables, but this is the first time I have utilized them as an attribute.
I also discovered that official documents describe these behaviours, see TiddlyWiki v5.3.6 — a non-linear personal web notebook