Preliminary proposal: Monoidal categories in base and proc notation support

[Edward Kmett]

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 <sophie at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140915/5ea83896/attachment.html>