3 ms·

Have you tried to express what Rust has with Haskell type system? E.g., to embed Rust into Haskell? There were some attempts to do so, for example, [1] and ass

by thesz 6y ago

Have you tried to express what Rust has with Haskell type system? E.g., to embed Rust into Haskell? There were some attempts to do so, for example, [1] and associated code at [2]. [1] http://web.engr.oregonstate.edu/~walkiner/student-theses/mcgirr-18-ms-project.pdf http://web.engr.oregonstate.edu/~walkiner/student-theses/mcg... [2] https://github.com/lambda-land/OwnershipMonad https://github.com/lambda-land/OwnershipMonad I actually am slightly sad that Mozilla started Rust effort instead of embedding what they wanted/needed to do into some proof assistant or Haskell.

Ericson2314 6y ago
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).
Ar-Curunir 6y ago
Haskell has a managed runtime; Rust does not. Rust is suitable in places that Haskell is not, despite the "less advanced" type system.
- thesz 6y ago
  The code embedded in Haskell need not managed runtime. It can be used for hard realtime tasks including garbage trucks with hybrid power train [1] and, from my experience, to control FPGA-based network switches for all kinds of analytics on 160G of Ethernet traffic in 2013. [1] https://www.slideserve.com/kin/controlling-hybrid-vehicles-with-haskell https://www.slideserve.com/kin/controlling-hybrid-vehicles-w... After embedding something in Haskell you can have your hard real time code with all kinds of runtimes seamlessly integrated with other code in typical Haskell with its RTS.
steveklabnik 6y ago
I personally have not, but it's also not my area of personal expertise. A proof assistant isn't magic fairy dust, and Haskell is not suited for the kind of work Rust focuses on for a variety of other reasons.
- thesz 6y ago
  You say that Haskell is not suited for the kind of work Rust focuses on. I would like to ask you for exactly what reasons is Haskell not suited for that kind of work? I think you did not think about embedding language into Haskell. Most of, if not all, machinery in Rust can be embedded into Haskell and used from there. But I think you will not go that path. That's okay, I see that you prefer to design languages instead of writing libraries. Fair choice, I concur.
  - steveklabnik 6y ago
    > I would like to ask you for exactly what reasons is Haskell not suited for that kind of work? The most obvious one is the mandatory runtime. EDIT: those projects you cite are effectively languages on their own, you're not running Haskell on the device, you are writing a DSL in Haskell that compiles to something else entirely. That is an approach that can work, but most of the ones I know about had some limited success and then have basically died out. Atom was last released in 2015, and has had only a few commits since then. Similar projects like Ivory have also petered out, in my understanding.
    - thesz 6y ago
      The runtime is not mandatory at all. [1] http://cufp.org/archive/2008/slides/HawkinsTom.pdf http://cufp.org/archive/2008/slides/HawkinsTom.pdf I have managed to compile Haskell code into C, Java and, finally, VHDL for some hardware simulation project. All that code did not require any kind of runtime except what was needed by typical program in that language. You seem to completely throw away whole point about embedding language into Haskell. I am okay with that. Do you?
      - 6y ago

by thesz 6y ago

Ericson2314 6y ago

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).

Ar-Curunir 6y ago

Haskell has a managed runtime; Rust does not. Rust is suitable in places that Haskell is not, despite the "less advanced" type system.

thesz 6y ago
The code embedded in Haskell need not managed runtime. It can be used for hard realtime tasks including garbage trucks with hybrid power train [1] and, from my experience, to control FPGA-based network switches for all kinds of analytics on 160G of Ethernet traffic in 2013. [1] https://www.slideserve.com/kin/controlling-hybrid-vehicles-with-haskell https://www.slideserve.com/kin/controlling-hybrid-vehicles-w... After embedding something in Haskell you can have your hard real time code with all kinds of runtimes seamlessly integrated with other code in typical Haskell with its RTS.

steveklabnik 6y ago

I personally have not, but it's also not my area of personal expertise. A proof assistant isn't magic fairy dust, and Haskell is not suited for the kind of work Rust focuses on for a variety of other reasons.

thesz 6y ago
You say that Haskell is not suited for the kind of work Rust focuses on. I would like to ask you for exactly what reasons is Haskell not suited for that kind of work? I think you did not think about embedding language into Haskell. Most of, if not all, machinery in Rust can be embedded into Haskell and used from there. But I think you will not go that path. That's okay, I see that you prefer to design languages instead of writing libraries. Fair choice, I concur.
- steveklabnik 6y ago
  > I would like to ask you for exactly what reasons is Haskell not suited for that kind of work? The most obvious one is the mandatory runtime. EDIT: those projects you cite are effectively languages on their own, you're not running Haskell on the device, you are writing a DSL in Haskell that compiles to something else entirely. That is an approach that can work, but most of the ones I know about had some limited success and then have basically died out. Atom was last released in 2015, and has had only a few commits since then. Similar projects like Ivory have also petered out, in my understanding.
  - thesz 6y ago
    The runtime is not mandatory at all. [1] http://cufp.org/archive/2008/slides/HawkinsTom.pdf http://cufp.org/archive/2008/slides/HawkinsTom.pdf I have managed to compile Haskell code into C, Java and, finally, VHDL for some hardware simulation project. All that code did not require any kind of runtime except what was needed by typical program in that language. You seem to completely throw away whole point about embedding language into Haskell. I am okay with that. Do you?
    - 6y ago