3 ms·

> ADT's don't scale. Witness haskell's half-decade of heroic effort... just to insert Applicative Huh? Firstly that has nothing to do with ADTs. Applicative'

by tome 9y ago

> ADT's don't scale. Witness haskell's half-decade of heroic effort... just to insert Applicative Huh? Firstly that has nothing to do with ADTs. Applicative's a type class. Secondly it didn't take effort it just took an agreement to do it and enough warning and checks that everyone had done the minimal rewrites required. If anything taking five years was a sign that it wasn't desperately important, just housekeeping.

mncharity 9y ago
Easy? Minimal? Ok, yes, compared to... something. C++ standards committee. But consider mathematics. You hand someone an algorithm, valid exactly on some theory/algebra/structure, with its types/equality, operators, and laws. And that's it - that's everything. It doesn't matter what they're named, or in what order they were gathered, or where that structure happens to appear in the lattice of some prelude or another. There's no context, no cruft. If you want a language with the expressive power of mathematics, it needs to support the expressive power of mathematics. > it didn't take effort [...] housekeeping This description is not consistent with my limited observation of discussions among some involved.
- tome 9y ago
  > You hand someone an algorithm, valid exactly on some theory/algebra/structure, with its types/equality, operators, and laws. And that's it - that's everything. It doesn't matter what they're named, or in what order they were gathered, or where that structure happens to appear in the lattice of some prelude or another This is also the case for algorithms in Haskell when the Applicative Monad Proposal was enacted. All existing implementations stayed unchanged. The benefit of the AMP was that some implementations could drop an Applicative constraint if they wanted. > > it didn't take effort [...] housekeeping > > This description is not consistent with my limited observation of discussions among some involved. Then I suggest you ask for further clarification. There was a lot of discussion and debate to make sure we got a smooth transition. Basically no one opposed the proposal. The changes to code were absolutely minimal.

by tome 9y ago

mncharity 9y ago

Easy? Minimal? Ok, yes, compared to... something. C++ standards committee. But consider mathematics. You hand someone an algorithm, valid exactly on some theory/algebra/structure, with its types/equality, operators, and laws. And that's it - that's everything. It doesn't matter what they're named, or in what order they were gathered, or where that structure happens to appear in the lattice of some prelude or another. There's no context, no cruft. If you want a language with the expressive power of mathematics, it needs to support the expressive power of mathematics. > it didn't take effort [...] housekeeping This description is not consistent with my limited observation of discussions among some involved.

tome 9y ago
> You hand someone an algorithm, valid exactly on some theory/algebra/structure, with its types/equality, operators, and laws. And that's it - that's everything. It doesn't matter what they're named, or in what order they were gathered, or where that structure happens to appear in the lattice of some prelude or another This is also the case for algorithms in Haskell when the Applicative Monad Proposal was enacted. All existing implementations stayed unchanged. The benefit of the AMP was that some implementations could drop an Applicative constraint if they wanted. > > it didn't take effort [...] housekeeping > > This description is not consistent with my limited observation of discussions among some involved. Then I suggest you ask for further clarification. There was a lot of discussion and debate to make sure we got a smooth transition. Basically no one opposed the proposal. The changes to code were absolutely minimal.