Thoughs on simplified syntax

[Mat]

I just want to bounce this thought to hear if it makes sense:

The idea is about how to simplify the syntax, or at least make it easier to learn. 

A user currently has to learn the distinction between

<<macrocall>> and {{transclusion}}

The two are both simplified expressions for underlying widgets.

And both are basically for text substitution!

...so just maybe they could both use the same format, i.e 

<<macrocall>> and <<transclusion>>

Of course, this is problematic in that the parser would not know...: 

1. ...if the argument is a macro title or a tiddler title
   
2. ...or even a <<macro with arguments>> or a <<title with spaces>>
   

But, regarding the first: Comparable to how we accept tags as tiddler titles, IMO it would be pretty natural to not make a distinction between macro titles and tiddler titles. In fact, tiddler philosophy applies pretty well also for macros... (Actually, if we pretend for a second that macros are code functions, I think tiddler philosophy and "function philosophy" are also pretty similar in objective -i.e to segregate and split out parts in code to make them manageable and reusable).

Problem 2 above is of course just a matter of syntactic sugar.

One could imagine this syntax

((mymacro(arguments list))) ...i.e a macrocall

((tiddlertitle())) or ((spaced tiddler title())) ...i.e transclusions

The round parentheses is just one imaginable example. It does have the niceity that picks up on the existing macro def parentheses, i.e in \define mymacro(parameter list)

The syntax is also interesting because it brings further similarity with macrocalls when we consider transclusion with templates! I.e

((tiddlertitle(template)))

Again, tiddlers and macros are interchangeable. (Which btw, means core macros should probably be suffixed like core tiddlers to not have users accidentally overwrite them.)

Thoughts?

<:-)

[Jeremy Ruston]

Hi Mat

Excellent, you're following a line of thought that has preoccupied me for a long time.

Firstly, I think about this stuff in a cloud headed “what comes after TiddlyWiki 5?” both because these sorts of changes are often challenging from a backwards compatibility perspective, and more importantly because now we're 6 years after started to create TiddlyWiki 5 I can recognise many fundamental elements of the design that I would do differently if I knew then what I knew now. I'm by no means eager to start things from scratch all over again, but its still interesting to assemble my thoughts on critiquing the current design of TiddlyWiki.

Anyhow, where I've got to in terms of this specific issue is to reformulate it as a slightly different question: do variables and tiddlers have to be different things? As you note, both the double angle bracket syntax and the double curly braces syntax get some text from somewhere and wikify it; the only thing that differs is where the text comes from.

You'll recall that the point of variables is that they can have different values across different parts of the widget tree; in contrast, the value of a tiddler is consistent across the tree. We need something like variables for the list widget to work, so that there is a way for the repeated chunk of wikitext to access the name of the item that it represents.

So, the solution I've been considering is to unify tiddlers and variables. The idea would be to have a new widget <$tiddler-store> that acts as a tiddler container. When a widget needs to read the value of a tiddler it sends a message to its ancestors until it finds one that responds with the value for that tiddler.

This structure is attractive because it's a bird that kills many stones. The cascading action we get between nested tiddler stores is precisely the same structure that we have with ordinary tiddlers being backed by shadow tiddlers. We'd have a stack of tiddler stores corresponding to each plugin and then the main tiddler store at the top. The list widget would act as a tiddler store for the index variable.

Pulling back up to your original question, the issue we'd now have is how to name those tiddlers that are acting as variables. Simple names like "currentTiddler” wouldn't be great because we'd be stomping all over the users tiddler name space. One solution would be to use a prefix for variables, such as "$:/variable/currentTiddler". Then the difference between {{Foo}} and <<Foo>> would be that the latter would be equivalent to {{$:/variable/Foo}}.

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

http://jermolene.com

On 7 Aug 2017, at 08:07, @TiddlyTweeter <tiddly...@assays.tv> wrote:

Matt

Very useful thoughts for someone like me.

One thing missing, at least I can't find one, is a CRIB sheet of existing syntax ... something along the lines of those that Tobias did for Filters and WikiText examples.

My single biggest issue as an idiot is that I forget what all the variant brackets mean so have to go fish around and look them up repeatedly. I've found it hard to consolidate what I know in a way that becomes intuitive. Crib sheets help people like me get out fog.

The rest of your points I think I understand, but, before one starts changing fundamentals, I'm wondering is just gathering all the syntax on one "page" with simple examples might not do what is needed.

Best wishes
Josiah

Mat wrote:

I just want to bounce this thought to hear if it makes sense:

The idea is about how to simplify the syntax, or at least make it easier to learn.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/9ed2811c-906c-4e8b-a3ec-1615fc74c71a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

Jeremy Ruston wrote:

 

unify tiddlers and variables.

Whoaaa! That sounds conceptually huge!

 

Pulling back up to your original question, the issue we'd now have is how to name those tiddlers that are acting as variables. Simple names like "currentTiddler” wouldn't be great because we'd be stomping all over the users tiddler name space. One solution would be to use a prefix for variables, such as "$:/variable/currentTiddler".

A few thoughts, probably based on misunderstanding from my side:

a) Is there anything within the $:/ name space that would not be a variable? Shouldn't just "$:/" suffice?

b) ...because wasn't a main point with the shadow tid cascade analogy that overwriting tids use the exact same title as the shadow tid? I.e that we should not have to name the tiddlers that act as variables in any particular way but that they instead are always treated as variables but with a fallback to a constant value (i.e the tiddler itself... or maybe tiddler content).

c) Are you saying there must exist a tiddler in order for it to be a variable? If yes, in the case of a currentTiddler variable, maybe the fallback physical tid would be a default tiddler? Can it not simply be a missing tiddler? Or just a dummy tiddler. Or the way it is currently; the historylist with a "variable field" for current... but maybe that breaks the concept...?

 

Then the difference between {{Foo}} and <<Foo>> would be that the latter would be equivalent to {{$:/variable/Foo}}.

Couldn't e.g {{Foo}} cover everything? - The system checks to see if Foo is a variable, in which case you get that value. Not variable - go up the tiddler store stack to check if there is a macro named so... get evaluated macro. Last fallback, tidder : transclusion. 

I.e only one kind of brackets and one name. System vars/macros/tids treated the same way but always have prefix $ or similar. 

...?

<:-)

[Jeremy Ruston]

Hi Mat

On 7 Aug 2017, at 16:55, Mat <matia...@gmail.com> wrote:

Jeremy Ruston wrote:

 

unify tiddlers and variables.

Whoaaa! That sounds conceptually huge!

 

Pulling back up to your original question, the issue we'd now have is how to name those tiddlers that are acting as variables. Simple names like "currentTiddler” wouldn't be great because we'd be stomping all over the users tiddler name space. One solution would be to use a prefix for variables, such as "$:/variable/currentTiddler".

A few thoughts, probably based on misunderstanding from my side:

a) Is there anything within the $:/ name space that would not be a variable? Shouldn't just "$:/" suffice?

Err under this proposal, “variables” are just tiddlers whose value is different across the widget tree. We haven’t turned every tiddler into a variable, we’ve turned variables into a special type of tiddler.

The idea of a naming convention is so that users can easily distinguish between tiddlers intended to be used as variables, and those intended for ordinary use.

b) ...because wasn't a main point with the shadow tid cascade analogy that overwriting tids use the exact same title as the shadow tid?

That is correct.

I.e that we should not have to name the tiddlers that act as variables in any particular way but that they instead are always treated as variables but with a fallback to a constant value (i.e the tiddler itself... or maybe tiddler content).

See my explanation above; we’re talking here about the adoption of a convention to make life easier for users.

c) Are you saying there must exist a tiddler in order for it to be a variable?

This proposal is about changing the way that tiddler storage works so that we can use tiddlers for the same purpose that we presently use variables. 

If yes, in the case of a currentTiddler variable, maybe the fallback physical tid would be a default tiddler?

There’s no concept of (or need for) a “fallback physical tiddler”.

Can it not simply be a missing tiddler? Or just a dummy tiddler. Or the way it is currently; the historylist with a "variable field" for current... but maybe that breaks the concept…?

I’m not quite clear what you mean here.

Then the difference between {{Foo}} and <<Foo>> would be that the latter would be equivalent to {{$:/variable/Foo}}.

Couldn't e.g {{Foo}} cover everything? -

Yes, that’s exactly it; I was proposing the angle brackets syntax as a shortcut for transcluding tiddlers with a particular prefix to their title. The idea is to allow us to use long tiddler titles for variables (that won’t clash with the users tiddler titles) while being able to refer to them without typing the entire name.

The system checks to see if Foo is a variable, in which case you get that value. Not variable - go up the tiddler store stack to check if there is a macro named so... get evaluated macro. Last fallback, tidder : transclusion. 

I think you’re making a different proposal, which would be equivalent to merging the variable and tiddler name space, which is exactly what I’m trying to involve.

I.e only one kind of brackets and one name.

Right, I think that’s what my proposal does.

System vars/macros/tids treated the same way but always have prefix $ or similar. 

I’m not sure what you mean here,

Best wishes

Jeremy

...?

<:-)

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To post to this group, send email to tiddly...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/3bc01743-00d3-4ff8-9530-40c4d74af7de%40googlegroups.com.

[Mat]

Jeremy Ruston wrote:

Err under this proposal, “variables” are just tiddlers whose value is different across the widget tree. We haven’t turned every tiddler into a variable, we’ve turned variables into a special type of tiddler. 

The idea of a naming convention is so that users can easily distinguish between tiddlers intended to be used as variables, and those intended for ordinary use.

Aha, more akin to how we currently use e.g state tiddlers then. I'll start a new thread on some thoughts about this.

Then the difference between {{Foo}} and <<Foo>> would be that the latter would be equivalent to {{$:/variable/Foo}}.

Couldn't e.g {{Foo}} cover everything? -

Yes, that’s exactly it; I was proposing the angle brackets syntax as a shortcut for transcluding tiddlers with a particular prefix to their title. The idea is to allow us to use long tiddler titles for variables (that won’t clash with the users tiddler titles) while being able to refer to them without typing the entire name.

But then you're still proposing a syntax with two kinds of brackets, that users must learn about. Even if only {{}} is required and <<...>> is a shortcut for {{$:/...}}, the user will probably still have to learn about both of those - just like it currently, very early on, is insufficient to only know about <<>> for macrocalls (any complex argument typically forces use of <$macrocall/>). My OP is mainly about simplifying the syntax because we have so many syntax forms.

<:-)

[TonyM]

Can I please plead the members of this thread consider my post in the other group that is related, although it may not be obviouse at first.

[TW5] Desirable core additions
https://groups.google.com/forum/?hl=en#!topic/tiddlywiki/AduZlD79FZo

Regards
Tony

[TonyM]

See also a similar discussion on Fields https://groups.google.com/forum/#!topic/tiddlywikidev/iw59ThjJID8