Help needed: Restrictions of proc-notation with RebindableSyntax

Wed Dec 21 05:15:03 UTC 2016

Arrows haven't seen much love for a while. In part this is because many of
the original applications for arrows have been shown to be perfectly suited
to being handled by Applicatives. e.g. the Swiestra/Duponcheel parser that
sort of kickstarted everything.

There are several options for improved arrow desugaring.

Megacz's work on GArrows at first feels like it should be applicable here,
as it lets you change out the choice of pseudo-product while preserving the
general arrow feel. Unfortunately, the GArrow class isn't sufficient for
most arrow desguaring, due to the fact that the arrow desugaring inherently
involves breaking apart patterns for almost any non-trivial use and nothing
really requires the GArrow 'product' to actually even be product like.

Cale Gibbard and Ryan Trinkle on the other hand like to use a more CCC-like
basis for arrows. This stays in the spirit to the GArrow class, but you
still have the problems around pattern matching. I don't think they
actually wrote anything to deal with the actual arrow notation and just
programmed in the alternate style to get better introspection on the
operations involved. I think the key insight there is that much of the
notation can be made to work with weaker categorical structures than full
arrows, but the existing class hierarchy around arrows is very coarse.

As a minor data point both of these sorts of encodings of arrow problems
start to drag in language extensions that make the notation harder to
standardize. Currently they work with bog standard Haskell 98/2010.

If you're looking for an interesting theoretical direction to extend Arrow
notation:

An arrow is a strong monad in the category of profunctors [1].

Using the profunctors library [2] (Strong p, Category p) is equivalent in
power to Arrow p.

Exploiting that, a profunctor-based desugaring could get away with much
weaker constraints than Arrow depending on how much of proc notation you
use.

Alternately a separate class hierarchy that only required covariance in the
second argument is an option, but my vague recollection from the last time
that I looked into this is that while such a desguaring only uses
covariance in the second argument of the profunctor, you can prove that
contravariance in the first argument follows from the pile of laws. This
subject came up the last time someone thought to extend the Arrow
desguaring. You can probably find a thread on the mailing list from Ross
Paterson a few years ago.

This version has the benefit of fitting pretty close to the existing arrow
desugaring and not needing new language extensions.

On the other hand, refactoring the Arrow class in this (or any other) way
is somewhat of an invasive exercise. The profunctors package offers moral
equivalents to most of the Arrow subclasses, but no effort has been made to
match the existing Arrow hierarchy.

Given that little new code seems to be being written with Arrows in mind,
while some older code makes heavy use of it (hxt, etc.), refactoring the
arrow hierarchy is kind of a hard sell. It is by no means impossible, just
something that would require a fair bit of community wrangling and a lot of
work showing clear advantages to a new status quo at a time when its very
hard to get anybody to care about arrow notation at all.

-Edward

[1] http://www-kb.is.s.u-tokyo.ac.jp/~asada/papers/arrStrMnd.pdf
[2]
http://hackage.haskell.org/package/profunctors-5.2/docs/Data-Profunctor-Strong.html

On Fri, Dec 2, 2016 at 10:57 AM, Jan Bracker via ghc-devs <
ghc-devs at haskell.org> wrote:

> Simon, Richard,
>
> thank you for your answer! I don't have time to look into the GHC sources
> right now, but I will set aside some time after the holidays and take a
> close look at what the exact restrictions on proc-notation are and document
> them.
>
> Since you suggested a rewrite of GHC's handling of proc-syntax, are there
> any opinions on integrating generalized arrows (Joseph 2014) in the
> process? I think they would greatly improve arrows! I don't know if I have
> the time to attempt this, but if I find the time I would give it a try. Why
> wasn't this integrated while it was still actively developed?
>
> Best,
> Jan
>
> [Joseph 2014] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/
> EECS-2014-130.pdf
>
>
>
> 2016-11-29 12:41 GMT+00:00 Simon Peyton Jones <simonpj at microsoft.com>:
>
>> Jan,
>>
>>
>>
>> Type checking and desugaring for arrow syntax has received Absolutely No
>> Love for several years.  I do not understand how it works very well, and I
>> would not be at all surprised if it is broken in corner cases.
>>
>>
>>
>> It really needs someone to look at it carefully, document it better, and
>> perhaps refactor it – esp by using a different data type rather than
>> piggy-backing on HsExpr.
>>
>>
>>
>> In the light of that understanding, I think rebindable syntax will be
>> easier.
>>
>>
>>
>> I don’t know if you are up for that, but it’s a rather un-tended part of
>> GHC.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Richard
>> Eisenberg
>> *Sent:* 28 November 2016 22:30
>> *To:* Jan Bracker <jan.bracker at googlemail.com>
>> *Cc:* ghc-devs at haskell.org
>> *Subject:* Help needed: Restrictions of proc-notation with
>> RebindableSyntax
>>
>>
>>
>> Jan’s question is a good one, but I don’t know enough about procs to be
>> able to answer. I do know that the answer can be found by looking for uses
>> of `tcSyntaxOp` in the TcArrows module.... but I just can’t translate it
>> all to source Haskell, having roughly 0 understanding of this end of the
>> language.
>>
>>
>>
>> Can anyone else help Jan here?
>>
>>
>>
>> Richard
>>
>>
>>
>> On Nov 23, 2016, at 4:34 AM, Jan Bracker via ghc-devs <
>> ghc-devs at haskell.org> wrote:
>>
>>
>>
>> Hello,
>>
>>
>>
>> I want to use the proc-notation together with RebindableSyntax. So far
>> what I am trying to do is working fine, but I would like to know what the
>> exact restrictions on the supplied functions are. I am introducing
>> additional indices and constraints on the operations. The documentation [1]
>> says the details are in flux and that I should ask directly.
>>
>>
>>
>> Best,
>>
>> Jan
>>
>>
>>
>> [1] https://downloads.haskell.org/~ghc/latest/docs/html/user
>> s_guide/glasgow_exts.html#rebindable-syntax-and-the-implicit
>> -prelude-import
>> <https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23rebindable-syntax-and-the-implicit-prelude-import&data=02%7C01%7Csimonpj%40microsoft.com%7C80e472cedf78463bd18408d417de1af5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636159690104764444&sdata=ygqePSmgcPKnPmKDBfZplkyjG9BIDBO1L1MWHNpqw88%3D&reserved=0>
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20161221/4381a0ce/attachment.html>