Expanding MVV compatibility: a feature wishlist

[pmario]

@TW_Tones

I am wondering is MVV’s deduplicate titles. How we stop it doing so for example a collected list of numbers etc…

Or cause it to deduplicate.

MVVs follow the same rules as standard lists do. eg: {{{ 1 2 3 =3 =>asdf [(asdf)]}}}

The point here is that {{{ 1 2 3 3 }}} creating a list already deduplicates here. So it is not MVV specific. It is a specification of standard lists in TW.

Initially lists have not been intended to be used with math functions. So title duplicates have been an annoyance. It was natural for TW, that lists are automatically deduplicated.

With the addition of math operators that changed.

[EricShulman]

@tw-FRed

we prevent deduplication with = prefixes

In other words, without explicitly using = prefixes items in MVVs DO get de-duplicated by default, just like any other filter list.

[etardiff]

@tw-FRed

So I think deduplication is a result of c() filter syntax, not MVV, as opposed to d() where we prevent deduplication with = prefixes.

Good catch! I assumed @TW_Tones was looking for some MVV-specific (de)duplication toggle, but the standard filter workarounds do still apply.

Here’s a comparison of MVV behavior vs. a title-list stored as a standard variable:

So if the defining filter has been written to preserve duplicates, the default method of accessing those values — i.e., ((test)) or [(test)] — will return them without deduplication. This is in contrast with enlist<title-list> or <title-list>enlist-input[], where the suffix :raw must be used to prevent deduplication.

I’d say this makes MVVs slightly more duplicate-friendly. Of course, you will need to use [(test)unique[]] or [(test)]each:value[]] if ((test)) contains duplicates and you want to remove them in a later filter.

[TW_Tones]

@etardiff

I’m not currently aware of any mechanism to prevent deduplication in an MVV.

That is sad, I think we need to address this ASAP, the key reason would be for maths

I remain curious about how it works underneath

• The parameters widget can return all parameters in the call using the variable named with $params=
• Returns the JSON representation of the parameters,

@etardiff

Conveniently, this also works with parameters declared as part of a pragma:

Ah, so it looks to me that the introduction of MVV’s is mostly giving us access to the full variable, that already exists, even without reference to MVV’s

Observation: Consider this simple example;

\function mylist() [tag[Welcome]]

((mylist))

HelloThere, Quick Start, Find Out More, TiddlyWiki on the Web, Testimonials and Reviews, GettingStarted, Community

One thing the above example makes clear is MVV’s can now be used as a simple way to concatenate and display a list directly without the list widget. However since an MVV can be the direct result of a filter, via the function, the list is very easy to modify, extend etc…

• No need for list/join/$text etc…
• If I remember correctly they do not yet have a way to reference them, MVV’s, in Substituted Attribute Values but they work as direct attributes where supported.

@etardiff

However, I’m trying to get in the habit of using ((alpha)) whenever I invoke \function alpha() in a variable definition, even when <<alpha>> would technically produce the same results. IMO, it’s useful to have the visual clue as to whether I’ve written a given function to be used as an MVV or as a title list.

Very true, that is the kind of defacto standard if used will help us all.

@pmario

Initially lists have not been intended to be used with math functions. So title duplicates have been an annoyance. It was natural for TW, that lists are automatically deduplicated.

With the addition of math operators that changed.

So true, but unless we seek changes to support duplicates, we just want to make clear how to retain duplicates where needed. Ideally without the = hard coded on individual items.

@etardiff

I’d say this makes MVVs slightly more duplicate-friendly. Of course, you will need to use [(test)unique[]] or [(test)]each:value[]] if ((test)) contains duplicates and you want to remove them in a later filter.

Well outlined @etardiff

It should be quite easy to provide a function that given an MVV name ensures uniqueness when we need to go the other way.

Also the " =[run] :all[run] union of sets without de-duplication" could be used in a way to make lists without deduplication more readable.
Failed example

\function testnumbers() :all[[1 2 3 3 4 2]]

((testnumbers))

Returns;

1 2 3 3 4 2

a single string

So it would be useful if we had a filter run prefix to support non-deduplicated lists, which are in turn MVV’s

• I still need to explore this further.
• I suspect the let filter run prefix is the key to a code pattern that is more acceptable, or we need to make one.

Perhaps since we could now build an MVV that contains duplicates and reference it later there would be value having a filter operator that is the obvious opposite to unique[] rather than “deduplication” only being present in default behaviours of filters.

Bright idea?

@pmario I just had the idea that what if we had an additional pragma very similar to the \function pragma that did not deduplicate? The value which becomes addressable as an MVV but as you know functions can be used everywhere and very useful.

• Strangely there are few English words that are the opposite to deduplication that are not unwieldy

I have looked for words and the best fit so far is “raw” so perhaps

\function.raw()   2 3 3 4 2

• However, when more advanced filters are used, I believe this would need to pass a flag into every operator to tell it to act in raw mode?
• I think this non-deduplicating flag (behind the scenes has been needed for a long time), and we just keep avoiding it.
• The automatic deduplication is an essential feature and a good default, especially for lists, sets, and new users handling titles, but any default behaviour is best matched with a mechanism to override that default.