Christopher Done
Here's a fair comparison of before/after on my ace package's parser: https://github.com/chrisdone/ace/commit/36767780ca356db75468f803b0c91388186c...
In my opinion, this is exactly why I want this extension - these changes are easier for me to parse after the changes, and would be even nicer if we could drop the 'i' (so the brackets are symmetric). Interestingly, I think some of these changes could be even nicer assuming we had ApplicativeDo as well: (|SentenceCoord_2 sentenceCoord_3 (optional (try (do string "or" sentenceCoord_2)))|) As you can see, it allows us to do away with infix operators entirely.
Cons:
* Nesting is not supported by quasi-quoters.
This is something I think is very important - I often nest applicative syntax in my own code, and it's essential to me that I would be able to nest idiom brackets too.
* Currently it lacks the Alternative support as proposed by Conor. That would look like this:
[i|TopicalizedSentenceExistential existentialTopic (optional (try sentenceCoord)) |TopicalizedSentenceUniversal universalTopic sentenceCoord |TopicalizedSentenceComposite compositeSentence|]
I'm actually somewhat against this - my personal preference is that we keep this extension very minimal. Essentially, all we're doing is overloading what whitespace means within the idiom brackets. Introducing new symbols now complicates that, and introduces yet more syntax. My current solution for dealing with sums is to use asum: asum [[i|TopicalizedSentenceExistential existentialTopic (optional (try sentenceCoord)) ,[i|TopicalizedSentenceUniversal universalTopic sentenceCoord |] ,[i|TopicalizedSentenceComposite compositeSentence|]] Though it is a little noisy, I think it gives you want you want - machine-predictable indentation and consistency.
Comparatively, I've never used arrows ever and yet GHC has built-in support for it. Meanwhile Applicatives have wide application (hehe) and we're stuck writing this clunky stuff. But I figured I'd play with the quasi-quoter and see how it feels, and see if other people get onboard with it.
Interestingly there is more interaction there. It's somewhat widely known now that Arrow <=> Applicative + Category. Thus in my current codebase using Opaleye, I actually work entirely *without* arrow notation. I find the notation alien-enough that it's not providing a huge win for my productivity, but in return I end up paying a cost in a little more typing. personBirthdayProduct = proc () -> do personRow <- personQuery -< () birthdayRow <- birthdayQuery -< () returnA -< (personRow, birthdayRow) right now becomes (,) <$> personQuery <*> birthdayQuery or liftA2 (,) personQuery birthdayQuery but with idiom brackets becomes (| (personQuery, birthdayRow) |) A slightly more complicated example is youngPeople = proc () -> do row@(_, age, _) <- personQuery -< () restrict -< age .<= 18 returnA -< row could become (| fst (second (lmap age restrict) . (| dup personQuery |)) |) where dup a = (a,a) Arguably not considerably better as you have to tuple things up only to immediately unpack them, but hopefully provides some insight how the use of ArrowNotation could be replaced with idiom brackets. - Ollie