Hacker News Reader

Comment by tlarkworthy | Hacker News Reader

I have been studying this, Elm explicitly forbids "signals of signals". This basically bans dynamic mutation of the dataflow graph and makes dynamic Gui's very difficult. The solution is not to enable signals of signals, because they are a source of problems. The solution would be to hoist all the functions up one level and operate on a dataflow graph comprised of transformations of signal transforms. This will kill many of the nice properties of Elm (hot code replacement), but the cost of the current system is that its unusable for application context switches and dynamic GUIs. In the literature the high level style of FRP is called AFRP (arrowized FRP).

I am currently prototyping AFRP ideas in Typescript and RxJS, although its very early days and basically not usable ATM. https://github.com/tomlarkworthy/animaxe (a better typed version is in a branch and not compiling ATM)

View on HN

It looks like you can always avoid needing signals of signals by declaring one signal for each type, not a signal for each instance.

All instances of the same message type can share a signal, as long as the messages contain a unique key to distinguish between objects, and the code that lives downstream filters events by key.

It's much like a database-backed app where you don't dynamically create tables while your app is running. Instead, instances are stored within a table and identified by their keys.

No because you must might want a whole subgraph of dataflow associated with each instance. You are right you can perhaps do it with collection primitives as signals. Creating tables is appropriate for multi tenancy apps. Or apps that let you build apps, or analogously, a drawing program for graphics.

So, an app builder will need to simulate signals in a purely functional way, rather than using the top-level, native signals. But if you want to write a debugger for the child apps, you need something like an interpreter anyway.

At the top level you might just have a single native signal for all events delivered to any child app.

But I agree that the ability to start and stop reactive sub-programs would be a useful thing.

What do you mean by "dynamic GUI"? As opposed to what other kind of GUI?

A GUI with n buttons and a button to add and remove additional buttons

Like this: http://evancz.github.io/elm-architecture-tutorial/examples/7... ?

Yes ... but with a more natural implemention. That style won't scale up to real dynamic programs though without significant routing infrastructure outside of Elm's typical constructs.

Without going on too long a tangent, this hasn't been our experience in practice at NoRedInk. We've built some absurdly complex UIs involving those same design needs, and what you're describing just has not been a problem.

I'd suggest giving it a try. It's really nice. :)

Naturalness as a criterion for evaluating languages is not that compelling to me. I think a honest word for what people usually mean when they say "natural" in this context is the word "familiar". I know plenty of programmers who think that OOP is just more "natural" than FP.

What I really would like to see is a counter example. Some GUI that just can not be done in Elm.

> What I really would like to see is a counter example. Some GUI that just can not be done in Elm.

I'm on the Elm/FRP fence myself but your comment here reeks of turing tarpit:

"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy."

Reply on news.ycombinator.com