I just want to say that those plans have fallen by the wayside as most of my after-work programming time has been caught up by the periodic table demo I’ve been doing. But I’m still keeping notes on this, and hope one day to get back to it.
I know this is from a while ago and I’m somewhat necroing a dead thread, but I thought I would say something about this.
This you mention here is precisely the problem.
People say they are like #define macros, but they don’t implode from recursion. They clearly don’t behave like preprocessor macros, and statements like this are misinformation adding to the confusion.
But at the same time, they don’t behave like functions either, as one would expect from the macrocall syntax and it being the normal alternative to macros.
The best I could describe them is a “Preprocessor macro that is interpreted instead of compiled”, which is a very foreign concept to most programmers and might actually be at the core of the issue. It’s something a term does not really exist for. Additionally feeding the flames is the fact that this is a point that is basically never explained.
1 Like
I don’t see how that furthers understanding anymore than my half-assed attempt to bridge the gap – there is no preprocessor in TW.
Perhaps I should have said “akin to”, rather than “not so different to”. Either way, the point I was trying to make is that TW macros, like #define macros, operate as a text replacement mechanism. Reading anymore into the analogy (like most analogies), doesn’t survive deep analysis.
^Z
1 Like
If it helps any, this is the mindset I crank on when using macros in TW, to overcome the things that used to trip me up all of the time.
First, these are text-substitution macros. That’s it, that’s all. (Well, the snippet of text is a template, in which parts can be different based on values provided with the macro reference. Much like a form letter and mail merge thingy.)
Next, I never say macro call. I say macro reference. There is no “call”.
Where there is a macro reference, that macro reference gets replaced by the snippet of text defined for that macro.
The widget “macrocall”, treat it as just a label (with no more meaning to it than if it were called “xyz”). It is just the name of the widget with which you are setting up a macro reference.
It is much easier to train your mind to think this way than it ever will be changing the widget name. For backwards-forwards compatibility, that widget name should never never never change.
4 Likes
One of the issues is, however you define these terms they need to include the fact that they are “rendered” at “display time” and will update if triggered by a change in the “widget Tree” (may not be correct term).
- This fundamental aspect of TiddlyWiki is like an interpreter, where its own code can change whilst it is interpreting, then its reinterpreted.
- After more than a decade with TiddlyWIki I think we may need to stop arguing the details and just accept that its different in tiddlywiki. Such that simple macros gain a new level of power.