How do callbacks change the state of objects in purely functional programming?

Question

Here's the problem: the GUI button has a callback that switches its state from marked to unchecked.

In imperative programming languages, this is very simple to implement: just change the state of the button. For example:

void callback(Button btn) { btn.setChecked(!btn.getChecked()); } 

But with purely functional programming, the callback cannot change the state of the object. The only thing the callback can do is create a new Button object with a new state. For example:

 Button callback(Button btn) { return new Button(!btn.checked); } 

The button created by the above callback will not be part of the graphical interface of the program, since the external function should receive the result of the callback and reintegrate the new value of the button into the graphical interface.

In addition, the button should not have callbacks with the above type signature, since button callbacks should be common. That is, the signature of the callback type will be:

 Object callback(Object object); 

The only solution I can think of in purely functional code is callbacks to accept and return a global GUI, for example:

 GUI callback(GUI gui, Button btn) { ...bla bla bla recreate the gui tre ... } 

So, how do I do this in purely functional code? how does my purely functional callback change the state of a button?

Answer 1

Probably the most elegant way to develop graphical interfaces in pure functional form is Functional reactive programming - see also this SO question and the HaskellWiki page .

If you do this, you will not use callbacks per se, but rather define functions that explain how "behavior" should evolve over time and with the help of the user. Clicking the button will be an “event” that would affect the corresponding behavior.

If you want to stick with a more traditional callback model, then I think some degree of peremptory behavior is required.

However, you can minimize the amount of variability, for example, by having only one mutable top-level value that represents the entire current state of the program, perhaps somewhat similar to the type of GUI that you specified above. The value will have some complex algebraic data type that contains everything that can change.

You can also use abstractions that restrict access to this top-level state, for example. restricting access only to certain parts and only providing access to these abstractions to specific callbacks.

Answer 2

Short answer: they (callbacks) cannot. Do not try to pull the imperative style into a functional world.
Possible solutions:

• You create a new button and re-integrate it into your graphical interface (as you already mentioned). Most functional graphical interfaces will actually do just that.
• Your button becomes an endless lazy stream of states where a new event is requested on the event. This, in fact, is also an example of reactive programming (I know that you read Wikipedia on this subject, but sometimes Wikipedia articles are not enough). In this case, your “callback” is a function to get a new state and prepare the “next” one.