9 ms·

Asterius – Haskell to WebAssembly Compiler

156 points by entelechy 8y ago

rustlava 8y ago
⸮ ϱninnɒd wobɒʜƨ ƨi ƨwɘn ɿɘʞɔɒʜ
danharaj 8y ago
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-2019.html https://webghc.github.io/2019/01/18/state-of-webghc-january-...
- hardwaresofton 8y ago
  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/ https://www.typescriptlang.org/ [1]: http://elm-lang.org/ http://elm-lang.org/ [2]: http://www.purescript.org/ http://www.purescript.org/ [3]: https://github.com/justinmichaud/ion https://github.com/justinmichaud/ion [4]: https://github.com/Drakirus/go-flutter-desktop-embedder https://github.com/Drakirus/go-flutter-desktop-embedder
  - nvrspyx 8y ago
    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 https://github.com/google/flutter-desktop-embedding
    - detaro 8y ago
      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.
  - tom_mellior 8y ago
    > 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 https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend
deleted 8y ago
[deleted]
pushtheenvelope 8y ago
I'm curious how they solve garbage-collection, since last time I checked WebAssembly doesn't yet support that?
- JoelMcCracken 8y ago
  Presumably it’s implemented “natively”. Just like it would be on a native pl.
  - carterschonwald 8y ago
    I don’t think it has gc yet ..
- Tarean 8y ago
  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.
- pjmlp 8y ago
  Most likely the same way as in any hardware CPU without support for GC memory tagging.
  - weberc2 8y ago
    What is hw support for GC mem tagging? I didnt realize such a thing existed.
    - Solar19 8y ago
      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.
      - pjmlp 8y ago
allenleein 8y ago
Another 'Haskell to WebAssembly' project: https://github.com/dfinity/dhc https://github.com/dfinity/dhc
boramalper 8y ago
Surprised to see that no one has mentioned GHCJS <https://github.com/ghcjs/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 https://github.com/boramalper/boolexman
- dllthomas 8y ago
  My experiences with GHCjs have been positive, though admittedly not very deep.
- Mikeb85 8y ago
  It's not the same though. GHCJS is a Haskell to JS source compiler (transpiler?). Webassembly is a lower level altogether.
  - dllthomas 8y ago
    It's not the same. It's certainly relevant.
paultopia 8y ago
Client-side pandoc would actually be reaaaal interesting
- guiraldelli 8y ago
  As far as I'm concerned, it already exists in two forms: 1. https://try.pandoc.org/ https://try.pandoc.org/ 2. http://markup.rocks/ http://markup.rocks/
  - ghayes 8y ago
    Are those sites using Emscripten or just passing your docs to a server to process?
    - PowerfulWizard 8y ago
      Markup.rocks says it is client side and appears to be using ghcjs: https://github.com/osener/markup.rocks/blob/master/Makefile#L47 https://github.com/osener/markup.rocks/blob/master/Makefile#...
      - paultopia 8y ago
        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...
  - minitech 8y ago
    (1) isn’t client-side. > $.getJSON("/cgi-bin/trypandoc", { from: from, to: to, text: text },

156 points by entelechy 8y ago

⸮ ϱninnɒd wobɒʜƨ ƨi ƨwɘn ɿɘʞɔɒʜ

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-2019.html https://webghc.github.io/2019/01/18/state-of-webghc-january-...

hardwaresofton 8y ago
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/ https://www.typescriptlang.org/ [1]: http://elm-lang.org/ http://elm-lang.org/ [2]: http://www.purescript.org/ http://www.purescript.org/ [3]: https://github.com/justinmichaud/ion https://github.com/justinmichaud/ion [4]: https://github.com/Drakirus/go-flutter-desktop-embedder https://github.com/Drakirus/go-flutter-desktop-embedder
- nvrspyx 8y ago
  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 https://github.com/google/flutter-desktop-embedding
  - detaro 8y ago
    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.
- tom_mellior 8y ago
  > 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 https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend

deleted 8y ago

[deleted]

pushtheenvelope 8y ago

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

JoelMcCracken 8y ago
Presumably it’s implemented “natively”. Just like it would be on a native pl.
- carterschonwald 8y ago
  I don’t think it has gc yet ..
Tarean 8y ago
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.
pjmlp 8y ago
Most likely the same way as in any hardware CPU without support for GC memory tagging.
- weberc2 8y ago
  What is hw support for GC mem tagging? I didnt realize such a thing existed.
  - Solar19 8y ago
    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.
    - pjmlp 8y ago

allenleein 8y ago

Another 'Haskell to WebAssembly' project: https://github.com/dfinity/dhc https://github.com/dfinity/dhc

boramalper 8y ago

Surprised to see that no one has mentioned GHCJS <https://github.com/ghcjs/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 https://github.com/boramalper/boolexman

dllthomas 8y ago
My experiences with GHCjs have been positive, though admittedly not very deep.
Mikeb85 8y ago
It's not the same though. GHCJS is a Haskell to JS source compiler (transpiler?). Webassembly is a lower level altogether.
- dllthomas 8y ago
  It's not the same. It's certainly relevant.

paultopia 8y ago

Client-side pandoc would actually be reaaaal interesting

guiraldelli 8y ago
As far as I'm concerned, it already exists in two forms: 1. https://try.pandoc.org/ https://try.pandoc.org/ 2. http://markup.rocks/ http://markup.rocks/
- ghayes 8y ago
  Are those sites using Emscripten or just passing your docs to a server to process?
  - PowerfulWizard 8y ago
    Markup.rocks says it is client side and appears to be using ghcjs: https://github.com/osener/markup.rocks/blob/master/Makefile#L47 https://github.com/osener/markup.rocks/blob/master/Makefile#...
    - paultopia 8y ago
      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...
- minitech 8y ago
  (1) isn’t client-side. > $.getJSON("/cgi-bin/trypandoc", { from: from, to: to, text: text },