Cockos Incorporated Forums - View Single Post

DrTT · 05-13-2022, 07:24 AM

Dear all,

sorry to revive this thread, but LarrySeyer has been bitten by the same thing as I have.

In my opinion WALTER is a nice little UI definition language, but I think WALTER has a severe conceptual inconsistency here.

Being in the process of setting up a complex theme with WALTER I have the following mental model:

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 [1 1 1 1 1 1 1 1].
Normally scalar literals also behave like 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.
This also means that scalar arithmetic works fine, because all operations work on the (identical) components of an eight-tuple. 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 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 function 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 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. And this is absolutely counter-intuitive! (By the way: one has to know that w is a scalar 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{0} [2] [5]
```
where you have to add some crazy projection when applying the variable to make it work.
compound operators like +:val1:val2. I can live with that in principle but it is not clear why they 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 an "ordered vector space" with well-defined semantics.
Extend the compound operators to tuple values.

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, but this should be tolerable.

What do you think about that?

Best regards,
DrTT

05-13-2022, 07:24 AM
DrTT Human being with feelings Join Date: Jan 2019 Posts: 76	In my opinion this IS A BUG! Dear all, sorry to revive this thread, but LarrySeyer has been bitten by the same thing as I have. In my opinion WALTER is a nice little UI definition language, but I think WALTER has a severe conceptual inconsistency here. Being in the process of setting up a complex theme with WALTER I have the following mental model: 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 [1 1 1 1 1 1 1 1]. Normally scalar literals also behave like 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. This also means that scalar arithmetic works fine, because all operations work on the (identical) components of an eight-tuple. 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 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 function 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 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. And this is absolutely counter-intuitive! (By the way: one has to know that w is a scalar 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{0} [2] [5] where you have to add some crazy projection when applying the variable to make it work. compound operators like +:val1:val2. I can live with that in principle but it is not clear why they 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 an "ordered vector space" with well-defined semantics. Extend the compound operators to tuple values. 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, but this should be tolerable. What do you think about that? Best regards, DrTT