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 < [email protected]> 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 <[email protected]> wrote: > >> On Mon, Sep 17, 2012 at 1:02 PM, Sjoerd Visscher <[email protected]>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 >> [email protected] >> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users >> >> > > _______________________________________________ > Glasgow-haskell-users mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >
_______________________________________________ Glasgow-haskell-users mailing list [email protected] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
