Hi Tony

Your description is very nicely put.

The curious thing for me about both the filter language and wikitext is that 
they both evolved from very simple initial conditions:

* The filter language evolved from the idea a simple list should be a valid 
filter, evaluating to the titles in the list. Given the double square bracket 
quoting that we already had, squeezing the operators in between the opening 
double square brackets allowed us to add logic without taking users too far 
from the existing logic (“square brackets are special”)
* The wikitext language evolved from binding together two parents: the wikitext 
syntax established with TWC and the HTML syntax for elements

Both have now become rich and expressive languages by iterative evolution from 
those initial ideas.

(A sore point in the design is action strings: we re-use the widget syntax, but 
at best its a declarative representation of procedural logic).

Best wishes

Jeremy

> On 4 Aug 2019, at 09:57, TonyM <[email protected]> wrote:
> 
> Mohammad,
> 
> Can you clarify what you mean by branching?
> 
> Despite my investigating replacements for common structures in procedural 
> programing languages, Tiddlywiki is not actually procedural. Even when you 
> trigger a "batch" operation control is returned only once it is completed and 
> everything visible is re-rendered.
> 
> The final result is presented each time the tiddler is rendered into HTML. 
> this is very common for online solutions as was for old mainframe apps. 
> Basically it is as if the server  processed everything its given and returns 
> the result. The browser then sits there doing nothing, while the browser 
> (client) lets you interact with what is in your browser and at the end you 
> "send", the changes get sent back to the server for processing. In 
> tiddlywikis case, the only browser to server interaction need be the save and 
> re/load process. But A similar model is used within tiddlywiki and our 
> browser session. When we save a tiddler, or navigate or use another trigger 
> like a button or action this is sent to the tiddlywiki internals they are 
> processed to completion and the result returned and the wiki re-rendered for 
> our pleasure. One of tiddlywikis strengths is it does this efficiently and 
> re-renders only that which has changed as a result of your change.
> 
> Because of this architecture we need our designs to "finish", they do not 
> branch off or spawn additional processes like a normal procedural language. 
> There must be a technical term for this. 
> 
> Now I know this view is not 100% correct but it helps me visualise the 
> "platform". Perhaps it always needs to be complete (related 
> https://simple.wikipedia.org/wiki/Turing_complete 
> <https://simple.wikipedia.org/wiki/Turing_complete>)
> 
> 
> Rather than branching I think in tiddlywiki we are more likely to "nest" 
> things. We can selectively nest different things in other things. Our wiki 
> text is nested inside a tiddler and the tiddler inside the story and the 
> story in the browser window (page template) and when a Change occurs all 
> these nested structures are economically processed and re-rendered the full 
> nested result presented.
> 
> Regards
> Tony
> 
> 
> On Sunday, August 4, 2019 at 4:53:28 PM UTC+10, Mohammad wrote:
> This is great!
> Still we have not real branching with then-else
> but we have
> if NonEmpty
>   return then part
> else
>  return else part
> end
> 
> And we need a construct like you proposed!
> 
> --Mohammad
> 
> On Sunday, August 4, 2019 at 10:47:34 AM UTC+4:30, TonyM wrote:
> Mohammad
> 
> This structure will return true only if the input is true, any other value 
> including empty  will return false
> 
> <$set name=input value="true">
> <$list filter="[<input>match[true]else[false]]" variable=returned>
> 
> </$list>
> <$set>
> 
> Thus inside the list you can test
>    <$list filter="[<returned>match[true]]">
> 
>    </$list>
>    <$list filter="[<returned>match[false]]">
> 
>    </$list>
> 
> Regards
> Tony
> 
> On Sunday, 4 August 2019 00:06:14 UTC+10, Mohammad wrote:
> While there were alot of request for simple conditional operations, it seems 
> the new TW 5.1.20 has this great feature
> 
> See
> https://tiddlywiki.com/prerelease/#Conditional%20Operators 
> <https://tiddlywiki.com/prerelease/#Conditional%20Operators>
> I think this needs to be discussed and examples are needed for clrification!
> 
> So, interested people, please give their use cases questions here!
> 
> -Mohammad
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "TiddlyWiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] 
> <mailto:[email protected]>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywiki/14de1ca9-88ae-42ce-b729-0d3ba15eeae8%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/tiddlywiki/14de1ca9-88ae-42ce-b729-0d3ba15eeae8%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/AAB07021-5896-454C-82F9-B022C4961945%40gmail.com.

Reply via email to