4 ms·

I wanted to like Haskell, but just never could get to the point where I enjoyed using it. It always felt messy and complicated to me. I think the language exten

I wanted to like Haskell, but just never could get to the point where I enjoyed using it. It always felt messy and complicated to me. I think the language extensions were a contributor to these feelings. I also felt as if I spent more time wrangling with the type system than actually solving my business problems. Yet I really do like Clojure, F#, and PureScript. There's an experimental C++ back-end to PureScript now [0]. I wonder if that will ever be a viable production target? Anyway, one of the things I like about PureScript is the row-types. Does anyone know if there's a plan to get row-types into Haskell? [0] https://github.com/andyarvanitis/purescript-native https://github.com/andyarvanitis/purescript-native

dukerutledge 9y ago
There are a number of row type libraries and a proposed extension: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/Ro...
dudul 9y ago
I also really dislike this extension system where you can unlock some magical features if you could just know what magical keyword to put at the top of your file.
- nightski 9y ago
  The language was designed as a testbed for future PL research. That was the primary goal.
platz 9y ago
I am unconvinced of the practical utility of what row types give you for the added complexity. The proposal to remove the Eff type (going back to IO) from purescript is telling
- wtetzner 9y ago
  Do row types add a lot of complexity?
  - platz 9y ago
    I think they add more complexity if you have to track and spell out each effect that is being added or removed from the stack
- brandonbloom 9y ago
  It's not surprising though, since usefully typing control effects with delimited continuations would require at least answer type polymorphism, but even more usefully something like session types.
dualogy 9y ago
> There's an experimental C++ back-end to PureScript now [0]. I wonder if that will ever be a viable production target? Obligatory reminder to anyone enjoying PureScript so much they want to compile it to executable binaries for their backend work (instead of Node or such) --- I'm still hacking along on my PureScript-to-Golang trans/compiler (GH to follow in profile if interested). Unlike most alternative backends (to date) it's not a parallel fork of the purs compiler but works off the official purs compiler's `--dump`ed intermediate-representation files. Seemed more tractable to me to do it that way.

dukerutledge 9y ago

There are a number of row type libraries and a proposed extension: https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/RowTypes/Coxswain https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker/Ro...

dudul 9y ago

I also really dislike this extension system where you can unlock some magical features if you could just know what magical keyword to put at the top of your file.

nightski 9y ago
The language was designed as a testbed for future PL research. That was the primary goal.

platz 9y ago

I am unconvinced of the practical utility of what row types give you for the added complexity. The proposal to remove the Eff type (going back to IO) from purescript is telling

wtetzner 9y ago
Do row types add a lot of complexity?
- platz 9y ago
  I think they add more complexity if you have to track and spell out each effect that is being added or removed from the stack
brandonbloom 9y ago
It's not surprising though, since usefully typing control effects with delimited continuations would require at least answer type polymorphism, but even more usefully something like session types.

dualogy 9y ago

> There's an experimental C++ back-end to PureScript now [0]. I wonder if that will ever be a viable production target? Obligatory reminder to anyone enjoying PureScript so much they want to compile it to executable binaries for their backend work (instead of Node or such) --- I'm still hacking along on my PureScript-to-Golang trans/compiler (GH to follow in profile if interested). Unlike most alternative backends (to date) it's not a parallel fork of the purs compiler but works off the official purs compiler's `--dump`ed intermediate-representation files. Seemed more tractable to me to do it that way.