Preliminary proposal: Monoidal categories in base and proc notation support

Simon Peyton Jones simonpj at microsoft.com
Mon Sep 15 16:06:49 UTC 2014


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

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Edward Kmett
Sent: 15 September 2014 14:54
To: Sophie Taylor
Cc: ghc-devs at 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 <sophie at traumapony.org<mailto: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<mailto: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/226de3da/attachment.html>


More information about the ghc-devs mailing list