Type operators in GHC
conal at conal.net
Wed Sep 19 18:56:45 CEST 2012
Indeed -- lovely notational tricks, Iavor & Edward! I think I'd be happy
with one of these variations. At least worth experimenting with.
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 :)
> 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:
>>> 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. ;)
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users