<div dir="ltr">I don't know how the arrow syntax works, but you can get banana brackets for applicatives with a preprocessor<span style="color:rgb(84,84,84);line-height:16.5455px">—the Strathclyde Haskell Enhancement (SHE)[1]. You can install it from cabal and enable it with {-# OPTIONS </span><font color="#545454"><span style="line-height:16.5455px">_GHC -F -pgmF she #-} after which it just works (including, if I recall correctly, ghci).</span></font><div><font color="#545454"><span style="line-height:16.5455px"><br></span></font></div><div><font color="#545454"><span style="line-height:16.5455px">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).</span></font></div><div><font color="#545454"><span style="line-height:16.5455px"><br></span></font></div><div><font color="#545454"><span style="line-height:16.5455px">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.</span></font></div><div><font color="#545454"><span style="line-height:16.5455px"><br></span></font></div><div><font color="#545454"><span style="line-height:16.5455px">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.</span></font></div><div><font color="#545454"><span style="line-height:16.5455px"><br></span></font></div><div><font color="#545454"><span style="line-height:16.5455px">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.</span></font></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 9:09 PM, martin <span dir="ltr"><<a href="mailto:monkleyon@googlemail.com" target="_blank">monkleyon@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
while learning about all the type classes and their relationships I came<br>
across something I found weird.<br>
If I understand it correctly, banana brackets where originally developed<br>
for Applicatives. The intent was to enable us to write something like<br>
<br>
(| (\a b c -> a + b + c), [3], [1,2], [5,0,7] |)<br>
<br>
and have it translated to<br>
<br>
liftA3 (\a b c -> a + b + c) [3] [1,2] [5,0,7]<br>
<br>
or alternatively, to allow us to write something like<br>
<br>
(| (pure $ \a b c -> a + b + c), [3], [1,2], [5,0,7] |)<br>
<br>
and have it translated directly to<br>
<br>
pure (\a b c -> a + b + c) <*> [3] <*> [1,2] <*> [5,0,7]<br>
<br>
A variant of banana brackets is implemented in ghc, but only for Arrows<br>
as part of -XArrowSyntax. Arrows are just the intersection of<br>
Applicative and Category, so this implementation seems to be a<br>
specialization. What's worse, I don't think -XRebindableSyntax extends<br>
to banana brackets.<br>
But why? Is it hard to have the notation work with both? (After all, the<br>
relationship between Arrows and Applicatives is not easily expressed in<br>
Haskell.) Was the demand for (Applicative) bananas not big enough? Is it<br>
just a relic?<br>
And more to the point: I have not looked at the ghc code base at all<br>
yet, but it's on my bucket list to hack on it one day. Right now, a<br>
generalization of banana brackets seems like a simple enough low<br>
pressure first project, but I fear that it might break code or that<br>
there is some pitfall I'm not seeing.<br>
<br>
Can anybody shed a bit of light on this?<br>
<br>
Thanks and cheers,<br>
Martin L.<br>
<br>
P.S.: If the list receives this mail several times, I apologize. The<br>
list management tool seems to be confused by gmail vs. googlemail.<br>
That's what you get for using non-Haskell software. ;)<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>