And a variant (worked out before recent reply by @Justin_H) that does not rely on dynamic tables, which works at tiddlywiki.com to illustrate principle. (Using named variables at each level can help keep the code easy to troubleshoot.)
<$list filter="[tag[HelloThere]]" variable="maintid">
<$link to=<<maintid>>/><br>
<$list filter="[<currentTiddler>fields[]prefix[t]] -text" variable="fieldname">
<li><<fieldname>>: {{{ [<maintid>get<fieldname>] }}}</li>
</$list>
</$list>
Or with slightly different styling:
<$list filter="[tag[HelloThere]]" variable="maintid">
<$link to=<<maintid>>/><br>
<ul style="list-style: none">
<$list filter="[<currentTiddler>fields[]prefix[t]] -text" variable="fieldname">
<li>''<<fieldname>>'': <$text text ={{{ [<maintid>get<fieldname>] }}}/></li>
</$list>
</ul>
</$list>
Just for fun and because @Scott_Sauyet showed a variant, I thought I would show a variant form using functions.
\function tagged.list(tag) [tag<tag>]
\function t.fields() [fields[]prefix[t]] -[[text]] -[[title]]
\function fieldname-title() [<fieldname>sentencecase[]addsuffix[: ]]
\function fieldname-value() [all[current]get<fieldname>]
<$list filter="[tagged.list[HelloThere]]">
<$link/>
<ul>
<$list filter="[<currentTiddler>t.fields[]]" variable=fieldname>
<li><<fieldname-title>> <<fieldname-value>></li>
</$list>
</ul>
</$list>
I think making a new filter for [tag[HelloThere]] is a bit of over-engineering and even increases complexity instead of simplifying things. It will also make the code harder to maintain.
It was only an illustration, that filter could be extended To select based additional critera.
eg \function tagged.list(tag) [tag<tag>has[title]]
I like it! One minor caveat. For similar reasons to what you said in Struggling with Procedures,
can I suggest you leave the bold wikitext out of this field, then you get to choose it when you display it, not when you set it.
I think the addition of the colon addsuffix[: ] belongs in the formatting, not in the general-purpose function. So:
...
\function fieldname-title() [<fieldname>sentencecase[]]
<!-- ^---- remove addprefix -->
...
<li><<fieldname-title>>: <<fieldname-value>></li>
<!-- ^---- here, not in function -->
...
On another topic, I know you’ve been playing with functions a lot. One thing that I know is common in TiddlyWiki that bothers me is nonlocality. It’s demonstrated above by the fact that the calls to fieldname-title and fieldname-value do not pass the field “fieldname”. Instead they reach out to the environment they’re running in to pick up these variables. This would be fine in a nested-function situation, but it bothers me when that doesn’t happen.
Whether this bothers others or not, it’s something I’d like to avoid in my own work. But is there an easy way to pass variables as parameters to the function calls? What I would like is something like this:
\function tagged.list(tag) [tag<tag>]
\function t.fields() [fields[]prefix[t]] -[[text]] -[[title]]
\function fieldname-title(fld) [<fld>sentencecase[]]
\function fieldname-value(fld) [all[current]get<fld>]
<$list filter="[tagged.list[HelloThere]]">
<$link/>
<ul>
<$list filter="[<currentTiddler>t.fields[]]" variable=fieldname>
<li><<fieldname-title <<fieldname>> >>: <<fieldname-value <<fieldname>> >></li>
</$list>
</ul>
</$list>
Put that fails syntactically. Is there a simple way to do this?
@Scott_Sauyet thanks for your considered feedback.
The difference between us is my non-locality is supported by standard variable names such as I always code for acting on currentTiddler, and always use filename both in the function name and variable. In a sense it may be non-local but it becomes global.
<<function var:"val">>
[function[val]]>> [function<varname>,{!!fieldname}]>> etc…
I remember 
Here is my rewrite of your code, the way I would do it. Changed the tag for more data. The prior example was to replicate the source in the topic.
\function tagged.list(tag) [tag<tag>]
\function op.fields() [fields[]prefix[op]] -[[text]] -[[title]]
\function fieldname-title() [<fieldname>sentencecase[]]
\function fieldname-value() [all[current]get<fieldname>]
<$list filter="[tagged.list[Filter Operators]]">
<$link/>
<ul>
<$list filter="[<currentTiddler>op.fields[]]" variable=fieldname>
<li><<fieldname-title>>: <<fieldname-value>></li>
</$list>
</ul>
</$list>
tag. List[] is unnecessary but it demonstrates a parameter<fieldname>
[Post script]
One area I am not sure of yet is if I want to paramatise a suffix to an operator eg in format:titlelist[] the titlelist, it can still be done with the \define` and a substitution. PPS Eric gave the answer here Can the suffix of an operator be given a variable? substitution in the backtick attributes.
PPPS;
Typicaly function returns only the first non-blank value (like cascades) but they can also be used to store lists or concatenate values with +[format:titlelist[join[ ]] OR +[join[ ]]
I know the code is only an example for a creative way to use functions, but for this concrete example with the filters and fields used, I would create a table and render the field values instead using them as plain text.
I think a table would be easier to read.
\function f.taggedList(tag) [tag<tag>]
\function f.opFields() [fields[]prefix[op]] -[[text]] -[[title]]
<$list filter="[f.taggedList[Filter Operators]]">
<table class="tc-max-width">
<tbody>
<tr>
<th colspan=2><$link/></th>
</tr>
<$list filter="[<currentTiddler>f.opFields[]]" variable=fieldname>
<tr>
<td><<fieldname>></td><td><$transclude $field=<<fieldname>>/></td>
</tr>
</$list>
</tbody>
</table>
</$list>
I did also rename the functions. For some time now I do use a special function format, to be able to easily identify functions used in filters or as variables. The format is like this: f.functionName for if the function belongs to a global procedure eg: myProc I use f.myProc-functionName, which can be a bit “clunky”, but will avoid naming conflicts for global function names.
Functions can also be used using the function-operator as in the following code. That mechanism is important, if a function can get more than 1 parameter. See the parameters of the first list-widget
\function f.taggedList(test, tag) [<test>] [tag<tag>]
\function f.opFields() [fields[]prefix[op]] -[[text]] -[[title]]
<$list filter="[function[f.taggedList],[non existing Title],[Filter Operators]]">
<table class="tc-max-width">
<tbody>
<tr>
<th colspan=2><$link/></th>
</tr>
<$list filter="[<currentTiddler>function[f.opFields]]" variable=fieldname>
<tr>
<td><<fieldname>></td><td><$transclude $field=<<fieldname>>/></td>
</tr>
</$list>
</tbody>
</table>
</$list>
just some thoughts
-mario
Yes, I agree about using tables, I was responding to the syntax a functions issue, and did not want to make it more complex.
function[] format and prefer to used the custom.name[]
This is what I mean by minimal table
<table style.width=".. >
<$list filter="...
<tr><td>Row name</td><td>row value</td><tr>
</$list>
</table>
It is interesting seeing how others make tiddlywiki their own.
I am slowly accruing a set of functions, some procedures and some widgets and a set of naming standards, to build a set of global features, I may use in all my wikis, eventually, but I also like each solutions to be stand alone. Plug compatible you could say, In many ways extensions to tiddlywiki. So I am happy to build a codex, or meta language I can remember, so I don’t need to check the syntax as often (because that annoys me).
If you’re going to do that, I think that a very slight tweak would improve readability a lot, using a single table. The simplest way to do that would just be to interchange the outer <$list> widget with the <table> tag. Alternate Table Demo.json (598 Bytes):
\function f.taggedList(tag) [tag<tag>]
\function f.opFields() [fields[]prefix[op]] -[[text]] -[[title]]
<table class="tc-max-width">
<$list filter="[f.taggedList[Filter Operators]]">
<tbody>
<tr>
<th colspan=2><$link/></th>
</tr>
<$list filter="[<currentTiddler>f.opFields[]]" variable=fieldname>
<tr>
<td><<fieldname>></td><td><$transclude $field=<<fieldname>>/></td>
</tr>
</$list>
</tbody>
</$list>
</table>
I might then go back and left-align the <th>s and increase their font size and padding. There are plenty of other ways we could achieve this, but this one is especially simple. However, the separate tables in your version are a little nicer. The simplest way to do this is to fix the width of the first column.
Alternate Table Demo 2.json (621 Bytes):
<td style="width:20%;"><<fieldname>></td><td><$transclude $field=<<fieldname>>/></td>
This of course has the problem that we have to pre-guess the likely width of that column, whether it’s as a percentage or a fixed width. A single table makes that easier.
Either way, I find consistent-width columns across parallel tables much easier to read.
global is the ultimate in non-local. And it’s what I’m hoping to avoid. In my day-job, I push functional programming over other paradigms. One tenet of FP is that functions are pure, relying only on their parameters and not any global or other non-local environment for their functioning. That’s why I asked this:
What I was really looking for is a fix for this:
\function fieldname-title(fld) [<fld>sentencecase[]]
<$list filter="[<currentTiddler>t.fields[]]" variable=my-field>
<<fieldname-title <<my-field>> >>
<!-- ^^^^^^^^^^^^--- This is illegal syntax --->
</$list>
Is there a simple replacement for that? One that doesn’t involve depending on global or other non-local variables in the function?
Right, and I’m not very happy with that either. For some reason, it bothers me less, but I would like to address that at the same time. I want my functions to know nothing about the outside world not passed to them as parameters (or as the current context when used as operators.)
Adding those parameter names is precisely what I’m trying to support. I know this is outside the norm when using TW, but is it possible to do it in a user-friendly way?
Can they also be called with parameters when they’re just used like variables, not inside a filter run? To repeat myself, I’m trying to solve this:
\function fieldname-title(fld) [<fld>sentencecase[]]
<$list filter="[<currentTiddler>t.fields[]]" variable=my-field>
<<fieldname-title <<my-field>> >>
<!-- ^^^^^^^^^^^^--- This is illegal syntax --->
</$list>
Is there a simple replacement for <<my-field>> here?
With the desire for complete clarity and documentation on the subject of filter functions;
There are a number of replacements for the non-working <<fieldname-title <<my-field>> >>
...fieldname-title[literal]... or ...fieldname-title<my-field>... or ...fieldname-title{!!my-field}...
{{{ [fieldname-title<my-field>] }}}
<$text text=`${ [fieldname-title<my-field>] }$`/>
On local, global etc…
To me this is a non-issue, not simply because I do like to globalise reusable functions in effect building a meta language but because we can no go ultra-local if we want, in procedures and custom widgets, even tiddlers you transclude.
This is because we can easily write a procedure or custom widget that has nested in it any of the following;
\define macro(p) $p$ with substitutions\procedure .. using parameters or variables available to it\function .. using parameters or variables available to itSuch “nested pragma” and any other content including the $parameters widget and its capabilities all exist only inside the “procedure and custom widget” n which it is defined.
When to go global?
As I design a procedure or custom widget and write new macros / procedures / functions, nested within it, I am always thinking about writing globally relevant solutions sometimes I;
Want to be ultra local?
Nesting your Tiddlers, macros, procedures and functions within your own procedure, custom widget or transcludable tiddler, is the first approach to ultra local but the $parameters widget also supports this. Just consider that the parameters widget;
Why ultra local? - because it all ceases with </$parameters>
Regards
Tony
I just want to comment specifically on this.
As the designer you can choose the best approach to suit your coding style.
If I were writing code for an application, such as Excel, or an application delivered in the cloud, I may very well stick religiously to this approach (possibly by order of my employer).
However;
Depending on what you intend to do with your tiddlywiki but coding within tiddlywiki,
I think it is fair to argue another paradigm is warranted.
And I thank you for that.
We have some fundamental disagreements here, and I thank you for your patience regarding them.
[quote=“TW_Tones, post:26, topic:8987”]
What I really wanted to know was if there was a replacement for the non-working <<my-field>>. We can call a function, as your earlier example showed, by just <<fieldname-title>>, assuming that any values it needs are in global (or some other outer) scope. I was wondering if we could pass parameters to them in the same format.
My original, completely broken code is at: Attempt 1.json (577 Bytes)
I’m not sure how you’re suggesting I’d use this. They would also have to include a . character in their name to be used like this, right? I did that in the examples below, but I’m not quite sure what you’re suggesting as a replacement for my broken code.
This gets the appropriate content, but wraps it in unwanted links: Attempt 2.json (582 Bytes).
If I wrap this in a <$text>-widget (like this: <$text text={{{ [fieldname.title<myfield>] }}}/>) it does work correctly: Attempt 3.json (610 Bytes). But that’s getting pretty far from <<fieldname.title ??my-field?? >>.
Again that works but is fairly far from what I would love to have. Attempt 4.json (609 Bytes)
I think we may be talking past each other here. I’m not particularly objecting to $:/tags/Global. For more complete modularity, we might prefer \import, but I am not worried about that at this stage in my TW understanding.
What I object to is something like this:
\function my-value() [all[current]get<fieldname>]
To understand how to use this, you have to look beyond the signature of the function, and understand its entire body, which might span hundreds of lines. You have to find all free variables (such as fieldname here) and then you have to ensure that when you call the function, those free variables have been defined in some scope that encloses your call. If you are calling multiple functions, you need to find a way to ensure that the name of those free variables do not conflict, but that they are the same if the same value needs to be passed to multiple functions.
Compare that to
\function my-value(fieldname) [all[current]get<fieldname>]
Here we don’t need to know anything about the body to know what we have to pass when we call the function. And we can pass the same value to different functions or pass different values to two different functions, even though both function use the parameter fieldname.
It is precisely this independence of functions that lets me “build a meta language” out of reusable functions.
Yes, I use much the same thinking, but the issue I brought up was about free variables, not function visibility.
For me, I’ve very happy with the Functional/Declarative paradigm. To my mind, t’s actually a very good fit with TiddlyWiki, especially compared to an Object Oriented/Imperative paradigm:
Similar to FP, which has a few datatypes and many common operations on them – and unlike OO, which has many datatypes, each with a few operations – TW works mostly with tiddlers and lists of strings, especially lists of tiddler titles. And it has many operations on these types.
The filter operations act very much like monadic structures.
Operations tend to be declarative, not imperative. It feels more like SQL than like Java.
There is very little imperative code of any sort in my wikitext. I’m not telling the computer “do this, then do that, and afterwards, do this other thing.” And when we do need to do anything like this, we usually end up burying it in JS tiddlers, comfortably out of sight.
And of course note that I started this sub-thread by saying
While I’m quite happy discussing competing programming paradigms, what I’m really interested in knowing is whether the one I would prefer to use is well-supported. Is there a simple way to pass arguments to a short-form function call, some syntax to replace the ??param?? to pass the parameter param to the function my.function in this
<<my.function ??param?? >>
I do too, because I believe in all sincerity, I have given an answer you your question as follows a number of times;
I am keen to understand and overcome where we are at “conceptual odds” I will reflect more on your last reply and respond later.
Just to if it helps
I call functions this way, as if it was a variable, when I want the result displayed. It also displays the result in text.
<<functioname p1:"value">>
<parmaname>
However;
{{{ filter }} and backtick attributes, as well as custom operators where we need the name to contain . as we do if defining `custom. Widget’s.As I said;
I am keen to understand and overcome where we are at “conceptual odds”, I will reflect more on your last reply and respond later.
You’ve given me any number of alternative ways to do what I’m trying to do, of varying degrees of simplicity and complexity. But what I’m asking is a simple yes-no question, where a “yes” should be backed up by a simple syntax demonstration, and a “no” will lead me to some minor disappointment and to thinking about which of the many alternatives to the larger construct we’ve seen I should adopt.
As specifically as I can ask it, in this, can the highlighted bit in this:
<<functioname p1:"value">>
<!-- ^^^^^^^ -->
that is, the characters ", v, a, l, u, e, " be replaced by a simple reference to the local variable my-field so that its value will become the argument to the function being called?
But where I thought we were talking past each other actually had to do with how we were using global and local. I was using it to discuss the scope of function parameters. I think you were using it to discuss the visibility of functions. They’re quite different.
<<functioname p1:"value">> is the shortcut form and can’t be used to do as you wish.
<$macrocall $name=function p1=<<my-field>>/>
OR
<$transclude $variable=function p1=<<my-field>>/>
And I answered, just as it is for macros, procedures and always with widgets.
{{{ [function<my-field>] }}}
I hope this helps.
Thank you. That’s what I’d come to expect, even if it’s disappointing. I’ll figure out which syntax appeals best.
While that would probably be my second choice, it introduces unwanted links.
But thanks too you, I have plenty of other options.
It does, very much. As always, thank you very much for your help.
Avoiding links is a key value of functions in my view, avoiding the verbose text widget.
<$.my.func p1=<<my-field>>/>
<<my.proc my-var>> OR <<my.proc my-fieldname>>
my-var={{{ [<my-var>getvariable[]] }}}
my-fieldname={{{ [all[current]get<my-fieldname>] }}}
Thank you very much. I look forward to playing with both. I can’t believe that after all my TW activity in the last 18 months, that I have yet to create a custom widget!