Hey, all —
*Jeremy*: in TWX the idea is to make macro invocations and transclusions
> be the same thing. In other words, macro invocations would become
> parameterised transclusions, which simply means that the parameters for the
> macrocall/transclusion would be available as local variables within the
> transclusion.
>
This sounds pretty good to me, and assuming some kind of parse-tree caching
is involved, this would work just like the "wiki-functions" I describe
under the hood.
My reason for describing an inline declaration syntax is that it's handy to
define macros without adding another tiddler that clutters the namespace.
On that note...
*Jeremy*: A related part of my thinking is that the tiddler store would
> become a widget; the tiddlers that it defines would be available within the
> scope of the widget. The ancestor cascade would take care of the shadow
> tiddler mechanism.
*This* sounds brilliant... it promises to address concerns like
namespacing, combining local and remote wiki-stores... Good stuff.
As pertains to the current discussion, I wonder if it would be possible for
a "macro"-heavy tiddler to have its own sub-tiddler store for those
subroutines?
*Mario*: What's the problem, with making it exactly look like the existing
> syntax and just implement the performance improvement?
That's basically what I'm getting at: It would be possible to make the
syntax for defining these exactly the same as (or substantially similar to)
defining macros. However, there *would* be some changes and incompatible
behaviors, so it would probably be better for the pragma to have a
different name like \function.
*Mario*: IMO those are implementation details, that could be implemented
> in a backwards compatible way. ... right?
>
Not exactly. $parameter$ and $(variable)$ substitution have the effect of
inserting text into the macro *prior* to parsing. That behavior has to
change for the performance improvement to take effect, because we want to
parse in advance and any change in the raw text could change the structure
of the parse tree.
However, it's my experience that *most* parameter and variable
substitutions in macros end up being either direct insertion into WikiText,
or attribute assignment in the form attrib="""$param""" — in both of these
cases, the <<variable>> behavior will have the desired effect. Most of the
remaining cases just force a move to widgets.
Some examples:
\define make_list(filter) <$list filter="$filter$"/>
\function make_list(filter) <$list filter=<<filter>>/>
\define keycap(text) <kbd>$text$</kbd>
\function keycap(text) <kbd><<text>></kbd>
Macros that would *not* be directly convertible to wiki-functions would be
anything where parameters need to be inserted into other pieces of syntax,
or where parameters need to insert "open markup" such as // which is closed
elsewhere:
\define get_date(tiddler) {{$tiddler$!!date}}
\define apply_tag(tag, text) <$tag$>$text$</$tag$>
\define apply_markup(markup, text) $markup$$text$$markup$ <!-- where
markup is something like // or ``` -->
Note that all these restrictions apply to transclusions as they already
exist in TiddlyWiki, as well as the new <<__param__>> syntax.
On Wednesday, 3 January 2018 05:40:51 UTC-6, Jeremy Ruston wrote:
>
> Hi Evan
>
> Apologies, the TWX discussion is spread all over the place, but I think I
> may have mentioned before that in TWX the idea is to make macro invocations
> and transclusions be the same thing. In other words, macro invocations
> would become parameterised transclusions, which simply means that the
> parameters for the macrocall/transclusion would be available as local
> variables within the transclusion.
>
> A related part of my thinking is that the tiddler store would become a
> widget; the tiddlers that it defines would be available within the scope of
> the widget. The ancestor cascade would take care of the shadow tiddler
> mechanism.
>
> So, “global macros” would be transclusions of tiddlers defined in the main
> store, and “local macros” would be transclusions of tiddlers defined within
> the same tiddler.
>
> Best wishes
>
> Jeremy.
>
> On 3 Jan 2018, at 07:01, Evan Balster <[email protected] <javascript:>>
> wrote:
>
> Hey, all —
>
> A while ago I noticed Jeremy expressing some regrets about how TiddlyWiki
> has become dependent on text substitution macros, and suggesting that TWX
> will do something differently:
>
> *Jeremy Ruston:*
>
> Thus, there are lots of quite prominent features that were introduced
>> early on and that I would now handle differently (eg, the fact there is a
>> difference between transclusion and the view widget, or the presence of
>> text substitution macros which I now think was a mistake).
>>
>
> Having developed a lot of things in TW *and* reviewed the widget
> architecture with an eye for performance, I have to agree. People across
> the experience gamut seem to routinely stumble on the order-of-operations
> involved in parsing widgets and expanding macros. I'm also speaking as a
> compiler-designer: I've made the mistake of letting macros stand in for
> functions in a language I've designed, and it was a problem for both
> maintainability and performance.
>
> I view TiddlyWiki as a functional programming system, where each widget is
> a node with some parameters (attributes, parse tree / children) and a
> result (DOM tree). Macros are the de-facto stand in for programmable
> subroutines, but they are unstructured and must be re-parsed whenever they
> appear. Transcluded tiddlers may also behave like subroutines, and while
> they're structured they don't support explicit parameters.
>
>
> The solution I anticipate would be to introduce a "wiki-function" entity
> which is pre-parsed and whose invocation does nothing more than set a few
> variables and instantiate its parse tree into widgets. Perhaps something
> like this, widget-wise, with a WikiText syntax to get rid of the
> boilerplate:
>
> <$function $name="tablerows" filter>
> <$list filter=<<filter>> >
> <tr>
> <th>{{!!title}}</th>
> <td>{{!!field1}}</td>
> <td>{{!!field2}}</td>
> </tr>
> </$list>
> </$function>
>
>
> <table>
> <tr>
> <th>Title</th>
> <th>field1</th>
> <th>field2</th>
> </tr>
> <tr><th colspan=3>Important Stuff</th></tr>
> <$call $name="tablerows" filter="[tag[Tag1]tag[Important]]" />
> <tr><th colspan=3>Less-Important Stuff</th></tr>
> <$call $name="tablerows" filter="[tag[Tag1]!tag[Important]]" />
> </table>
>
> Now, this *does* look basically the same as a macro call. The
> differences are crucial, though: lower parsing and refresh overhead, only
> <<one syntax>> for variables, and no gotchas with quoting, whitespace,
> order-of-operations or open markup. As far as I'm concerned, the
> similarity in usage could make transitioning trivial in many cases and the
> more consistent behavior could make TiddlyWiki "programming" much 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 [email protected] <javascript:>.
> To post to this group, send email to [email protected]
> <javascript:>.
> 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/a6e13075-d639-4af5-b3c5-3883745688cd%40googlegroups.com
>
> <https://groups.google.com/d/msgid/tiddlywikidev/a6e13075-d639-4af5-b3c5-3883745688cd%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
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 [email protected].
To post to this group, send email to [email protected].
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/bba9e126-74be-4b2a-9b45-ad1dcb5f5fe2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
