4 ms·

-XStrict doesn't make Haskell's module system any less of a bad joke.

Ericson2314 11y ago
Yes, yes. I wish we had https://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf https://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf too. http://plv.mpi-sws.org/backpack/ http://plv.mpi-sws.org/backpack/ and http://www.lpw25.net/ml2014.pdf http://www.lpw25.net/ml2014.pdf will bridge the gap between OCaml and Haskell from both sides, but I know of no plan for doing something about the rather embarrassing facepalms mentioned in the OP. At least most of Haskell's facepalms are in the std library, not the language (monad fail, applicative monad), which makes there after-the-fact remedy slightly less herculean.
- catnaroek 11y ago
  If I understand correctly, Backpack's design is primarily driven by compatibility considerations (“how do we build upon GHC's existing foundation?”), rather than elegance. In particular, Backpack doesn't eliminate those ugly .hs-boot files, it just automates and hides their generation and processing. For all their faults, Standard ML and OCaml have pretty good support for modular programming. And, as the Modular Type Classes paper you linked shows, type classes can be built elegantly on top of a good modular foundation.
  - Ericson2314 11y ago
    I agree that backpack leaves Haskell with too many overlapping concepts. But consider things could be unified internally, and compatibility-breaking language extensions introduced down the road. That's my hope at least :). Also, check out https://www.mpi-sws.org/~rossberg/1ml/ https://www.mpi-sws.org/~rossberg/1ml/ . I think it makes a pretty good argument that there is a similar problem going on with the MLs versus the ideal too. (The overlapping features are also not a subset of Haskell's overlapping features, interestingly too.)
    - catnaroek 11y ago
      As far as I can tell, Standard ML doesn't have much of a feature overlap problem. Off the top of my head, the only redundant feature is `abstype`, which I think is a leftover from the 70's, when ML didn't have its module system. If Standard ML had first-class modules, then modules and records could also be considered redundant. What Standard ML suffers from is lack of expressivity. The lack of (pattern) guards sometimes forces pattern matching blocks to (nest more than necessary and) contain redundant clauses. The lack of polymophic recursion forces non-uniformly recursive data types (as well as the functions that operate on them) to be rewritten in a way that makes the type checker a less effective bug-finding tool. Without higher-rank types, you can't express the Day convolution, free Applicatives, or Traversals (from the lens library). On the other hand, I don't find myself missing higher-kinded types much, since they are mostly useful in combination with type classes, which modules can adequately replace. What 1ML does is unify features: (0) records and let expressions are now particular uses of modules, (1) core language functions and type constructors are now particular uses of functors.
      - Ericson2314 11y ago
        > On the other hand, I don't find myself missing higher-kinded types much... I don't find myself missing modules that much for precisely the inverse reason. > If Standard ML had first-class modules, then modules and records could also be considered redundant. If Haskell+Backpack had first class packages/modules, then packages/modules and type classes could also be considered redundant. This is the duality I am trying to get it :). Looking each language alone, the features are "somewhat orthogonal". But in the context of the entire design space, the lack of unification comes off as redundancy.
        catnaroek 11y ago
        > I don't find myself missing modules that much for precisely the inverse reason. The “tiny” detail is that ML modules do much more than what type classes do: they allow you to define abstract types whose representation is invisible to the rest of the program, without ugly hacks like `newtype`-wrapping the internal representation. > If Haskell+Backpack had first class packages/modules Packages and modules are completely different things. A package is a unit of distribution, whereas a module is a unit of encapsulation. Even within a single program that's only distributed as a whole, you may want different components to hide their internals from each other. > This is the duality I am trying to get it There is no duality between modules and type classes, because, while modules can do everything type classes do (and more), the converse does not hold.
deleted 11y ago
[deleted]

Yes, yes. I wish we had https://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf https://www.mpi-sws.org/~dreyer/papers/mtc/main-long.pdf too. http://plv.mpi-sws.org/backpack/ http://plv.mpi-sws.org/backpack/ and http://www.lpw25.net/ml2014.pdf http://www.lpw25.net/ml2014.pdf will bridge the gap between OCaml and Haskell from both sides, but I know of no plan for doing something about the rather embarrassing facepalms mentioned in the OP. At least most of Haskell's facepalms are in the std library, not the language (monad fail, applicative monad), which makes there after-the-fact remedy slightly less herculean.

catnaroek 11y ago
If I understand correctly, Backpack's design is primarily driven by compatibility considerations (“how do we build upon GHC's existing foundation?”), rather than elegance. In particular, Backpack doesn't eliminate those ugly .hs-boot files, it just automates and hides their generation and processing. For all their faults, Standard ML and OCaml have pretty good support for modular programming. And, as the Modular Type Classes paper you linked shows, type classes can be built elegantly on top of a good modular foundation.
- Ericson2314 11y ago
  I agree that backpack leaves Haskell with too many overlapping concepts. But consider things could be unified internally, and compatibility-breaking language extensions introduced down the road. That's my hope at least :). Also, check out https://www.mpi-sws.org/~rossberg/1ml/ https://www.mpi-sws.org/~rossberg/1ml/ . I think it makes a pretty good argument that there is a similar problem going on with the MLs versus the ideal too. (The overlapping features are also not a subset of Haskell's overlapping features, interestingly too.)
  - catnaroek 11y ago
    As far as I can tell, Standard ML doesn't have much of a feature overlap problem. Off the top of my head, the only redundant feature is `abstype`, which I think is a leftover from the 70's, when ML didn't have its module system. If Standard ML had first-class modules, then modules and records could also be considered redundant. What Standard ML suffers from is lack of expressivity. The lack of (pattern) guards sometimes forces pattern matching blocks to (nest more than necessary and) contain redundant clauses. The lack of polymophic recursion forces non-uniformly recursive data types (as well as the functions that operate on them) to be rewritten in a way that makes the type checker a less effective bug-finding tool. Without higher-rank types, you can't express the Day convolution, free Applicatives, or Traversals (from the lens library). On the other hand, I don't find myself missing higher-kinded types much, since they are mostly useful in combination with type classes, which modules can adequately replace. What 1ML does is unify features: (0) records and let expressions are now particular uses of modules, (1) core language functions and type constructors are now particular uses of functors.
    - Ericson2314 11y ago
      > On the other hand, I don't find myself missing higher-kinded types much... I don't find myself missing modules that much for precisely the inverse reason. > If Standard ML had first-class modules, then modules and records could also be considered redundant. If Haskell+Backpack had first class packages/modules, then packages/modules and type classes could also be considered redundant. This is the duality I am trying to get it :). Looking each language alone, the features are "somewhat orthogonal". But in the context of the entire design space, the lack of unification comes off as redundancy.
      - catnaroek 11y ago
        > I don't find myself missing modules that much for precisely the inverse reason. The “tiny” detail is that ML modules do much more than what type classes do: they allow you to define abstract types whose representation is invisible to the rest of the program, without ugly hacks like `newtype`-wrapping the internal representation. > If Haskell+Backpack had first class packages/modules Packages and modules are completely different things. A package is a unit of distribution, whereas a module is a unit of encapsulation. Even within a single program that's only distributed as a whole, you may want different components to hide their internals from each other. > This is the duality I am trying to get it There is no duality between modules and type classes, because, while modules can do everything type classes do (and more), the converse does not hold.

deleted 11y ago

[deleted]