I think you have an argument here. ⌠We would need to test it a bit more.
1 Like
I donât think that the term âmacroâ works for the new procedures because in programming contexts the term âmacroâ almost always indicates a preprocessor where expansion occurs via textual substitution (some examples are C/C++ and Rust). We take the term from programming, and so it would be unhelpful to take an existing term from the field and use it to mean something different. Meanwhile, âmacroâ covers very well the functionality of the existing macros.
That is a good arguement but can we find another term? I am yet to understand it deeply enough, but I am working on it. Can we find a term that describes it without miss representing it?.
Sure I may need to concede procedure, but I will continue to research it. I have a hunch that I cant yet put my finger on.
The changes to the transclude widget attributes donât affect any of the attributes for the other widgets.
What exactly do you mean by âstand aloneâ? It only makes sense to use the parameters widget in some context in which you can pass parameters. That could be by transcluding a tiddler or invoking a macro/procedure/widget (i.e. transcluding a variable). Under the covers, all of those are handled by the transclude widget. The parameters widget is handled by the transclude widget code.
Could you share an example of what you mean? You can place the parameters widget whereever you want, but it wonât have any effect unless you have a way of passing parameters into the widget.
Yes. This works in a tiddler with or without a transclusion that shows it. ⌠BUT if transcluded, that âparamâ value can be changed
\parameters (param:"test parameter")
<<param>>
1 Like
Here they are. See the first 3 posts 
and have fun!
3 Likes
Then it is could be \runner, it sound good to me, because it executes a filter expression. I would prefer short pragmas (it is the same reason for my preference of \def over \procedure)
1 Like
I believe the names we will use should not so much root in (programming) semantics, but if at all possible in terms that an advanced TW user (below the level of developer) will already know if he/she has been studying the documentation diligently. I for one can live with historians 100 years from now saying âDuh, TW people used the term âmacroâ wrongly.â
For what itâs worth, my vote is for \operator. Look up any âoperatorâ in the docs and you will find a description of a name, suffix, parameters, functionality. This is very close to what we will define with the pragma. Maybe itâs not semantically correct, but one will intuitively know whatâs going on when reading code.
For the same reason I must vote for \macro. This is finally the chance to call a spade a spade in the source code, donât squander it.
I know <$placeholder> would be a lot to type, but Iâve been doing that every time a make an $edit-text widget, and it makes pretty clear what it does with terminology a TW programmer knows â at least better so than <$slot> does.
Iâm not a fan of $$ and havenât been, but there are only so many symbols that most people are familiar with, and I like that TW tries not to go overboard with it.
I promise, though, that I will not refuse the new functionality no matter what the pragmas will be called eventually. 
1 Like
From a user experience perspective I strongly disagree. It is extremely important to use distinct terms for new concepts that avoid the need for disambiguation, which is almost guaranteed when re-using existing terminology.
Overall I think there is far too much focus on the names of the new pragma in this discussion thread. I would suggest approaching this instead from the point of view of trying to write end user documentation for the new concepts - not the pragma that implements the concept - and think of the names for the new concepts in terms of how intuitive and precise that documentation will be for new TiddlyWiki users.
Letâs agree to disagree, then. Your point about appropriate distinction is surely valid, but with it comes a hefty initial âshockâ because there is so little thatâs familiar to existing users. One might certainly improve the initial acceptance (for those users), if not everything that is PR #6666 was completely new regarding every syntax, term and concept. Why must âmacrosâ now be called âproceduresâ only because they gained flexibility? Why must filter âoperatorsâ now be called âfunctionsâ, only because I can define them myself? Why do widgets not get a new name?
I must admit that Iâm a bit of an outsider looking in on PR #6666, so my perspective will surely be different from yours.
I think the OP in its closing remarks put the focus on exactly this point.
That was definitely something I always liked about TW.
Also, Iâm thinking from the point-of-view of an existing user. From a new user perspective, starting from a clean slate, most of my points would be invalid, of course.
2 Likes
Very interesting, forthright, discussion you are having.
I have appreciation of both your takes on the matter.
I want to comment generally that ânew terms/conceptsâ can work well within a system that co-mutually defines those terms.
Though issues would arise where they lack total inter-consistency. Without that, a given descriptive system, can fail.
TBH, I think that TW functionality is very innovative and actually deserves itâs own meta-concepts. When needed, for purpose.
Though location of those concepts in the extant computer-languages matrix does raise issues, especially on initial comprehension.
I should quickly add, I am not a programmer. Merely a social scientist interested in where âdifferentiation & expansionâ of lingo is valuableâi.e. does new TW lingo better serve end-use or not? And avoid barriers to entry?
Just somewhat philosophical thoughts,
TT
See. ⌠Thatâs wrong. An operator is only 1 element of a filter run. eg: [tag[HelloThere]] ⌠tag is the operator and HelloThere is the operand. ⌠All together is 1 filter run.
⌠But functions IMO is a name that should be challenged. IMO the best fit would be filter ⌠but ⌠that term is overused already.
Intentionally allowing ambiguity in the documentation and concepts and potential confusion for most users for all time, for the express purpose of allowing a semblance of familiarity of existing advanced users - who are a smaller though outspoken and important subset of the community - cannot be the goal that drives these decisions. If anything, I would hope that the advanced users are precisely the community members more willing to be open to change and learning new concepts and terms, and thus contribute to creating a better entry path for others behind them on the learning curve.
I would much rather that the introduction of parametrized transclusions come as a shock to some existing users if it means that in the long term we have greater clarity in the concepts and documentation. After all, all of the these new concepts and features are entirely backwards compatible and optional for existing users to learn at this time, and the existing mechanisms will still be present and usable just as they always have been.
I will assume that this is merely a rhetorical question since taken literally it would indicate a lack of familiarity with the relevant documentation and concepts. Reusing the same term for something that behaves and is used differently is bound to lead to user confusion and even lead them to the wrong documentation.
Would you like to take a crack at a quick draft of documentation for tw-com for âproceduresâ and âfunctionsâ under your proposed nomenclature of macros and operators, whilst disambiguating between the new forms and what those terms are currently used for in TiddlyWiki? It would be a good way to determine the merits of the proposal as seen from your perspective. I considered this path a while back but personally did not find it viable.
A fair proposal. I shall take a stab at it, but cannot promise that anything presentable will ever come of it. At the least it will shut me up for a whileâŚ
Thanks @Yaisog there are some helpful questions there.
That observation seems fundamental: there is a shock to the new stuff because it is new. Even though the changes are backwards compatible, they require users to reconsider the way that they have always done things. I can understand why that can be unnerving.
But there are good reasons for the introduction of these new features. A trend through this thread has been the desire to use existing names for the new things as a way to make them more familiar, and less shocking.
Part of the problem is that doing that would require us to retrospectively change what these existing names mean, which is super confusing. As @saqimtiaz notes, reusing the existing names means that we have to qualify those names to avoid ambiguity, making the docs more complex and hard to read.
Procedures are not just macros with the addition of new capabilities. Macros also have capabilities that procedures lack: notably, procedures donât do textual substitution, which is the capability that gives macros their name.
Because what we are calling functions are not the same as filter operators. Filter operators take suffixes and operands, and can only be used in filters. Functions take named parameters, and can be used in many contexts.
The key observation with functions is that our usage of the term closely matches that of the wider software industry. Almost all programming languages agree on what a function is, and the TiddlyWiki interpretation is very similar.
Widgets already exist in TiddlyWiki. The parameterised transclusion work doesnât replace them with anything else, it just adds the ability to make user defined widgets. Thereâs no need to change the terminology because there is no confusion.
1 Like
I canât argue your facts, neither do I want to. I just gave an opinion from a singular perspective, and it wasnât that of the persons writing the docs.
Like I said initially, Iâll be using the new stuff regardless. In fact, I canât wait to use it in production to replace some currently very unpretty code.
In the end, it doesnât really matter what theyâre called (the pragmas and concepts), we will have to get used to new terminology anyway. So maybe it would be an opportune time, @jeremyruston having very succinctly outlined the reasons and origins, to put an end to the discussion and finalize the nomenclature?
I would propose, though, to create a âTransitioning for experienced usersâ (or similar) document / tiddler, which goes a bit more into detail than the âIntroduction to v5.3.0â paragraph. Maybe some old-vs-new or whatâs-now-possible examples. Something to âdampen the shockâ, take the experienced TWâer by the hand and lead him into the promised land, if you know what I mean. And at the same time a concide reference. Much of the content could probably be found in this very thread.
There probably was something like this planned anyway or is already existing?
1 Like
I concur with @Yaisog and have said so multiple times. I have put arguments here and elsewhere including I believe reasonable alternatives and I forshadow the ambiguity and technical terminology, unlike earlier terms is going to reduce the uptake, or slow the learning for many users of tiddlywiki in the long run, and a p[ercentagew will abandone it because of this. I am an optimist that a little creativity can come up with terms acceptable to all and as for @Yaisog I will accept the result either way.
- I always need to check myself when communicating complex issues that I do not burden my language with difficult jargon and terms.
- A few of us have tried to call out this issue with these upcoming changes not because we donât love the work / new-features, but because we are familiar with communicating with less experience users.
- Also please donât dismiss this once again with we are not happy with change, I am very happy with change itâs why I chose IT at the bleeding edge as my career, but I also appreciate changes can be implemented at varying levels of quality.
- It is also very important we keep the communications channels open and demonstrate we are listening to each otherâs differing perspectives.
I think I must withdraw part of my original propositions for the new names / concepts. That was informed at least in part by my bad memory and the amount of time passed since I had last read over the descriptions of the new features.
After the reprimand I got from @saqimtiaz I had another look. I realized that the differences between the old and the new are indeed substantial enough to warrant new names for the concepts, to avoid confusion. I am a bit embarrased by the lack of my own diligence.
As Saq rightfully noted, it is probably more important to agree on a name for the new concepts than one for the new pragmas. And maybe there is a way to bridge the gap beween the old and the new. How about we talk about Filter Functions and Macro Procedures?
Filter Functions would describe the intended (main) use and their content. And while not strictly macros from a CS point-of-view, procedures originate from macros and would be used mainly how a macro is used today. Even the docs and tags refer to macros sometimes in the context of procedures. So we combine terms that are familiar with ones that describe the underlying concepts better.
That way we could also stick with the current pragma names. I donât have another, better proposal for those at this point. And there might not be a need.
3 Likes
A transition guide would be a great idea. The material in the OP of the PR is written from the perspective of existing users, and could serve as a basis for it.
I donât think weâve got viable alternatives yet. I went back through this thread collecting up the suggestions a couple of weeks ago. The suggestions that I can see for the pragmas all have the problem that they reuse words that already have an established meaning in TiddlyWiki (for example âoperatorâ or âexpressionâ instead of âfunctionâ).
I am hoping I read this all correctly, but if we are looking for a term to describe a pragma for defining a filter step, then why not just use \step? that way it is consistent with the filter docs etc.
Especially if you are looking to name other pragmas in this way (âI want to make a procedure so I will use the \procedure pragmaâ, etc)