[Haskell-cafe] Applicative banana brackets

[martin]

> 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]. [...]
I hadn't looked into preprocessors yet, but that sounds like a great
idea. Thanks!
> Personally, playing around with it convinced me that banana brackets aren't
> quite as nice in practice as they look. [...] Of course, those more complicated cases end up being the
> most common. [...]
I only played around with arrow brackets yet, but that sounds familiar.
They can make your code really beautiful - but only rarely. I'm
currently trying to convert some of my overcomplicated arrow structures
to simpler applicative ones, which is one of my motivations here. But if
it's of so little use, and with liftAn's already there...
> A particular problem I had is that, by necessity, $ works differently
> inside banana brackets than normally. [...]
That sounds like it might not have been a problem for me yet because the
natural composition of arrows is through (>>>) anyway. Interesting.
> I don't want to discourage you too much. 
Don't worry. There are always things to play around with and projects to
try. It was just that I thought I might have found something far simpler
that what I usually come up with, and thus something I could actually
finish and share some day. ;)
> Also, they'd be somewhat redundant with ApplicativeDo.
Yet another thing I hadn't thought of. I'm not a huge fan of do-notation
and arrow-notation myself. They are useful, but can be overly verbose
and distracting. So maybe I'll get more use out of brackets? Only one
way to find out...

Anyway, thanks for all the great information. These are definitely
things I'll consider!

>> 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
>>