Hacker News Reader

Comment by seanmcdirmid | Hacker News Reader

I've glanced at the PLDI paper and would definitely consider Elm to be FRP, more in Conal's vision than say Flapjax. But I don't get what new contribution Elm makes to push-based FRP beyond being a nice implementation of it?

View on HN

The most novel stuff was about how to handle asynchrony and concurrency without unexpected/unwanted glitches, though I think formulating things in a way that is simple, accessible, and efficient was important too. My thesis ( http://www.testblogpleaseignore.com/wp-content/uploads/2012/... ) goes through all of the previous literature that I could find at the time. It frames my view on Elm fits into prior work and how I understood things at that time, but that section got cut from the PLDI version unfortunately.

Ok, fair enough. I never tried calling my work FRP before since...well, I threw out the functions and embraced glitches. You should have a look at Conal's vertigo work if you haven't already. It will give you cool things to do functionally with your GPU support.

http://conal.net/Vertigo/

Ah, cool! I think he told me about this work when we chatted at ICFP last year, but wasn't able to find it. So thanks for the link!

One thing that this work requires is some from of symbolic differentiation. Basically, given some expression e, you have to compute, via a symbolic analysis on e's structure, a derivative for e, e'. e' can then be used to compute normals used for shading, replacing the need for a hand crafted normal map (you can also approximate normals via sampling, but if you have a functional definition of a surface, why not just use derivatives!).

This definitely requires some compiler support, but the purity of Elm should be helpful in that regard.

Reply on news.ycombinator.com