3 ms·

> While it looks like boilerplate, we can more or less mechanically write out the instances… Yes so why doesn’t some GHC extension do this? The issue I have w

> While it looks like boilerplate, we can more or less mechanically write out the instances… Yes so why doesn’t some GHC extension do this? The issue I have with this and Functors and Monads and Monad transformers is that there is a lot of boilerplate. I wish i could apply f x y instead of lift $ f <$> x <*> pure y. It would be awesome if there was a ghc extension which, whenever it encounters something like ‘(a -> b -> c) applied to (f a and f b, expected to return g (f c))’ it automatically adds the appropriate ‘fmap’, ‘bind’, ‘pure’, ‘lift’, ‘inj’, ‘Impure’ etc. Then combined with do-notation, you can write truly imperative-looking code, without having to manually convert ‘a’ and ‘State a’ and ‘Reader a’ and ‘Exception a’ into ‘(State :+: Reader :+: Exception) a’. IMO free monads are an implementation detail for how to enable typed effects and subtypes in a pure language. They’re still kind of important for users to understand, but they would be easier to explain if you let users write imperative-looking code first and then convert it into free monads. That would fix the question most people have when learning about category theory, “why?” - most people don’t know what to make with category theory abstractions because they don’t know what they’re for.

siraben 4y ago
> I wish i could apply f x y instead of lift $ f <$> x <*> pure y. In "Applicative Programming with Effects"[0], the authors use such a notation, and even leave it as an exercise to implement it in Haskell using MultiParamTypeClasses: > Given Haskell extended with multi-parameter type classes, enthusiasts for overloading may replace ‘⟦’ and ‘⟧’ by identifiers i[ and ]i with the right behaviour. So they have code that looks like eval :: Exp v -> Env v -> Int eval (Var x) = fetch x eval (Val i) = ⟦ i ⟧ eval (Add p q) = ⟦ (+) (eval p) (eval q) ⟧ > Yes so why doesn’t some GHC extension do this? It's possible to derive the functor instance automatically if the data type is built from products, sums and arrows. However even for Applicatives you can't do this in general because there can be many lawful Applicative instances for the same type, for instance[1] for lists. [0] http://strictlypositive.org/IdiomLite.pdf http://strictlypositive.org/IdiomLite.pdf [1] https://hackage.haskell.org/package/base-4.16.1.0/docs/Control-Applicative.html#t:ZipList https://hackage.haskell.org/package/base-4.16.1.0/docs/Contr...
- Iceland_jack 4y ago
  It is possible to derive Applicative. The next release of GHC is able to derive Applicative for product types: `deriving Applicative via Generically1 F`. If you have a sum type you can derive Applicative as well, but as you mention there are often multiple options so this requires user assistance: `deriving Applicative via Idiomatically F '[LeftBias Id]`. Here is the library that allows that: https://hackage.haskell.org/package/idiomatic https://hackage.haskell.org/package/idiomatic
whateveracct 4y ago
Doing the magic stuff you say doesn't work well due to the ambiguities that could result. Applicative style is so trivial that it's hard to say it's worth it to automate it at the cost of ambiguities. Feel free to write a GHC proposal to solve this trivial deficiency - anyone! I dare you! I'd like to see this complaint's rubber hit the road.

siraben 4y ago

> I wish i could apply f x y instead of lift $ f <$> x <*> pure y. In "Applicative Programming with Effects"[0], the authors use such a notation, and even leave it as an exercise to implement it in Haskell using MultiParamTypeClasses: > Given Haskell extended with multi-parameter type classes, enthusiasts for overloading may replace ‘⟦’ and ‘⟧’ by identifiers i[ and ]i with the right behaviour. So they have code that looks like eval :: Exp v -> Env v -> Int eval (Var x) = fetch x eval (Val i) = ⟦ i ⟧ eval (Add p q) = ⟦ (+) (eval p) (eval q) ⟧ > Yes so why doesn’t some GHC extension do this? It's possible to derive the functor instance automatically if the data type is built from products, sums and arrows. However even for Applicatives you can't do this in general because there can be many lawful Applicative instances for the same type, for instance[1] for lists. [0] http://strictlypositive.org/IdiomLite.pdf http://strictlypositive.org/IdiomLite.pdf [1] https://hackage.haskell.org/package/base-4.16.1.0/docs/Control-Applicative.html#t:ZipList https://hackage.haskell.org/package/base-4.16.1.0/docs/Contr...

Iceland_jack 4y ago
It is possible to derive Applicative. The next release of GHC is able to derive Applicative for product types: `deriving Applicative via Generically1 F`. If you have a sum type you can derive Applicative as well, but as you mention there are often multiple options so this requires user assistance: `deriving Applicative via Idiomatically F '[LeftBias Id]`. Here is the library that allows that: https://hackage.haskell.org/package/idiomatic https://hackage.haskell.org/package/idiomatic

whateveracct 4y ago

Doing the magic stuff you say doesn't work well due to the ambiguities that could result. Applicative style is so trivial that it's hard to say it's worth it to automate it at the cost of ambiguities. Feel free to write a GHC proposal to solve this trivial deficiency - anyone! I dare you! I'd like to see this complaint's rubber hit the road.