Type operators in GHC

[Edward Kmett]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120917/431e7a5f/attachment.htm>