TW the finite state machine

[Louis Davout]

Hello all,

I've been casually using TW for a few months now. In the past couple weeks I have started working with the slightly more advanced features. https://groktiddlywiki.com/read/ has been very helpful, thanks Soren. One of the obstacles for me to grok TW is there appears to be a lot of conditional rules based on the current context of the parser - ex: in tiddler text vs macro call vs macro definition. This makes me visualize TW as a finite state machine. Maybe it's actually designed as such, I haven't looked at the code. Anyway, the nice explanation by PMario here just bolstered my visualization.

I don't suppose there is documentation of TW as finite state machine. Probably not, but thought I would ask. What I mean is documentation broken down as:

1. Here are all the possible states TW can be in
2. Here are the rules for when TW is in a given state
3. And here are the triggers that will change TW from one state to another
   

Maybe there are too many states, or may different levels/granularities of states.

The closest I found is Tones' https://anthonymuscio.github.io/It has many of the rules for a given "state".

Thank you.

[David Gifford]

Thanks for pointing out Tones' standard nomenclature, I hadn't seen that. I just added it to the TiddlyWiki toolmap.

[TW Tones]

Davou,

I just refreshed the concept of finite state machine and I would be confident in saying tiddlywiki is not one. You may see elsewhere and reasonable claim tiddlywiki is a "non-trivial quine", it can change itself and save its state.

This is because an  finite state machine's memory is limited by the number of states it has, tiddlywiki is not, and its memory limitations are in undetermined.

However I suspect the reason you think this may be the case is reasonable, but would argue that this mostly stems from tiddlywiki being used in the browser. Along with other websites and even much earlier Mainframe terminals the client server model a need to limit the effort required by the server html tends to respond to a client when needed and not until then. Think of a html form, it sits on your screen and the server may be able to forget you exist until you hit the submit button, at which point the server/host responds. Tiddlywiki however exists wholy within the browser and only on saving do we need to communicate with the server/host.

Tiddlywiki's update process that reflects any change throughout the whole wiki, makes use of a thing call widget trees, examples such as transclusions need to be resolved based on any relevant change. However such could result in infinite loops but tiddlywiki is designed to avoid this. Basically it works to ensure each change is processed in a finite way so it returns quickly to allow the user to interact or provide more data to it. 

I feel that tiddlywiki is better thought of as an approximation of a Turing machine that handles most freeze, fails and infinite regress (although not all).

Part of the complexity comes on one hand from the feature rich code and services available to software in the modern browser and on the other hand it can be hosted such that changes can't be saved. It could be argued a read only tiddlywiki has finite states, however there are so many states it can be in, it may as well be infinite.

Thanks for posting such ideas.

Tones

[Louis Davout]

Tones,

I think we're looking at the state of different things. Let me see if I can articulate. If I'm understanding what you're saying, you're talking about the entire application including all the tiddlers as the state machine. I create a new tiddler in my wiki instance, the state of that wiki has changed. Yea that would not be finite. Sorry if I wasn't clear.

I was referring more to the engine - the parser (and maybe other things) - as it process a tiddler to convert it into html. For example, a tiddler has a text field the parser reads that field. The TW parser is initially in "General wiki text" (as you describe it). The parser encounters the string \define, the parser recognizes this as macro definition therefore TW state has changed to "Macro definition" and therefore rules of what valid text should follow is different than if TW was still in "General wiki text.

Hopefully that clarifies things.

Thanks.

[PMario]

On Monday, August 9, 2021 at 7:01:42 PM UTC+2 davou...@gmail.com wrote:

I don't suppose there is documentation of TW as finite state machine.

There is the TW dev documentation, that has been started, I think by 2 students as a project to analyse the internal structure of TW.

See: https://tiddlywiki.com/dev/  ... This docs shows most of the internals, that core developers need to know.

 

Probably not, but thought I would ask. What I mean is documentation broken down as:

1. Here are all the possible states TW can be in

There are way to many states TW can have. All of the states the TW UI can have, are stored in tiddlers. ... Eg: The reveal widget needs a state-tiddler to decide if it should be "open" or "closed". Depending on the value of a field or an index of the state-tiddler, the widget renders differently. The state of the field can be changed by actions. Actions are mainly triggered by buttons. ... Buttons are pressed by users. So in the end the whole system is "user event" driven.

1. Here are the rules for when TW is in a given state

Most of the time the decision is created with matches. Eg. again the reveal widget has a type-field, where we define if it should compare the state-tiddler value with a given value. ... The result of the "match" decides if a state is eg: open or closed. ...

Some other widgets have an "implicit" rule. Eg: the transclusion-widget. If the widget is called with a tiddler attribute that doesn't exist is uses the content between transclusion-start and transclusion-end as the "value" that should be shown. This mechanism allows us to create very simple wikitext code that uses a fallback, if a value is missing. eg: The right sidebar shows a list of tiddlers. If a tiddler has a caption-field it is used. If the caption-field is missing, we show the tiddler title. eg

<$transclude tiddler=<<currentTiddler>> field=caption>
<$text text={{!!title}}/>
</$transclude>

The $view-widget has a very similar behaviour. ...

1. And here are the triggers that will change TW from one state to another
   

As I wrote. In normal cases changes are driven by the user. Whenever a button is clicked, there is usually an action-parameter somewhere, which triggers the change of a tiddler value. ... The TW core has an internal mechanism, that watches the state of every tiddler in the store. Whenever a tiddler is changed, a "change" event is triggered by the core. Every widget, that needs values from tiddlers listens to this "change" event and acts accordingly.

Maybe there are too many states, or may different levels/granularities of states.

The "granularity" the system can handle, is on the tiddler level. As above, every tiddler value change triggers a "change" event. So the smallest element we use to store state is a tiddler.

 

hope that helps.

mario