Make language fully declarative

[spersson]

Over many years I have thought about how QML could be improved upon. One of the ideas that stuck with me was
to go fully declarative, in other words getting rid of event handlers and imperative statements. They would be replaced
with stateful memory expressions.

How would it look?

Before

export App := Window {
    Button {
        property<int> count: 0;
        clicked => {count += 1}
        text: "You clicked {count} times."
    }
}

After

export App := Window {
    Button {
        property<int> count: Memory { first: 0; then: if click.triggered { self + 1; }  }
        text: "You clicked {count} times."
    }
}

Details

The Memory{...} expression introduces a memory cell into an expression. The memory cell
has two mandatory parts "first" and "then". There's nothing special about the first-expression, it just assigns a value
at the time of creation of the parent object. The "then-expression" gets called directly after the first-expression and then again whenever any of it's inputs changes. It is a bit unusual because it is allowed to access the
memory cells own current value in order to express what the next value for the property should be. Here I suggested
the keyword self to do this. Another unusual thing is that it is allowed to not always return a value, in which case the
compiler adds an else clause to the top level if expression that just returns self (meaning the value doesn't change).
This is of course just a convenience. If the then-expression would be something like self + 1 you would get a run-away
value that goes to infinity. Clearly that can't be allowed. I suggest that the compiler checks any access to self must
be guarded by an if-clause that checks for some signal having been triggered.
Removing imperative statements, assignments and side-effecting function calls, is not strictly necessary for the suggested
addition of memory cells, it's just that it becomes possible. One option could be to keep at least assignments in expressions
where they would only be allowed to mutate local variables. In the end such an expression is still a pure function.
Emitting a signal does not return a value, it's a function call that calls registered handlers purely for them to have side effects.
As such they don't fit in any more.

Signals

Signals would need to change to be just data. I suggest that it can be done with a data type called Signal which would
be a built in type. It would be a simple object with just a single property called triggered. This boolean is false
all the time except when the signal is emitted, at which time it would be true for the shortest possible time. Once
all downstream users in the data flow graph has updated themselves to react to the signal being true it then goes
back to false again and the downstream data flow again needs to be updated with the false value (expect this update
to stop propagating quickly since most expressions are not expected to change value when a signal becomes deactivated).
It would only be interesting to use a trigger from then-expressions of memory cells where the fact that it was true
for an instant can be remembered. This may even be enforced or warned about. A signal object would be allowed
to have other properties added, just like any other object. Such properties (for example coordinates of a click event)
would only have valid values at the time when triggered. Similar to accessing self from a then-expression the
compiler should probably check that any access to properties of a signal is only done from within a conditionally
executed expression which has checked that the "triggered" property of that same signal is true. But that becomes a problem when defining a signal based on another signal, the following example show access to other properties of an event.

Rectangle {
  area := TouchArea { fill: parent }
  bomb_dropped := Signal {
    triggered: gameplay_active && area.click.triggered;
    property<float> longitude: area.click.x / area.width;
    property<float> latitude: area.click.y / area.height;
  }
}

Here I think the rule could be to simply allow access inside of signal-property expressions to properties of signals which triggered status is used in the own triggered expression. Not fully thought out, but not making an exception would make the above very ugly and repetitive.

Advantages

• Think of this example: width: 2*height. The person reading the code could easily think that width will always stay twice the height. But actually there could be some event handler that changes the value of this property in the event of some signal being emitted. This hurts the ability to reason about code you are reading. Properties being private by default helps to control this uncertainty but it is still more troublesome to be sure what values a property will have during its lifetime compared to this current proposal. With fully declarative language the expression for a property is the only thing that defines what values a property can take and you can see it right there. Well, except for inheritance and overrides. But that is just such a powerful and nice thing to have.
• Very related to the above, but think about scalability. If a property can be changed by ten different event handlers it can get complex to figure out if some will always take priority over some other. With this proposal it all becomes just one big expression where priorities are clearly spelled out. For this argument to be true it might require a good if-elseif or switch/match expression that can scale up nicely.
• Simplification of concepts. Not sure, but I think that it's simpler to not mix imperative and functional code.
• If an event handler does many things then the data flow needs to be taken care of by the programmer ordering the statements of the handler correctly. With the current proposal the ordering of updates will be done automatically by the compiler, according to data flow. This is really quite a minor advantage.

Disadvantages

• I have never had time to implement this and it is not common in the world of programming languages. In researching this idea I only found the language LUSTRE has this. So that means I have very little experience with how this works in practice. And also it will be unfamiliar to most programmers. But the concept itself is really quite simple, just the application and consequence of how to structure a program might take some getting used to.
• Somebody wanting to see "what happens when I click this button" can no longer read a single event handler to see that. Instead the reactions will be scattered out in different property definitions. This is just the inverse of the advantage listed above.

More ideas

One idea could be to make signals directly usable as a boolean, by designating the triggered property as a default property which may be omitted. That could make usage look a bit shorter. Another way to say the same thing is to say that there is an automatic type conversion from Signal to boolean.

Summary

I think a core deciding factor between memory cells and event handlers is if you prioritize being able to scale up in how many signals affect the value of a certain property (all signals being checked in one expression), or if you prioritize being able to scale up in how many properties can be affected by a single signal (all assignments in one handler). Actually now that I think about it, this should be able to be measured on existing code bases.

[ogoffart]

Hi,

First, thanks for your suggestion, It really makes me happy to see people interested in our project.

I think the problem of not knowing where a property is modified is a real problem and it is indeed worth trying to improve the situation.
Notice that the language being properly typed, the compiler already know where a variable is modified and so a yet-do-be-written language server for IDE could easily offer a feature to see all use of a property, and filter on the location that modifies it.

Personally, I prefer seeing the signal handler near the button so that one can "see what happens when one press the button" and the triggered logic does not seem so intuitive to me.
For example, how would you rewrite the fax_number property binding of the fax number in the demo: https://github.com/sixtyfpsui/sixtyfps/blob/master/examples/printerdemo/ui/printerdemo.60#L121 ?

Here is another idea i think we could implement to make it easier to reason about the code.

Add a mutable keyword when declaring the property, letting the developer know that this property might be modified by some other signal handler. In the absence of the keyword, the property is not allowed to be modified by anything else than the binding itself. (a bit like the mut keyword in rust)

mutable property<int> count: 0;

Me may also need to allow binding to be marked as mutable:

Xxx {
   mutable count: 0;
}

This syntax not so pretty so perhaps we could have a prettier syntax to mark a binding a mutable.

property<int> count: mutable 0;
// or
property<int> count: mutable: 0;
// or
property<int> count: mutable(0);

Another thing to take in account are the states
I would say that changing the property in a state should still be allowed even if the binding was not marked as mutable, i see this keyword as really meaning that this is meant to be changed by an event/signal handler.

Would that help mitigate the downside of having normal signal handler?

[spersson]

Ah, that fax example is indeed a problem for my idea. What you have there are anonymous UI elements generated by basically mapping a collection. Since my idea would change the data direction from a mix of pull and push to purely pull direction, then of course the problem becomes how to pull data from an non-named item? Ehh. Only thing I can think of is to pull it out using indexing into that generated array of UI elements. But it would surely not be elegant so I believe you found a very good challenge to my proposal. :-)

I like your idea of marking properties mutable, because in practice my guess would be that it gives almost the same certainty about how and when a given property can change (when combined with IDE based cross references to write access locations, as you noted). Since it's a relatively simple modification it gives a lot of "bang for the buck". But how would it work together with libraries of components? If a library does not have the mutable keyword for a property then users of this component can't change it from event handlers? Library authors would have to remember to mark as mutable everything that a user might want to change. Perhaps the child class "override" can be allowed to change this mutability for any inherited property. Oh, and come to think of it, QML had that thing of read-only properties that only expose values from the host language, not allowed to be re-assigned. If you also plan to have that it might be a little confusing if non-mutable is not the same as read-only.

Perhaps another idea is to skip any mutable keyword and make a specialized IDE or editor for this language, then simply add different visual markers based on if effectively the property is being changed by states or by event handlers or both.

States have a similar trade-off as event handlers in that they scatter the logic for what values a property can take, but instead is able to collect all the effects of a certain condition being true into one place. In my head that classifies them bindings, not imperative assignments. So in that sense I agree with you not mark a mutable. But on the other hand the binding logic is now scattered. (My understanding is that the expression directly in a property declaration is not merely an initial value in this case since if no active state has an effect on this property it goes back to having that "direct" property binding active again). Having a second keyword, "statemut" , would be terrible. :)

In the end I think I might be obsessing a bit too much about certainty for the reader/poor guy stuck debugging. I started my QML-replacement thoughts with how it could be useful for control systems... that could explain why. For user interfaces it could very well be that it's more important to prioritize easy and flexible development.

Anyway, thanks for the kind and thoughtful answer. As you can see I was not completely convinced my idea was all that good but I thought I should mention it and get some criticism, toy around with it.

[ogoffart]

I like your idea of marking properties mutable [...]. But how would it work together with libraries of components? If a library does not have the mutable keyword for a property then users of this component can't change it from event handlers?

I think the key is that we would not mark the property itself as mutable but the binding. Which is why the binding is on the right hand side.
But perhaps we need both: a way to mark the property as const (so that nobody can change it) and a way to mark the binding as read-only (so that once assigned it can no longer change from the same component) and ideally const or read only would be a default unless specified otherwise. We just need to find a good syntax for it.

make a specialized IDE or editor for this language

This is planed #34
But we have put this on the side for now. However since rust has library to make LSP server implementation, and the compilerlib is a standalone library, it shouldn't be too hard.

States have a similar trade-off as event handlers in that they scatter the logic for what values a property can take,

That is true. But on the other hand, states are quite declarative.
We want to make our language Designer-Tool-Friendly, and a design tool can easily show all the possible value of a property in each different states.

My understanding is that the expression directly in a property declaration is not merely an initial value in this case since if no active state has an effect on this property it goes back to having that "direct" property binding active again)

That's right. I remember an idea about not allowing bindings on property that are changed in the states. So that one must use a default state instead. But i'm not sure if this is a good idea.