[Haskell-cafe] Applicative banana brackets

[martin]

That's... just brilliant!

I think I'll sneak back to the beginners' play room now...


On 2015-12-14 15:16, S. Doaitse Swierstra wrote:
> In the Idioms module of uu-parsinglib:
>
> https://hackage.haskell.org/package/uu-parsinglib-2.9.1/docs/Text-ParserCombinators-UU-Idioms.html
>
> I show how you can achieve what you want without any preprocessors. The idea is to overload based on the type of the operand:
>
> {-# LANGUAGE RankNTypes,
>              MultiParamTypeClasses,
>              FunctionalDependencies,
>              FlexibleInstances,
>              UndecidableInstances,
>              FlexibleContexts,
>              CPP #-}
>
> module Idiomatic where
>     
> -- | The  `Ii` is to be pronounced as @stop@
> data Ii = Ii 
>
> -- | The function `iI` is to be pronounced as @start@
> iI ::Idiomatic  (a -> a) g => g
> iI = idiomatic (pure id)
>
> class Idiomatic f g  | g -> f   where
>     idiomatic :: [f] -> g
>     
> instance  Idiomatic x  (Ii -> [x]) where
>     idiomatic ix Ii = ix
>
>
> instance  Idiomatic f g  => Idiomatic  (a -> f) ([a]  -> g) where
>     idiomatic isf is = idiomatic (isf <*> is)
>
> instance Idiomatic f g => Idiomatic ((a -> b) -> f)  ((a -> b) -> g) where
>     idiomatic isf f = idiomatic (isf <*> (pure f))
>
> t :: [Int]
> t = iI (\ a b c -> a + b +c) [3] [1,2] [5,0,7] Ii 
>
> So you get:
>
> *Idiomatic> show t
> "[9,4,11,10,5,12]"
> *Idiomatic> 
>
>
>   
>
>
>> On 14 Dec 2015, at 14:53 , martin <monkleyon at googlemail.com> wrote:
>>
>>> 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
>>>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe