3 ms·

Functional reactive programming provides a decent abstraction for functional UIs: http://stackoverflow.com/questions/1028250/what-is-functional-reactive-program

Functional reactive programming provides a decent abstraction for functional UIs: http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming http://stackoverflow.com/questions/1028250/what-is-functiona... My understanding is that FRP represents the state of the program as a function of a stream of events. Each time a new event comes in, information about the event is used to create a new state based on the current one. Ultimately the global state of the program gets mutated, but this fact can be abstracted away; program logic looks like: λ event oldState -> newState

demallien 16y ago
Interesting, but I don't think it gets to the heart of what I'm trying to get at. Imagine that instead of drawing a box where the mouse cursor is, you want to draw 20 words of anti-aliased text. Calculating that text is too slow to do repeatedly every time the pointer moves, so you're going to have to write the text into a once into buffer, and then just blit the buffer to the screen. But that buffer is state. It needs to be updated to when the text is updated. So maybe I could use FRP to automatically recalculate the buffer when the text changes. But nnow I point out that you can't just arbitrarily allocate a graphics buffer for each piece of text, it would take way too much memory. I could just allocate a buffer only when the buffer is actually on the screen, and not when it's clipped. But even just calculating if the object is on the screen can become very costly when you are working with complicated graphics geometries. Anyway, I gave up doing it in a functional manner, and just embraced the inherent state-iness of UI work. But I'd love to learn if I've been doing it wrong! (incidentally, Apple get's around this when working with UIs by 'binding' variables to graphical objects - if one changes, the other changes automatically - eg, moving a slider changes the variable representing the value of the slider. Changing the variable changes the slider on-screen). All done in Objective-C by making heavy use of forced setters/getters.
- timrobinson 16y ago
  Calculating that text is too slow to do repeatedly every time the pointer moves, so you're going to have to write the text into a once into buffer, and then just blit the buffer to the screen This sounds like an example of memoization. The buffer is allocated once, on demand, and presumably reallocated when the text changes. Mutable state is involved, but it's hidden inside your memoization function, which is typically provided by the language. You supply a function like: λ string -> GraphicsBuffer.

demallien 16y ago

Interesting, but I don't think it gets to the heart of what I'm trying to get at. Imagine that instead of drawing a box where the mouse cursor is, you want to draw 20 words of anti-aliased text. Calculating that text is too slow to do repeatedly every time the pointer moves, so you're going to have to write the text into a once into buffer, and then just blit the buffer to the screen. But that buffer is state. It needs to be updated to when the text is updated. So maybe I could use FRP to automatically recalculate the buffer when the text changes. But nnow I point out that you can't just arbitrarily allocate a graphics buffer for each piece of text, it would take way too much memory. I could just allocate a buffer only when the buffer is actually on the screen, and not when it's clipped. But even just calculating if the object is on the screen can become very costly when you are working with complicated graphics geometries. Anyway, I gave up doing it in a functional manner, and just embraced the inherent state-iness of UI work. But I'd love to learn if I've been doing it wrong! (incidentally, Apple get's around this when working with UIs by 'binding' variables to graphical objects - if one changes, the other changes automatically - eg, moving a slider changes the variable representing the value of the slider. Changing the variable changes the slider on-screen). All done in Objective-C by making heavy use of forced setters/getters.

timrobinson 16y ago
Calculating that text is too slow to do repeatedly every time the pointer moves, so you're going to have to write the text into a once into buffer, and then just blit the buffer to the screen This sounds like an example of memoization. The buffer is allocated once, on demand, and presumably reallocated when the text changes. Mutable state is involved, but it's hidden inside your memoization function, which is typically provided by the language. You supply a function like: λ string -> GraphicsBuffer.