[Haskell-cafe] Applicative banana brackets

[Tikhon Jelvis]

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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20151209/a3471987/attachment.html>