Asterius – Haskell to WebAssembly Compiler | Hacker News Reader

Asterius – Haskell to WebAssembly Compiler

github.com

156 pointsentelechy33 comments

See also webghc which has an alternative strategy to writing a new RTS and code generator. They are cross compiling to wasm via llvm. https://webghc.github.io/2019/01/18/state-of-webghc-january-...

I expect that relying on LLVM going forward will be the popular approach for Haskell and other languages (there's so much momentum behind LLVM and it's made to be built upon), it's fantastic to see people entering this space.

Despite the amount of derision Javascript and the web-as-a-platform idea is met with, the amount of innovation is undeniable. I personally think the web is the best platform (at the very least, it's the devil almost everyone knows) -- it's already ubiquitous, has more-than-good-enough solutions for most things and is supported by very huge companies and open source naturally. One of the main hangups for those who dislike the web-as-a-platform idea spreading usually call out the terribleness of Javascript the language -- and though I think transpiled solutions like Typescript[0] and Elm[1]/Purescript[2] fix this issue, the introduction of WASM will finally completely obliterate this long-standing hangup. You want to write some other language for your JS frontend? Soon you'll be able to.

JavaFX/QT/GTK/WxWidgets/etc people you had your chance (in the last decade or two) to create simple, cross-platform yet sufficiently feature full implementations and people are choosing bundling an entire browser to get away from the tools you're giving them. If someone develops a sufficient stripped down browser rendering interface or if projects like ion[3] take off, even more people (with relatively simple apps to write) will use the web platform I think.

As WASM gets better, the "native UI & speed" island is going to continue to shrink, in my estimation. Of course you've also got approaches like Flutter out there trying to render every single pixel (!), with enough weight to actually make it happen and provide full sets of widgets and even work on a desktop embedder[4] (shame about the only viable language being dart though...).

[0]: https://www.typescriptlang.org/

[1]: http://elm-lang.org/

[2]: http://www.purescript.org/

[3]: https://github.com/justinmichaud/ion

[4]: https://github.com/Drakirus/go-flutter-desktop-embedder

I'll add a fifth link since Google is actually working on a desktop embedder for Flutter themselves.

[5]: https://github.com/google/flutter-desktop-embedding

More precisely, someone who works at Google is working on that:

This is not an officially supported Google product. This is an exploratory effort, and is not part of the Flutter project.

It being under the google GitHub organization doesn't mean much about the backing, since Google demands copyright for all kinds of things their employees do.

> I expect that relying on LLVM going forward will be the popular approach for Haskell and other languages

My vague understanding that might be outdated by a few years is that LLVM isn't a very nice target for garbage collected languages. It does have support for GC hooks, stack maps etc., but somehow people are (were?) struggling to make it all work efficiently in the real world.

There must be other factors as well, as a Haskell LLVM backend has existed for years. Here's a list of problems with LLVM for this use case pointed out two years ago: https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend

Surprised to see that no one has mentioned GHCJS <https://github.com/ghcjs/ghcjs> still.

I have used it[0] a year ago and despite my shallow understanding of Haskell, I have managed to port my CLI app to Haskell fairly easily!

[0]: https://github.com/boramalper/boolexman

My experiences with GHCjs have been positive, though admittedly not very deep.

It's not the same though. GHCJS is a Haskell to JS source compiler (transpiler?). Webassembly is a lower level altogether.

It's not the same. It's certainly relevant.

I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?

Presumably it’s implemented “natively”. Just like it would be on a native pl.

I don’t think it has gc yet ..

So far they use the "don't" approach to garbage collection. It would have to be implemented.like the rest of the rts.

I guess parts of the c code could be transpiled but something low-level like the gc relies on details like register pinning.

Most likely the same way as in any hardware CPU without support for GC memory tagging.

What is hw support for GC mem tagging? I didnt realize such a thing existed.

It's something that has been researched, but not deployed. It would implement GC memory tagging in the CPU or even the memory controller. Google Scholar should produce some good hits.

Surely it was deployed, in the original Lisp Machines hardware.

Right. I forgot about those.

It existed on Lisp machines.

https://en.wikipedia.org/wiki/Lisp_machine

"Lisp Hardware Architecture: The Explorer II and beyond"

https://3e8.org/pub/scheme/doc/lisp-pointers/v1i6/p13-dussud...

"Garbage collection in a large LISP system"

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.125....

"KIM 20 : A SYMBOLIC RISC MICROPROCESSOR FOR EMBEDDED ADVANCED CONTROL "

https://www.computer.org/csdl/proceedings/easic/1990/2066/00...

The failed iAPX 432 processor from Intel also supported it.

https://en.wikipedia.org/wiki/Intel_iAPX_432#Garbage_collect...

https://news.ycombinator.com/item?id=9448712

C and ASM don't have a GC either, and yet we can build GC collected languages on top of them. So it will be eventually be solved in the same fashion: By building a runtime environment on top of the underlying machine, which performs memory management incl. garbage collection.

Depending on how the runtime for "native Haskell" is implemented, the effort might be everything from just cross-compile it to building a completely separate runtime.

In assembly language, you can build an accurate garbage collector for your assembly language application. There are no hidden "not user servicable" areas in the run-time, like in C. You can set up your calling and framing conventions so the GC can trace the stack and know exactly where the root pointers are.

The consensus of "the same way they do in native code" is a probable approach, but it's worth calling out an additional complication in this setting: you might wind up working with two garbage collectors, with references in one keeping objects in the other alive. This isn't intractable, but it is messy.

Yes, like the IE memory leaks (and early Mozilla leaks) where DOM and JavaScript objects are collected in a different way, so can easily get stuck in unfreeable reference cycles.

Old Frameworks have to do perverse things to break those cycles, and if they don't, the browsers leaked memory over time.

It would be sad if that came back to modern browsers, due to WASM and DOM using separate collectors. Or worse, multiple WASM components, (perhaps in different languages, perhaps not, but all different collectors), holding indirect, accidental references to each other because someone decided to use the components in the same DOM.

Hi, asterius main dev here. Garbage collection support is near; we're working actively on it, and after a few regressions are fixed it'll be available on master.

It'll be a copying GC, with builtin support to automatically free unused JavaScript references in the Haskell heap. It's also possible to plug in more fancy gc algorithms later (e.g. generational, or concurrent ones with read barriers).

To be clear, this will be your own GC bundled with each application, not an interface to the host browser's GC?

Indeed it's not an interface to the browser's gc.

There does exist a wasm anyref proposal which enables manipulating opaque references in wasm and a gc proposal for further allocating/using such garbage collected objects. However, basing our gc on those is currently less pragmatic than rolling our own :)

Client-side pandoc would actually be reaaaal interesting

As far as I'm concerned, it already exists in two forms:

1. https://try.pandoc.org/

2. http://markup.rocks/

Are those sites using Emscripten or just passing your docs to a server to process?

Markup.rocks says it is client side and appears to be using ghcjs: https://github.com/osener/markup.rocks/blob/master/Makefile#...

Cool! Right now I run a docker container with pandoc on heroku in order to do stuff like make decent PDFs from my iPad... hmm...

(1) isn’t client-side.

> $.getJSON("/cgi-bin/trypandoc", { from: from, to: to, text: text },

Another 'Haskell to WebAssembly' project:

https://github.com/dfinity/dhc

Reply on news.ycombinator.com