Hacker News Reader

Comment by jarcane | Hacker News Reader

Purescript[1] is also gaining some traction and even has a pretty nice looking book out. [2]

It has some changes however; most notably it's strictly evaluated rather than lazy, and there are differences in how it handles type variables. [3]

Personally though, I've grown more fond of F# than Haskell; I only wish the documentation for Websharper and Funscript was more solid.

[1] http://www.purescript.org/ [2] https://leanpub.com/purescript/read [3] https://github.com/purescript/purescript/wiki/Differences-fr...

View on HN

Elm is actually 3 things rolled into one:

1. an language very similar to Haskell

2. a set of runtime libraries

3. a technique for modeling a GUI as a declarative state machine

PureScript only competes with #1 and #2 here. Where Elm really shines is #3, which #2 helps with a lot.

Technically #3 could be done in any language. But it really helps to model it in such an expressive language with immutable data and no side-effects (except via Signals).

I won't argue that Elm does anything other than an exemplary job at #3, but it is worth noting that there are some interesting efforts to build similar functionality in PureScript libraries:

https://github.com/paf31/purescript-thermite

https://github.com/kRITZCREEK/reactive-psc

https://github.com/bodil/purescript-signal

https://github.com/michaelficarra/purescript-demo-mario

https://github.com/mechairoi/purescript-frp-rabbit

To me, this is the benefit of PureScript - yes, you have to do a little more work, because you don't get these things for free from the compiler and tools, but you gain complete control over your application structure. You're not forced to work in some ambient Signal category.

You can probably implement Elm in PureScript pretty trivially, AFAICT. AFAIK Elm doesn't have any static guarantees about lack-of-space leaks or lack-of-time leaks. Or, maybe it just lacks higher-order-signals? (Which would mostly prevent those sorts of things happening). I found Neel Krishnaswami's papers on a static way to decide/prevent these things statically very interesting. I haven't found any implementation of his ideas, but they seem pretty solid: http://www.cs.bham.ac.uk/~krishnan/

Reply on news.ycombinator.com