The categories package itself has a number of current users who still use it on older versions of GHC, so it doesn't really unblock me there for the foreseeable future, but this will definitely help hask along.
The hask package is already tied pretty close to the bleeding edge of GHC development, as compiling it with versions of GHC prior to 7.8.3 yields illegal .hi files. -Edward Sent from my iPad > On Sep 15, 2014, at 12:06 PM, Simon Peyton Jones <simo...@microsoft.com> > wrote: > > #9200 is fixed in HEAD, which may unblock you? > > Simon > > From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Edward Kmett > Sent: 15 September 2014 14:54 > To: Sophie Taylor > Cc: ghc-devs@haskell.org > Subject: Re: Preliminary proposal: Monoidal categories in base and proc > notation support > > I'm currently working towards a new release of 'categories', which gets you > closer to your goal here, if not yet integrated into base. Said release is > currently blocked on GHC #9200, and in many ways the current work on hask is > as well. I'd frankly consider that base isn't really in a good place to > consider adopting either treatment at this point. Doing them right requires > poly kinds, constraint kinds, etc. This steps pretty far outside of the scope > of what we've been willing to bake into base to date, and it isn't clear how > to do such a design tastefully. > > One option might be to define a number of combinators in an internal module > in base with the SMC vocabulary and modify the arrow sugar to desugar in > terms of those combinators rather than general use of arr, with > RebindableSyntax turned on local definitions of the combinators would get > selected, and then rules would have something to fire against. This would > permit experimentation along these lines, without baking in assumptions about > which of the points in the design space is best. > > Sent from my iPad > > On Sep 15, 2014, at 11:32 AM, Sophie Taylor <sop...@traumapony.org> wrote: > > >Hi Sophie, > > >In your proposal draft, I am missing the rationale part. > Yeah, I'm still writing it - I definitely need to expand that a bit mor. > >Do we need *all* of these classes in base in order to desugar proc? Can > you demonstrate why they are needed? Or will something simpler suffice? > > I think I might remove the binoidal class, and remove the PFunctor/QFunctor > classes - I included them because I usually find finer grained class > hierarchies to be more tasteful; but it probably would make it more > frustrating to implement an arrow, for example. > With SMC classes, proc notation can be desugared to remove a LOT of calls to > arr, which allows more fine-grained RULES optimisations to take place, and > additional work such as the ModalTypes extension in Adam Megacz Joseph's > thesis to be much more straightforward. > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
