[v5.3.2-pre] Peeking at the Conditional Shortcut Syntax

[CodaCoder]

@etardiff

because it does inform me when it fails

Which, IMV, is not “brittle”, in practice or otherwise.

@etardiff

But I suppose it could create some “unexpected” errors, since core widgets are generally fairly apathetic to whitespace.

True. Perhaps text node walking/traversing was difficult back when <$if>/<$else> was introduced. But Evan does make it crystal clear in his docs.

[Springer]

@Flibbles

if someone is making a chain of if-else statements, they’re not using Tiddlywiki the way it should be used. It’s about templates, not imperative programming.

Hi @Flibbles,

As an intermediate user, I do enjoy crossing thresholds of “getting it” about how TW “wants” me to approach things. I’ve absorbed the habit of using a <$list> widget — often with limit[1] in its filter — to accomplish display of conditional elements, and later I may refactor once I see the power of a template or cascade approach. It’s kinda cool, in an occam’s razor way. Like learning how to build out a whole circuit board with NAND gates.

Still, nearly every newbie here at the forum has a bit of a struggle with why <$list> counts as the right tool for the task they come here to ask about — given that what they want seems (to them) nothing like a “list”!

Meanwhile, the cascade mechanism is a tremendously powerful way of handling conditional matters, but it’s unwieldy for most ordinary tasks.

(Erring on the side of keeping certain complexities “in-tiddler” is understandably tempting for ordinary users who want most tiddler names to be nodes of meaning directly relevant to their project, and who want their “Recents” tab to track that recognizable project content, not little utility tiddlers that do work behind the scenes.)

I think the new <% if %> affordances (even if <% elseif %> feels a bit roundabout) hits a sweetspot of intelligibility (as well as preserving backward compatibility).

After all, displaying something conditionally is the kind of task that pretty much any beginner will need to do, and even for me, I suspect this new shortcut tool will make my future self less confused (and/or will free up time otherwise lost to writing out comments to my future self about what’s going on with each nested level of <$list> here).

Since the <% if %> toolset offers a cognitive shortcut, it’s optional whether to use it, right?

There’s often a tradeoff between encouraging “optimal” habits and letting people rely on gaurdrails, training wheels, etc. I think it’s reasonable for most US-market keyboard manufacturers to put qwerty labels on the keys, even though you really shouldn’t look at your hands while you type — and even though nobody should be using Qwerty anyway. ) At the risk of supporting bad habits for those who never get it about touch-typing (let alone what makes a keyboard layout a choiceworthy one), it’s still mighty helpful to those who haven’t yet streamlined their skills, and who might have more urgent projects at hand.

[CodaCoder]

My God, @Springer, post of the week (if not year). Exemplary.

And your cross-disciplinary analogies → NAND gates. Boole and De Morgan would be proud!

[jeremyruston]

Thanks @Flibbles, and apologies for my delayed response. Your comments are valuable feedback, and I’m delighted to receive them before it’s too late for this release.

I am happy to delay the release for a week to allow for further discussion if enough people think that it is warranted. It would be useful to hear from others who have concerns about this new syntax.

@Flibbles

Why not just have an <$else> widget? Why are we introducing all of this new syntax for something only power users will ever use?

An assumption within the core is that widgets are independent of their siblings. There is no lateral flow of variable values or anything else. I do recognise this as a limitation of the current design. A particular motivation to update the design would be to be able to compute running heading numbers in wikitext.

I know that Evan’s conditional plugin does work laterally in the widget tree, but I think it is brittle, and constrains what we can do with the widget tree.

@Flibbles

And if someone is making a chain of if-else statements, they’re not using Tiddlywiki the way it should be used. It’s about templates, not imperative programming.

I disagree. The core has many instances of the list widget being used for if-then-else logic, and they will all be much clearer once we’ve updated the templates to use the new syntax.

@Flibbles

Nor do I need to use these features, because they are just syntactic sugar.

That is correct.

@Flibbles

They don’t actually provide solutions to previously unsolvable problems.

The problem that the new syntax attempts to solve is readability and brevity.

@Flibbles

I say it’s not the way TiddlyWiki is supposed to be used because TiddlyWiki is designed for modularity, not conditional logic. So functionality is introduced through modules which get plugged in. Or tiddlers with tags that get looped in implicitly through filters. Tiddlers are intended to be small, almost atomic, and to be looped in declaratively. That’s why there was a big move away from data-tiddlers (or at least that’s what I thought.).

Eloquently put. It is certainly true that conditional logic is needed much less frequently in TiddlyWiki than in some other environments, but it is still very common.

@Flibbles

Big chains of if-elses inside of a single tiddler is often a sign that a refactoring may be called for. I might not always be right, but in the odd cases where I’m wrong, I don’t know if it’s worth having an entire syntax dedicated to supporting a TiddlyWiki anti-pattern.

I can’t agree with the characterisation of if-then-else as an anti-pattern because I think it is common and (with the new syntax) perfectly readable.

@Flibbles

I can’t use these new syntaxes because a lot of users of my plugins froze their Tiddlywikis at older versions.

It is a similar situation with the core with respect to JavaScript versions: to be as universal as possible we constrain ourselves to an elderly variant of JavaScript. But it is not an argument that JavaScript should not continue to advance.

[HistoryBuff]

I will say that I actually like the new conditional syntax. I find that it can make a macro or procedure much more readable and understandable (at least for me). Also, from a readability point of view I like the use of <% instead of <$ as it makes the conditional statements popout of the code for me (maybe this is partly due to the fact that I tend to do all of my code composing in Notepad++ where I’ve created a color coding scheme that suits me). This is all going to be extremely helpful for me when I come back to a certain procedure a year or two from now and am trying to remember what it does and why I did it. As a retired VHDL programmer, it just makes it more intuitive to me (fits the way my brain works).

I have only updated a handful of procedure with the new syntax, but I have had no issues with it whatsoever. It does just what I was wanting it to do. The only trip up for me was needing “elseif” instead of the “elsif” of VHDL that I was used to. It took me several minutes to find the muscle memory mistake.

[CodaCoder]

@HistoryBuff

I tend to do all of my code composing in Notepad++ where I’ve created a color coding scheme that suits me).

Perhaps you might share the scheme (in another thread) ?

@HistoryBuff

It took me several minutes to find the muscle memory mistake.

I have thousands of those if you ever run short

Absolute bane of my life the older I get.

[Scott_Sauyet]

@jeremyruston

I am happy to delay the release for a week to allow for further discussion if enough people think that it is warranted. It would be useful to hear from others who have concerns about this new syntax.

I think that’s a good idea. It’s much better to get this right than to do it immediately.

@Flibbles

I can’t use these new syntaxes because a lot of users of my plugins froze their Tiddlywikis at older versions.

That’s what versioning is for.

@Flibbles

Nor do I need to use these features, because they are just syntactic sugar. They don’t actually provide solutions to previously unsolvable problems.

Carried far enough, that logic will say that we don’t need TW because everything it does is simply build atop raw JavaScript. (Or we could go all the way down to NAND gates if we prefer.) The proper questions about syntactic sugar are about how much implementation complexity and how much conceptual space it adds versus how much simplification it introduces for users’ common cases.

To me this new syntax is absolutely a win. Note that I’m someone who strives in his JS to write expression-only code, and use no statements at all beyond high-level definitions. So I almost never use the built-in if-else constructs. But in TW, I’m using way too many <$list> invocations in my templates to hide and show content. These would all be improved with the new syntax.

[TW_Tones]

@TW_Tones

Folks, The 5.3.2 Prerelease now has a number of new features listed and one of these is quite different in form and possibly ease of use, that is the Conditional Shortcut Syntax.

• I have started this Topic to solicit initial observations and to encorage our broader community to have a look

Now the debate has being raised can we please return to my original Topic.

• I am exploring how and when to use it and its features or even bugs

Can we try and use this in the prerelease and share back here?

My Observations

• The conditional shortcut syntax adds to the methods we can use to conditionally display content including the list and reveal widgets (also custom widgets)
• being wiki-text themself we should be able to use this in macros, procedures, transclusions and custom widgets.
• They leverage the filter once again so filter writing skills are even more important.
• Except for a leading space before a filter <%if filter%> and <#elseif filter%> no spaces are needed inside the new “elements”, so they can be written more simply than the examples suggest.
• You do not need new lines when using this unless you want them in the result or for easy of reading.
• If something is wikified it can contain these new syntax elements, such as the caption field. You could have a short and verbose caption field.

[Scott_Sauyet]

@TW_Tones

Can we try and use [the Conditional Shortcut Syntax] in the prerelease and share back here?

I don’t have much to report except that it works as expected. In a heavily templated wiki, I have a great deal of conditional rendering of content in ViewTemplates. I replaced a number of <$list> widgets with the new syntax and it works as advertised. I haven’t had any need for elseif yet. In the plain if case, it feels slightly more verbose than <$list>...</$list>, but when I have an <$else>, it is less verbose. And in all cases, it is much more obvious what’s happening. I had far too many of scenarios like this:

<$list filter="[some[complex]filter[with]many<clauses>]">
Branch A
</list>
<$list filter="[some[complex]filter[with]!many<clauses>]">
Branch B
</list>

where the only difference between the two filters is the existence of a single !. The new syntax makes these much nicer.

[TW_Tones]

Yes the emptyMessage is the “else” in a list widget which is not as intuitive as the new syntax, the same can be said for the emptyvalue parameter of the set widget.

• The new custom functions are valuable here as well.

[CodaCoder]

@Scott_Sauyet

(Or we could go all the way down to NAND gates if we prefer.)

Watch your language, please. Wait until the children are in bed.

[CodaCoder]

@Scott_Sauyet

Note that I’m someone who strives in his JS to write expression-only code, and use no statements at all beyond high-level definitions.

Admirable.

Heads-up, everyone “Elvis has ENTERED the building”

@Scott_Sauyet

The proper questions about syntactic sugar are about how much implementation complexity and how much conceptual space it adds versus how much simplification it introduces for users’ common cases.

Zackly. Prior to the condition plugin, I was swamped in <$list> and <$reveal> widgets which brought zero semantic relevance to my code (probably negative meaning). Hence I jumped on it the moment I laid eyes on it.

Don’t get me wrong though, I can for a moment stand in @Flibbles shoes and see where he’s coming from. But they don’t actually fit me. I couldn’t wear them all day – knowwhatImean?

[CodaCoder]

Yeah, sorry Tones, this has drifted quite a bit…

I’ve tested everything I want to do on the pre site. It works like a charm → NFF!

Once it’s released, I’ll take the same approach as I am doing with \define → \procedure, change them when I see them, because a total rewrite is simply not possible.

[TW_Tones]

I am not in such a rush to rewrite unless there is a compelling reason because we do have a commitment to backwards compatibility. I suppose I am exploring where and when we will be compelled to rewrite our code and when to do so, such as when updating or maintaining.

• Sometimes maintanence is about making code easier to read or modify which helps all users including ourselves.
• including training and supporr.

Of course there are also a lot of options to be explored for how we develop new solutions.

• especialy improved and innovative methods

[TW_Tones]

@pmario

I think verbosity wins in the long run, even if it is more to type.

Actually I am not worried about extra typing, I am more worried by the extra reading. Especially when it reduces readability. For me [~[]] reads as current tiddler and gets out of the way of the rest of the filter.

Unfortunately this only works as a variable <<~>> {{{ [<~>] }}} unless you add a . to make it a custom operator;

\function .~() [all[current]]

<<.~>>
{{{ [<.~>] }}}
{{{ [.~[]] }}}

• I am not sure if this is better or worse.

@Flibbles

Why not just have an <$else> widget? Why are we introducing all of this new syntax for something only power users will ever use?

• If you have used Evans formulae plugin you will know it is very powerful and it is not a legacy to damage.
• In am not certian where we had the legacy <$else>

@Springer

Meanwhile, the cascade mechanism is a tremendously powerful way of handling conditional matters, but it’s unwieldy for most ordinary tasks.

• This value is diminishing somewhat in everyday filters, now that, functions and backticks for attribute values return only the first result that matches, as a result you can have a list of conditions with the first matching like a cascade result.
• Not withstanding its use in the cascade mechanisms

@jeremyruston

I am happy to delay the release for a week to allow for further discussion if enough people think that it is warranted. It would be useful to hear from others who have concerns about this new syntax.

• I don’t have any trouble with this feature, But I don’t like the changes to the list widget, since I can achieve the same with custom widgets and other methods. Its unnessasary.

[tw-FRed]

@TW_Tones

Unfortunately this only works as a variable <<~>> {{{ [<~>] }}} unless you add a . to make it a custom operator;

\function .~() [all[current]]

<<.~>>
{{{ [<.~>] }}}
{{{ [.~[]] }}}

Why not just name this function .?
In filesystems, . means “here”, or “current directory”, so the analogy with currentTiddler strikes me.

\function .() [all[current]]

<<.>>
{{{ [<.>] }}}
{{{ [.[]] }}}

Fred

[TW_Tones]

We do discuss this above [v5.3.2-pre] Peeking at the Conditional Shortcut Syntax - #14 by pmario

But yes. Did you test it