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 wrote:

#9200 is fixed in HEAD, which may unblock you?

Simon

From: ghc-devs [mailto:ghc-devs-bounces@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 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