4 ms·

The one point about coupling in type systems is the names. While some languages (Typescript comes to mind) has structural typing, languages like Haskell tend t

by rtpg 9y ago

The one point about coupling in type systems is the names. While some languages (Typescript comes to mind) has structural typing, languages like Haskell tend to have nominal typing. So even if your data _looks like_ {'amount': 100, 'currency': 'USD'}, becuase you've wrapped it in a "Money" ADT, now its treated as a different object. Now sometimes this is valuable! There's a reason we have "newtypes" in a lot of these languages. But other times you end up having to do a lot of wrapping/unwrapping for little reason beyond the type system. There's a lot of compiler-related reasons for this stuff as well, but if you work a lot in duck-typed languages you can end up getting used to writing stuff that works across data types without any fuss.

Tehnix 9y ago
I can certainly see how that would bring frustrations, especially if you come from a dynamically-typed language (heck, even if you start out in Haskell it'll annoy you). It's worth noting though, that row polymorphism/structural typing also exist in Elm and PureScript, and there are some libraries in Haskell[0] that attempt to solve it using various approaches (admittedly not as nice as first-class support). I guess my larger problem is that he uses it as an argument static types, whereas it's a solved problem in several existing type systems that has implemented row polymorphism. [0] https://www.reddit.com/r/haskell/comments/5p307s/row_polymorphism_or_something_similar/ https://www.reddit.com/r/haskell/comments/5p307s/row_polymor...
- rtpg 9y ago
  I've worked with Purescript and agree it helps solve it, though I am willing to cut some slack to Hickley to not being super aware of row polymorphism. It's been an academic thing for a while, but only fairly recently has it been a thing in even very small languages with use like Elm. I also feel like a lot of these tools still have some difficulties. There's some conflicts where you can't declare typeclasses on pure Object records in purescript (instead having to go through a wrapper class). Still agree that forward progress is happening and interesting

by rtpg 9y ago

Tehnix 9y ago

I can certainly see how that would bring frustrations, especially if you come from a dynamically-typed language (heck, even if you start out in Haskell it'll annoy you). It's worth noting though, that row polymorphism/structural typing also exist in Elm and PureScript, and there are some libraries in Haskell[0] that attempt to solve it using various approaches (admittedly not as nice as first-class support). I guess my larger problem is that he uses it as an argument static types, whereas it's a solved problem in several existing type systems that has implemented row polymorphism. [0] https://www.reddit.com/r/haskell/comments/5p307s/row_polymorphism_or_something_similar/ https://www.reddit.com/r/haskell/comments/5p307s/row_polymor...

rtpg 9y ago
I've worked with Purescript and agree it helps solve it, though I am willing to cut some slack to Hickley to not being super aware of row polymorphism. It's been an academic thing for a while, but only fairly recently has it been a thing in even very small languages with use like Elm. I also feel like a lot of these tools still have some difficulties. There's some conflicts where you can't declare typeclasses on pure Object records in purescript (instead having to go through a wrapper class). Still agree that forward progress is happening and interesting