I don't know how the arrow syntax works, but you can get banana brackets for applicatives with a preprocessor—the Strathclyde Haskell Enhancement (SHE)[1]. You can install it from cabal and enable it with {-# OPTIONS _GHC -F -pgmF she #-} after which it just works (including, if I recall correctly, ghci).

Personally, playing around with it convinced me that banana brackets aren't quite as nice in practice as they look. They still make *certain* expressions nicer (especially simple ones involving operators), but either don't make a difference or actually make the code *less* readable in more complicated cases. Of course, those more complicated cases end up being the most common, so in a small project I only found something like two applicative expressions where it helped (out of at least 20).

A particular problem I had is that, by necessity, $ works differently inside banana brackets than normally. This is the only thing that makes sense, of course, but it doesn't jell well with how I intuitively use $ as more or less syntax for limiting nested parentheses.

I don't want to discourage you too much. They might work better for you than they did for me. But you should definitely play around with them, preferably on a real project, before you sink any time in trying to implement them in GHC. You might like them but don't be surprised if you don't.

Also, they'd be somewhat redundant with ApplicativeDo. The syntax is different enough that both can be useful, but it's something to keep in mind. At the very least, the ApplicativeDo extension is a good place to start looking to understand how to desugar to applicative operators in GHC.

On Tue, Dec 8, 2015 at 9:09 PM, martin <monkleyon@googlemail.com> wrote:

Hi,

while learning about all the type classes and their relationships I came
across something I found weird.
If I understand it correctly, banana brackets where originally developed
for Applicatives. The intent was to enable us to write something like

(| (\a b c -> a + b + c), [3], [1,2], [5,0,7] |)

and have it translated to

liftA3 (\a b c -> a + b + c) [3] [1,2] [5,0,7]

or alternatively, to allow us to write something like

(| (pure $ \a b c -> a + b + c), [3], [1,2], [5,0,7] |)

and have it translated directly to

pure (\a b c -> a + b + c) <*> [3] <*> [1,2] <*> [5,0,7]

A variant of banana brackets is implemented in ghc, but only for Arrows
as part of -XArrowSyntax. Arrows are just the intersection of
Applicative and Category, so this implementation seems to be a
specialization. What's worse, I don't think -XRebindableSyntax extends
to banana brackets.
But why? Is it hard to have the notation work with both? (After all, the
relationship between Arrows and Applicatives is not easily expressed in
Haskell.) Was the demand for (Applicative) bananas not big enough? Is it
just a relic?
And more to the point: I have not looked at the ghc code base at all
yet, but it's on my bucket list to hack on it one day. Right now, a
generalization of banana brackets seems like a simple enough low
pressure first project, but I fear that it might break code or that
there is some pitfall I'm not seeing.

Can anybody shed a bit of light on this?

Thanks and cheers,
Martin L.

P.S.: If the list receives this mail several times, I apologize. The
list management tool seems to be confused by gmail vs. googlemail.
That's what you get for using non-Haskell software. ;)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe