[Haskell-cafe] Proposal: Infix expression keyword: -XInfixExpressions
vogt.adam at gmail.com
Tue Feb 24 19:36:30 UTC 2015
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
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:
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
> 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>
>> > 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:
>> 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
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe