Can reflex-frp-dom be compiled with Haste?

[saurabhnanda]

If not, then why? Just curious because it seems that Haste compiles down to a smaller JS size, which is important from a production perspective.

Has anyone tried it? Any benchmarks between Haste and GHCJS?

[ryantrinkle]

When I last checked, Haste did not support System.Mem.Weak. Reflex requires weak references in order to work properly, and I doubt that it is possible to write an FRP system that doesn't require them. There may be other features that Haste doesn't have, but this is the big one I know of.

[saurabhnanda]

Thanks for replying. Do you know of any benchmark that compares Haste & GHCJS on size+speed of compiled JS code?

On Mon, Aug 22, 2016 at 5:39 PM, Ryan Trinkle notifications@github.com wrote:

When I last checked, Haste did not support System.Mem.Weak. Reflex requires weak references in order to work properly, and I doubt that it is possible to write an FRP system that doesn't require them. There may be other features that Haste doesn't have, but this is the big one I know of.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/reflex-frp/reflex-dom/issues/86#issuecomment-241393649, or mute the thread https://github.com/notifications/unsubscribe-auth/AABu0UnB_3EXVt5ZgOygPu0fv331km8dks5qiZFygaJpZM4JpmYb .

[ryantrinkle]

No problem! Since Haste can't support Reflex at a technical level, I haven't put any time into testing or benchmarking it. However, my guess would be that its output is probably smaller and at least a little faster.

[saurabhnanda]

I know this doesn't concern the reflex-frp project, but if you could indulge me a little bit, what is the technical difference between Haste & GHCJS? From Haste's home page:

Haste is an implementation of the Haskell functional programming language, geared towards web applications. Haste is based on the de facto standard GHC compiler, which means that it supports the full Haskell language, including GHC extensions and produces highly optimized code but comes with an extended set of standard libraries.

Is System.Mem.Weak a GHC core feature or a GHCJS extension?

[mightybyte]

GHC compiles Haskell code by performing a series of transformations into lower and lower level representations. Something like this: Haskell -> A -> B -> C -> Assembly language.

Haste and GHCJS do not compile Haskell directly to Javascript. They use GHC to perform some of those transformations, then jump in and convert one of the intermediate representations to Javascript. My understanding is that the basic technical difference between Haste and GHCJS is that GHCJS jumps in at a lower level in the chain. So if we use my above notional GHC diagram, it would be something like this:

Haste: B -> Javascript

GHCJS: C -> Javascript

The further down you start, the more closely you will match GHC.

[saurabhnanda]

Thanks for the explanation @mightybyte

It seems that System.Mem.Weak is core to GHC and Haste source code has some references to it

[ryantrinkle]

Yes, System.Mem.Weak is a core library for GHC. Although Haste does have stubs for it, as you can see, it does not actually function as a weak reference: https://github.com/valderman/haste-compiler/blob/9dbd810d3bc9aade6bb63746ff784690e7674554/lib/Weak.js

The net result of this is that anything relying on weak references will (presumably) leak memory on Haste.

[saurabhnanda]

Is this the only problem keeping reflex-frp from using Haste as a compiler? Did anyone try pestering the Haste team to implement weak-reference properly?

Btw, will reflex-starter at least compile on Haste, ignoring the memory leak for a moment?

@ryantrinkle I remember chatting about weak references on IRC as well. Would it be possible to explain why/how reflex-frp uses them and why they're required for JS callback (IIRC)? Btw, this comment says that they're not required since JS implements its own GC. Is it a misguided comment?

[saurabhnanda]

Feel free to close this issue if Haste is not on your roadmap at all. I'm just trying to understand things better. From a production standpoint, Haste's smaller JS size & better speed is obviously desirable.

[3noch]

@saurabhnanda @luite is working on JS size right now. He expects GHCJS to have better JS size in the next couple months.

[saurabhnanda]

From Haste's Github repo:

Supports all GHC extensions except Template Haskell

That could a significant downer for people using Persistent to generate common record-types to share between frontend and backend.

[ryantrinkle]

@saurabhnanda I don't know what will/won't work on Haste. Reflex also uses STM, which is a pretty advanced feature, so it's possible that would also be an issue. I'm not sure whether reflex-starter will work with Haste, but if you try it, i'd love to hear how it goes!

I believe the Haste comment is incorrect. As far as I know, JavaScript's built-in GC does not support weak references, so a (substantially) more complex approach to provide their behavior.

Haste is not on my roadmap for now, but I'm more than happy to discuss it, and it would be great if it supported reflex in the future.

And, yes, Template Haskell is extremely important, at least for my applications.

[saurabhnanda]

Here's my short-lived experience FWIW :)

[ryantrinkle]

Closing, since I think we've gone over the major points. Feel free to continue the discussion, and we can reopen if necessary.