Type operators in GHC
carter.schonwald at gmail.com
Tue Sep 18 05:05:28 CEST 2012
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users