Switching from macro to procedure

#1

In another thread I used a macro to solve an issue:

I really need to get better at the new things. So I thought that this was a good candidate to use a procedure instead. I thought it would be a mechanical transformation. But it hasn’t worked yet, and I’m wondering if someone might be able to offer guidance.

The macro begins like this:

\define paginate(filter)       <!--
^^^^^^^                                -->

<$let 
  start={{{ [{!!page-number}subtract[1]multiply{!!items-per-page}] }}} 
  count= {{{ $filter$ +[count[]] }}}
<!--         ^^^^^^^^            -->
  last-page={{{ $filter$ +[count[]divide{!!items-per-page}ceil[]] }}} 
<!--            ^^^^^^^^         -->
>

<$list filter="$filter$ +[butfirst<start>first{!!items-per-page}]" >
<!--           ^^^^^^^^           -->

<!--- ... -->

So my naive attempt was just to change to this:

\procedure paginate(filter)       <!--
^^^^^^^^^^                         -->

<$let 
  start={{{ [{!!page-number}subtract[1]multiply{!!items-per-page}] }}} 
  count= {{{ <<filter>> +[count[]] }}}
<!--         ^^^^^^^^^^            -->
  last-page={{{ <<filter>> +[count[]divide{!!items-per-page}ceil[]] }}} 
<!--            ^^^^^^^^^^         -->
>

<$list filter="<<filter>> +[butfirst<start>first{!!items-per-page}]" >
<!--           ^^^^^^^^^^           -->

<!--- ... -->

and switch the $:/tags/Macro to $:/tags/Global.

This doesn’t work at all. Logging the <$let ...> variables, I get

start:0, count:1 last-page:1

When I get these with the macro:

start: 10, count: 60, last-page: 12

So I know I’m off to the wrong start. Am I just using the wrong syntax, or is there something more fundamental wrong with this idea?

#2

If an incoming value/parameter contains a filter you can either use it in its totality filter=<<filter>> or in a subfilter if you wish to combine it with more filter="[subfilter<filter>] .... it is not valid to use <<anyvarorparam>> inside a filter.

#3

Thank you very much! That fixed this problem. On to the next (vanishing whitespace.)

I wonder if it would be useful to add another column to the table at the start of
Variable Usage. Because reading that as is, makes me feel as through I should be able to replace my $filter$ anywhere in the body wtih <<filter>>. I’m not sure what would go in the other rows yet, but would this be a useful approach?:

how declared how parameters are defined accessing parameter values in the body accessing parameter values in a filter
\define () $param$, <<__param__>> $param$
$parameters or \parameters <<param>> ?
$set, $let, $vars $parameters or \parameters <<param>> ?
\procedure, \widget (), $parameters or \parameters <<param>> see subfilter operator
\function () <param> ?
javascript macros exports.params javascript property array passed as normal javascript function parameter and so accessed as a normal javascript variable ?

Again, thank you for the quick, and very helpful response!

#4

I think there is danger in adding that extra column because there are valid reasons to use more than one form in a filter, as I illustrated filter=<<paramname>> is a valid way to use a parameter as a filter, not in a filter, and you could use [$param$] or $param$ in a filter depending on the content the param.

  • There may be other ways to improve the documentation for sure.
  • Also there are now very similar tables through out tiddlywiki.com now.
#5

Ok, but note that other cells do show multiple formats. We could easily do this here.

Whether it’s here in this table, or somewhere else, it would be really useful to have a comprehensive and authoritative list of which syntaxes referencing variables, fields, parameters, etc. is appropriate in which circumstances. Too often I find myself getting the logic and design correct only to get stymied by syntax.

Again, thank you for your help.

– Scott

1 Like
#6

This. 100 times, this.

1 Like