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:
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/
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).