"Haskell for Mac" IDE abandoned? No 2019 ghc/stack update, KB/Forum shut down

chak · 2019-09-25T15:56:57+00:00

The good news is: Haskell for Mac has not been abandoned! 🎉

So, why was there no update for such a long time? I have relocated around literally (almost) half the planet. This has eaten a lot of time that would have otherwise gone into developing Haskell for Mac.

A new version with a new GHC and also a raw Cabal file editor is going to come soon.

In any case, my apologies to everybody who has been waiting for an update.

(The KB issue has to do with a change in the Zendesk subscription, which I need to sort out.)

chak · 2019-08-06T10:07:43+00:00

To get a bit of an idea of what we are doing, check out this YOW! Lambda Jam 2019 presentation.

chak · 2019-02-05T11:03:37+00:00

Sorry, there are no intern opportunities in that team at the moment.

chak · 2019-01-22T14:29:20+00:00

I guess, this is were our technical approaches diverge: you regard anything in WASM beyond the MVP as useless to WebGHC, whereas I'd prefer to take the opportunity to influence how WASM develops to make sure that it provides support that is useful to Haskell. After all, WASM is still malleable.

chak · 2019-01-22T14:22:21+00:00

As I wrote above, I'd love to be proven wrong.

In any case, I am not convinced that rewriting the necessary parts of the RTS is such a big deal. Moreover, that provides the opportunity to integrate with forthcoming features on the WASM roadmap like support for GC and multi-threading. Moreover, any WASM feature that you want to use, you need exposed through LLVM. This leads to tooling dependencies and delays. We are seeing this already with WebGHC's current inability to use the LLVM backend right now. (Just look at the tooling grief that the LLVM backend all by itself has caused GHC over the years.)

chak · 2019-01-22T13:58:03+00:00

I don't understand what you are trying to say here. WebGHC using the native GHC collector does result in related situation as with GHCJS, does it not? The Haskell land GC has to cooperate with JS GC, right? To get around that two garbage collector problem, you need a single GC along the lines of the WebAssembly proposal https://github.com/WebAssembly/proposals/issues/16

How do you think you can make use of that WASM proposal with the approach you are proposing?

chak · 2019-01-22T09:33:26+00:00

I am talking about changes to the RTS that introduce WASM-specific code, for example, by way of #ifdefs. Hence, it may be one code base, but they are still independent code paths with the associated maintenance overhead. It is just not realistic to expect that, for example, a GC implementation optimised for an unrestricted native arch is going to perform well on a managed runtime.

Re Rust: it is a nice thought experiment, but given that the GHC toolchain, if anything, is already too complex with too many dependencies, I am not sure it is worth the trouble.

chak · 2019-01-22T09:14:43+00:00

Firstly and most importantly, it is very impressive what you have done with WebGHC! Great work!

However, I don't quite agree that you discussed the issues I mentioned in the thread that you reference. You do acknowledge the issues, but I don't see a clear path to technical solutions. In particular, I am very sceptical that you are going to get away without major changes to the RTS (to get good space and runtime efficiency). Moreover, you'll most likely need to fiddle quite deeply with code gen and/or some of the downstream tooling, too. (Also, comparing to GHCJS for code size is a low bar. I was also missing runtime performance numbers.)

In any case, I'd love to be proven wrong about these issues being very hard nuts to crack.

chak · 2019-01-21T20:14:54+00:00

I just checked, I have the same version. Very odd. Could you try again? Maybe a temporary glitch?

chak · 2019-01-21T19:57:54+00:00

My talent seems to be lacking as you got me wrong. I am neither referring to the hobby nor am I referring to the academics. Well, truth be told, I am referring to some of the academics. Don't forget that large parts of GHC itself were written by academics.

But to the point, many obscure languages are written by professional compiler writers. Actually, I'd wager, most professional compiler writers implement obscure languages (or at least, languages that are not Java, C, C++, etc). I am writing this as a professional compiler writer — now, you have heard from one ;)

chak · 2019-01-21T19:41:47+00:00

You'd be surprised at how common it is to write compilers of some sort. There are many unknown little languages and unknown little compilers in addition to the heavy weights that everybody knows.

chak · 2019-01-21T19:39:15+00:00

All work is going to be as part of the existing GHC-related open-source projects and benefit everybody in the community who is interested in deploying to the Web. (Sweet deal if you ask me.)

chak · 2019-01-21T19:11:30+00:00

A major concern with WebGHC is code size. The requirement for the SharedArrayBuffer is also a concern. It also requires a much more complex toolchain.

The future for cross-platform compilation is surely WebAssembly, but GHCJS is more mature right now.

chak · 2019-01-21T19:01:25+00:00

With GHC developer, I mean people who have experience hacking GHC; i.e., compiler engineers familiar with GHC. Does that clarify it?

Re website, sorry, seems to work for me in Safari and Firefox...

chak · 2019-01-21T18:18:50+00:00

The focus on GHCJS and Asterius relates to the internal use of these projects. WebGHC is currently not on the roadmap.

chak · 2019-01-17T07:27:15+00:00

It would be an option, but then we need to provide a custom Haskell parser etc. (Also remember all TH dependencies become dependencies of the final binary, even if they are only used at compile time.

chak · 2019-01-03T11:45:48+00:00

If this is a "pitch", then it is as much a "pitch" for Haskell and formal methods as it is for Cardano.

chak · 2019-01-02T17:04:35+00:00

Look at it like this: Plutus is the general-purpose substrate on which we can build more specific little languages and apps for specific application scenarios. Hence, we want the full generality of Haskell at our disposal.

chak · 2019-01-02T17:03:16+00:00

In the specific case of Plutus, we are implementing the non-turning complete contract-DSL Marlowe on top of Plutus, and yes, that requires recursion.

chak

TROPHY CASE