Tiny change in WALTER to make it more consistent

DrTT · 05-13-2022, 01:08 PM

Dear all,

I have been bitten by a problem in WALTER that has been brought up by LarrySeyer in thread https://forum.cockos.com/showthread.php?t=250420.

First of all I have to say that in my opinion WALTER is a nice little UI definition language, but I think WALTER has a severe conceptual inconsistency.

Being in the process of setting up a complex theme with WALTER I have the following mental model about variable and value semantics:

All variables in WALTER are eight-tuples (typically used for widget layouts).
When defining a "scalar" variable, it is elevated to an eight tuple with identical component values. E.g. set x 1 sets x to the eight-tuple [1 1 1 1 1 1 1 1].
Normally scalar literals also behave like those tuples. Hence you can do component-wise arithmetic with them so * 2 [1 2 3 4 5 6 7 8] produces [2 4 6 8 10 12 14 16] (because the literal 2 is expanded to a tuple of twos and multiplication is done componentwise on the tuples).
This also means that scalar arithmetic works fine, because all operations work on the (identical) components of an eight-tuple. So * 2 3 is really done as * [2 2 2 2 2 2 2 2] [3 3 3 3 3 3 3 3] --> [6 6 6 6 6 6 6 6]. The only drawback is that the operations are done eight times instead of once, but this seems to be no performance issue...
To project out a really scalar value from such a tuple variable, one can apply the "{}"-notation, e.g. xxx{0} yields the first tuple value.

Unfortunately there are places where this logic does not work any longer (which is mentioned in the documentation where it says that for some contexts "val1/val2 can be constant or scalar value variables" which means they must be scalars). Those contexts are:

comparisons: those fail for non-scalar values. I can understand that a total order comparison is not possible for arbitrary tuples, but they should at least be okay for tuples with all components identical. In my opinion [1 1 1 1 1 1 1 1]<[2 2 2 2 2 2 2 2] is perfectly valid, but in WALTER it is not. So the code
Code:
```
set panelWidth w
set xxx panelWidth<100 [1] [0]
set yyy w<100 [1] [0]
```
leads to different values for xxx and yyy when w is 85 (because I've left out the "{0}" projection). And this is absolutely counter-intuitive! (By the way: one has to know that w is a scalar constant by definition and hence it is different from your own variables...)
This logic also makes it difficult to define boolean variables like
Code:
```
set panelIsSmall w<100 1 0
set xxx ?panelIsSmall [2] [5]
set xxx ?panelIsSmall{0} [2] [5]
```
where the second line does not work while the third does. You have to add some crazy scalar projection when applying the variable to make it work.
compound operators like +:val1:val2. I could live with that in principle but it is not clear why those operators could not be fully identical to + * val1 argument1 * val2 argument2 for val1 and val2 being tuples.

So my feature request would be as follows:

For comparison operators do a componentwise comparison of the tuple elements and combine the results with an AND. So [1 2 5 4 7 8 12 3]<[2 6 9 5 12 14 13 7] is true and [1 2 5 4 7 8 12 3]<[2 6 4 5 12 14 13 7] is false. There should be no real problem with that since mathematics considers such a relation on tuples an "ordered vector space" with well-defined semantics.
Extend the compound operators to tuple values. If the syntax gets too confusing for tuple literals, one could only allow variable names or literals between the colons...

In my opinion this does not break any existing WALTER scripts: they then just do unnecessary extra work for the projection. It impedes performance somewhat because some operators (comparisons, compound operators) become a little bit more expensive to calculate, but this should be tolerable for the sake of consistency.

What do you think about that?

Best regards,
DrTT

Justin · 05-15-2022, 05:59 AM

I agree that the current behavior of "scalar<vector" being interpreted as "scalar<0" is not useful and is unexpected. We will change it so that it is interpreted as 'scalar<vector{0}'

DrTT · 05-15-2022, 01:28 PM

Hello Justin,

you wrote:

Quote:

... "scalar<vector" being interpreted as "scalar<0" is not useful and is unexpected. We will change it so that it is interpreted as 'scalar<vector{0}'

What about valA<valB being interpreted as "for all i in {0, ..., 7}: valA{i}<valB{i}" and scalars being elevated to vectors with identical components? This would allow comparisons of two vectors regardless of where they came from. So e.g.

Code:

set panelHeight * h 1@h
set widgetHeight 20@h
set isSmaller widgetHeight<=panelHeight 1 0

would work as expected...

That for-all-logic also helps when using those "boolean variables". They must have all components zero for false and non-zero for true.
So isSmaller can be used for setting another variable:

Code:

set otherHeight ?isSmaller - h@h widgetHeight 0

Best regards,
DrTT

Justin · 05-30-2022, 06:54 PM

I can see the appeal of that request, but from an implementation perspective making all comparisons operate on scalars and treating vectors in that context as the first item simplifies things.