Dynamically creating new FRP-Widgets - do I need switch for that?

[jhegedus42]

Suppose I want to allow the user to create new FRP-Widgets at runtime, for example a new SButton here.

Questions:

• For that I need some sort of switch right ? I mean, there is no other solution for that than using switch. If I understand correctly such a situation (adding/removing widgets) is one of the main use cases of switch because GUIs change dynamically all the time, so the graph needs to change.

• Is this use case discussed in the book ? If yes where ? I read it quickly through last evening, looking for this, but did not find it. The closest thing I found was the screen switching in Zombicus.

[the-real-blackh]

Hi,

Yes, a switch is absolutely require to achieve this. To cut a long story short, this is the philosophically correct way to do it and it would work well. We are breaking the law slightly, pretending that widget creation is not I/O. Basically we are pretending we are working with an imaginary functional GUI library.

The only discussion of this in the book is in Chapter 7, and the screen switching is the closest to that use case.

Steve

[jhegedus42]

Basically we are pretending we are working with an imaginary functional GUI library.

React is pretty functional in this respect. React "widgets" (without state, having only props) are described purely by virtual dom, which is referentally transparent, immutable.

So I have the gut feeling that it could fit nicely with FRP.

[dakom]

Yes, a switch is absolutely require to achieve this. To cut a long story short, this is the philosophically correct way to do it and it would work well.

Is it possible to post a super barebones code sample of how to do this? I'm biased to the Typescript implementation but any language is fine... I feel like switch is something I don't really get yet

[the-real-blackh]

I may have given you the wrong advice, actually. Creating new widgets can be done any time. It's only if you want their output to be used in existing FRP logic that you'll need a switch - but the need for this should be obvious.

What's your use case?

[dakom]

Interesting!

I don't really have a specific use-case with code yet, but I'm hoping to migrate some stuff over to FRP which is basically like a drawing app.

In particular, the ability to add/remove stickers from the scene. I'd imagine each sticker is its own cell, rather than a Cell<Array<Sticker>> holder, but I'm not sure yet.

More generally it would be helpful to have more examples of switch to look at, which I guess is related to the overall recipes/wiki thing

[dakom]

I'm playing around with this, and adding stickers is pretty easy...either accum or collect can simply push new Cells onto a List.

For removing stickers though - I'm not sure how to go about it. I'm trying to keep everything as pure so there's no pointers/references to hold onto... how is something like this done in Haskell (or more specifically, how should it be done in FRP)? Do you give each item an auto-incremented counter/id and then cull the list by that?

[the-real-blackh]

The usual pattern is to have a cell along the lines of Cell<ImmutableMap<Int,Cell>>, which is defined a hold of the merge of two streams: one for adding items, and one for removing them. When adding items, you have to allocate a unique number. When removing them, your logic has to remember the number that was allocated.

Basically in real functional programming, there is no such thing as a reference to an object. Because of that, you have to use unique keys - usually integers - to reference things. You might find it useful to use Supply - which is in the book and will be somewhere in the examples directory - to allocate unique numbers. Alternatively, you can just get the highest key in the ImmutableMap data structure and add 1 to it.

Another way to view this is that in functional programming, data structures (the word "objects" isn't really used) do not have any identity other than their value. If they contain functions, then they don't have any identity at all, because functions are opaque: there is no way to ask if one function equals another. Cells and streams are the same. There is no equality operation for them. Java will let you compare the references to them, but in FRP/FP that is a totally invalid thing to do.

[dakom]

Oh man... I forgot how much fun FRP can be! This is so elegant it feels unfair... a time-varying sticker accumulating thing

1. makeStickerFromUrl() takes a string and returns Cell<Maybe<Sticker>> (not shown here because under the hood it loads the graphics etc. - but basically it sends either a Nothing or a Just to its Cell)
2. sStickerAddUrl gets sent the url request and accumulates the makeStickerUrl() calls into a list, resulting in a new Cell of type Cell<Array<Cell<Maybe<Sticker>>>>
3. Since Cells are fantasy-land compatible, we can map that Cell with S.sequence(Cell) to turn that into Cell<Cell<Array<Maybe<Sticker>>>>
4. We can then flatten it via Cell.switchC to get Cell<Array<Maybe<Sticker>>> - in other words a time-varying list of all the (maybe) stickers!

Unbelievable that all of this is simply:

const cStickers =
    Cell.switchC(
        sStickerAddUrl.accum([], (url, list) =>
            list.concat(makeStickerFromUrl(url))
        )
        .map(S.sequence(Cell))
    );

!!!