Type operators in GHC

[Conal Elliott]

Indeed -- lovely notational tricks, Iavor & Edward! I think I'd be happy
with one of these variations. At least worth experimenting with.

-- Conal

On Mon, Sep 17, 2012 at 8:05 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 1) kudos to iavor and edward on the slick notation invention!
>
> 2)   the key point is that ghc 7.6 does not have support for infix type
>  variable notation, and how to encode infix arrow notations nicely subject
> that design choice, right?
>
> i'm likely just being a tad redundant in this conversation, but it never
> hurts to sanity check :)
>
> cheers
> -Carter
>
> On Mon, Sep 17, 2012 at 6:40 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> On Mon, Sep 17, 2012 at 1:02 PM, Sjoerd Visscher <sjoerd at w3future.com>wrote:
>>
>>> Hi,
>>>
>>> Note that nobody was suggesting two pragmas with incompatible behaviors,
>>> only to have just one symbol reserved to still be able to have type
>>> operator variables.
>>>
>>
>> An issue with reserving a symbol for type operator variables is it
>> doesn't help you today.
>>
>> 7.6.1 is already released.
>>
>> This means that any change in behavior would have to be in 7.6.2 at the
>> earliest. Assuming the bikeshedding could complete and Simon et al.
>> frantically patched the code tomorrow, rushing to release a 7.6.2 before
>> the platform release.
>>
>> Failing that, you'd have a whole release cycle to wait through, probably
>> a platform, before you could go back to your old behavior, and then your
>> code would have some strange gap of GHC version numbers over which it
>> didn't work.
>>
>> Everyone would have to pretend 7.6.1 never happened, or  and break
>> anyone's code that was already written for 7.6, so instead of one breaking
>> change, we'd now have two.
>>
>> For instance, I'm already using ~> in 'github.com/ekmett/indexed.git'
>> for natural transformations and I am loving it, and would be sad to lose it
>> to the choice of ~ as a herald, similarly it would make the >~c~> trick
>> more verbose, and ~ is particularly terrible for operators like ~+~.
>>
>> Other herald choices lead to different issues, '.' is slightly better for
>> the other operators, but makes kind of ugly arrows, plus some day i'd
>> _really_ like to be able to use . as a type constructor for functor
>> composition! It is currently reserved at the type level as an almost
>> accidental consequence of the way forall gets parsed today.
>>
>> I really like Iavor's entirely-in-language way of addressing the issue,
>> due in part to it providing even better associativity than the existing
>> approach, and honestly, even if GHC HQ was somehow convinced to set aside
>> an ad hoc herald for type variables, I'd probably start using it in my
>> code. (probably sandwiching between something like :- and :> for old GHC
>> compatibility). I really like that I can just call the Category c, and just
>> get >~c~>  or something similar as its arrows. This feels more notationally
>> accurate to me.
>>
>> It also has two major benefits compared to any proposal for adding
>> different heralds:
>>
>> 1.) It is compatible with old code, code written with 7.6.1 and I suppose
>> future code, since (:) is such a remarkably awkward choice of herald for
>> the reasons already documented that it seems an unlikely choice.
>>
>> 2.) I can program with it today.
>>
>> I just realized if you don't want to worry about collisions with the type
>> naturals from GHC.TypeLits, and didn't care about pre-7.6 compatibility,
>> you could strip the notation down all the way to
>>
>> cmap :: CFunctor f c d => (x -c> y) -> f x -d> f y
>>
>> This is even shorter than the conventional
>>
>> cmap :: CFunctor f (~>) (~~>) => (x ~> y) -> f x ~~> f y
>>
>> Which turns the "but it is longer" argument against it on its head. ;)
>>
>> -Edward
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>>
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120919/5e0572fb/attachment.htm>