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) ⟧
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
[1] https://hackage.haskell.org/package/base-4.16.1.0/docs/Contr...
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
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.
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.