3 ms·

Considering the state of "linear Haskell", and the difficulties in working on GHC (which didn't have CI at the time), I don't really blame them. I would actual

Considering the state of "linear Haskell", and the difficulties in working on GHC (which didn't have CI at the time), I don't really blame them. I would actually like GHC be a Rust compiler too. I think that would force it to be more modular, and if it's more modular and has more incremental CI, we'll get a lot of productivity and such a thing would actually be practical. So just gotta find a way to unwind the causality loop they (probably modularity for modularity's sake.)

thesz 6y ago
I keep saying that one can embed his language of choice into Haskell and get whatever one needs. Including, but not limited to, LLVM and other backends. Linear Haskell is a disgrace, glad you asked. It can be implemented as a library, as usual [1], and the process of inputting that linear logic into compiler I see as political, not technical. [1] https://jpaykin.github.io/papers/pz_linearity_monad_2017.pdf https://jpaykin.github.io/papers/pz_linearity_monad_2017.pdf Compiler (ghc) can recognize what code that monad from [1] produces and apply transformations accordingly. The bonus here? That recognition process can accidentally optimize parts of program that do not use linear monad at all but happen to have same structure and same satisfied constraints. About fifteen-twenty years ago I tried to invent a linear programming language or add that to Haskell. And it was not pretty. Linearity pops where you clearly don't want it to be, preventing clear explanation of ideas and/or requiring several types for innocent expression (there's no possibility of most general type in some variants of linear logic).