[Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions

[adam vogt]

Hi Matthew,

Looks like you can nest your version, if you add type annotations
specifying the result type of each bracket.

> runIdentity $ iI (+) f (iI (+) (Identity 1) (Identity 1) Ii :: Identity Int) Ii :: Int

Changing "i x" to ix in the instance head lets ghc pick the instance
when an Ii shows up, and then decide the result of the bracket is "i
x":

instance (Applicative i, ix ~ i x)   => Idiomatic (Ii -> ix) where
  type I (Ii -> ix) = GetI ix
  type F (Ii -> ix) = GetX ix
  idiomatic xi Ii     = xi

type family GetI xi :: * -> *
type family GetX xi :: *
type instance GetI (i x) = i
type instance GetX (i x) = x

It seems cleaner to avoid type families for this problem:
https://gist.github.com/aavogt/433969cc83548e1f59ea#file-ii-hs

Regards,
Adam

On Tue, Feb 24, 2015 at 8:44 AM, Matthew Pickering
<matthewtpickering at gmail.com> wrote:
> I've been playing around with various implementations like this.
> Interestingly, this more general version allows nested "idiom brackets"
> whilst a more specific implementation (such as the one on the haskell wiki)
> doesn't. Any ideas why?
>
> The two implementations I have been testing this with are
> https://gist.github.com/mpickering/e19f6a5590a74fc36752
>
> On Fri, Feb 20, 2015 at 7:12 PM, adam vogt <vogt.adam at gmail.com> wrote:
>>
>> On Thu, Feb 19, 2015 at 10:42 AM, Christopher Done <chrisdone at gmail.com>
>> wrote:
>> > Right, I see three use-cases:
>> >
>> > * Some things are foldable cleanly like monoids, so you can just
>> > mconcat [x,y,z] and that'll be inlined (I think).
>> > * Other things like x <|> y is not the same as asum [x,y] due to the
>> > additional mempty being introduced. You can also use foldl1 kind of
>> > functions, but they are partial and therefore not desirable.
>> > * Finally, things like <*>, $=, $, ., #/:& (e.g. in HList/vinyl) can't
>> > be folded at all, because the types are different.
>> >
>> > The third use-case doesn't have a solution that I'm aware of. So this
>> > solves that. It also solves the second use-case, which has only a
>> > partial (he he) solution. The first use-case is just a bonus. Should I
>> > add this clarification to the proposal?
>>
>> I think this is a half-solution to the third option:
>>
>> https://gist.github.com/aavogt/433969cc83548e1f59ea
>>
>> Rather than adding more syntax, maybe it's better to make polymorphic
>> functions/values easier to create. Writing instances of ApplyAB is a
>> pain, but ghc could help, as it does with this quasiquoter
>> http://lpaste.net/114788.
>>
>> Regards,
>> Adam
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>