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