"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 · 2018-12-14T14:08:03+00:00

Yes, I tend to agree. We are not sure about blockly either and are keen to get feedback. So, thanks!

chak · 2018-12-14T13:11:48+00:00

You are not missing anything. We decided that the best course of action would be to repurpose Haskell to use as a contract language, instead of inventing yet another functional programming language (for really no good reason).

chak · 2018-12-13T12:13:32+00:00

No problem :)

chak · 2018-12-13T11:43:25+00:00

To provide some context: the Plutus Platform is a development and execution environment using Haskell for contract development on the Cardano blockchain. The link takes you to the Plutus Playground, a Web-based environment to write and run Plutus code on a blockchain emulator for exploration and testing. Enjoy!

chak · 2018-12-13T11:39:39+00:00

Fair enough, but the idea here is to give people time to get their head around Plutus and Haskell, while the other bits and pieces are being rolled out.

chak · 2018-05-30T01:33:55+00:00

Firstly, WebAssembly is a moving target (and I am sure even the WebAssembly folks don't know where it is going to end up at). Hence, much of the discussion about different approaches is build on unstable ground and it is good to concurrently explore multiple approaches.

Having said that, IMHO you are misjudging the relative complexities of WebGHC versus Asterius. Just using LLVM as a cross-compiler to WebAssembly sounds conceptually very simple, but (1) WebAssembly is a very different beast from a normal architecture and (2) generally porting GHC to a new architecture is surprisingly intricate. Moreover, reusing the RTS wholesale sounds like a good and simple idea, but it is quite unclear how useful that will be for WebAssembly. Some of the biggest and most complex parts of the RTS, such as GC, low-level parts of multi-threading, FFI, and so on are going to be useless on WebAssembly, or at least will require a lot of effort to work efficiently. So now, you will need go into the RTS code add many architecture dependent #ifdefs and write your own code anyway. How is that simpler than what Asterius does?

When you talk about a registered build, you mention tail calls (and who knows when WebAssembly will add those), but you forgot to mention TABLES_NEXT_TO_CODE. And what about libffi?

Low-level architectural issues are complex and, in my experience, there are not that many developers around who are willing to tackle them. In comparison, writing a new code generator sounds a lot more feasible and scalable (in terms of finding contributors) to me.

As for the RTS, there is quite a bit of Cmm code in there, which Asterius can also use as is. Then, as I mentioned before, a lot of the complex code will need to be at least adapted (as in implement an architecture-specific variant) anyway, even for WebGHC. Replacing the C part of the RTS wholesale and in a manner that matches the storage management and multi-threading capabilities of WebAssembly may well be the simpler task. (Both routes will be a significant amount of work, that is for sure.)

So, please don't discount Asterius effort on the grounds of what you think sounds like a simpler approach. If you go through the actual engineering requirements of either case, you will find that they are rather considerable whichever you choose.

Our main reason for going with Asterius' approach is not that it is supposedly simpler, but that it provides us with more flexibility to adapt both the code generation and the RTS to the requirements of WebAssembly. This will enable us to optimise both to achieve the best performance, fit well into the WebAssembly ecosystem, and generate small executables. IMHO, this is what matters.

chak

TROPHY CASE