Home » forums » LtU Forum

A Farewell to FRP in Elm

Making signals unnecessary with The Elm Architecture

...the big benefit is that Elm is now significantly easier to learn and use. As the design of subscriptions emerged, we saw that all the toughest concepts in Elm (signals, addresses, and ports) could collapse into simpler concepts in this new world. Elm is designed for ease-of-use, so I was delighted to stumble upon a path that would take us farther with fewer concepts. To put this in more alarmist terms, everything related to signals has been replaced with something simpler and nicer.

By Greg Buchholz at 2016-05-10 15:24 | LtU Forum | previous forum topic | next forum topic | other blogs | 32723 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Model-Update-View?

I am interested in reading about subscriptions, but my five minute perusal of your links didn't yield much fruit. Is it the same as Model-Update-View?

By Matt M at Tue, 2016-05-10 17:02 | login or register to post comments

no and yes and no

dis/agreement.

By raould at Tue, 2016-05-10 20:32 | login or register to post comments

Remove flatmap, prioritize cells?

As far as I can tell, this is classic FRP, with an emphasis on:

* Not supporting higher-order primitives. Ex: flatmap/switch .

* Promote use of cells. Ex: allow use of callbacks to inject a value into a source stream

I found flatmap always hard to teach, and one of the few advances from popular 2000s era one-way databinding libraries. FWIW, at work, we primarily use that in specific parts of our code, and for most cross-module stuff, are moving to Falcor, which is a similar flat, centralized databinding layer.

Cells are awesome. They're ignored in literature, but useful in practice :)

By lmeyerov at Wed, 2016-05-11 02:05 | login or register to post comments

Nah...

Nick Benton and I wrote a paper, Ultrametric Semantics of Reactive Programs, which contains a correctness proof of an FRP system implemented using (a version of) cells.

These days, though, I don't think you need them. You can implement switching with booleans and if-then-else, and schedule code for execution using plain old thunks and memoization (see Higher-Order Functional Reactive Programming without Spacetime Leaks), and then you can extend the model to asynchronous programming using plain old callbacks (see my new draft with Jennifer Paykin and Steve Zdancewic, The Essence of Event-Driven Programming).

No fancy implementation strategies are needed, if you structure the programming model right.

By neelk at Wed, 2016-05-11 09:59 | login or register to post comments

Not as worried

I was never worried about the impl of cells, but usability implications. However, now on my reading list, thanks!

(Diff story for switch, where I'm still iffy, but my initial comment here was still also about usability and software arch, not impl. I think that's the Elm.concern as well.)

By lmeyerov at Wed, 2016-05-11 15:35 | login or register to post comments