<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Sorry to barge into the discussion with neither much knowledge of
the theory nor the implementation. I tried to look at both, but my
understanding is severely lacking. However I do feel a tiny bit
emboldened because my own findings turned out to at least have the
same shadow as the contents of this more thorough overview.<br>
</p>
The one part of the existing story I personally found the most
promising was to explore the category hierarchy around Arrows, in
other words the Gibbard/Trinkle perspective. Therefore I want to
elaborate my own naive findings a tiny bit. Bear in mind that much
of this is gleaned from experimental implementations or interpreted,
but I do not have proofs, or even theory.<br>
Almost all parts necessary for an Arrow seem to already be contained
in a symmetrical braided category. Fascinatingly, even the braiding
might be superfluous in some cases, leaving only the need for a
monoidal category. But to get from a braided category to a full
Arrow, there seems to be a need for "constructors" like (arr $ \x
-> (x,x)) and "destructors" like (arr fst). There seem to be
several options for those, and a choice would have to be made.
Notably: is introduction done by duplicating existing values, or by
introducing new "unit" values (for a suitable definition of "unit")?
That choice doesn't seem impactful, but my gut feeling is that
that's just because I cannot see the potential points of impact.<br>
<br>
What makes this story worse is that the currently known hierarchies
around ArrowChoice and ArrowLoop seem to be coarser still – although
the work around profunctors might help. That said, my understanding
is so bad that I can not even see any benefits or drawbacks of the
structure of ArrowLoop's "loop" versus a more "standard" fix-point
structure.<br>
<br>
I do, however, think there is something to be gained. The good old
Rosetta Stone paper still makes me think that what is now Arrow
notation might be turned into a much more potent tool – exactly
because we might be able to lift those restrictions. One particular
idea I have in mind: If the notation can support purely braided
categories, it might be used to describe reversible computation,
which in turn is used in describing quantum computation.<br>
<br>
The frustrating part for me is that I would like to contribute to
this effort. But again, my understanding of each and every component
is fleeting at best.<br>
<br>
MarLinn<br>
<br>
<br>
<div class="moz-cite-prefix">On 2016-12-21 06:15, Edward Kmett
wrote:<br>
</div>
<blockquote
cite="mid:CAJumaK-EdTBMNJ8eEfgr4QjjJvUVQVXz_OhF=XJ06u_uP+uF5g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
There are several options for improved arrow desugaring.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>
<div>
<div>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.</div>
<div><br>
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.<br>
<br>
</div>
</div>
<div>If you're looking for an interesting theoretical
direction to extend Arrow notation:</div>
<div><br>
</div>
<div>An arrow is a strong monad in the category of profunctors
[1]. </div>
<div><br>
</div>
<div>Using the profunctors library [2] (Strong p, Category p)
is equivalent in power to Arrow p.</div>
<div><br>
</div>
<div>Exploiting that, a profunctor-based desugaring could get
away with much weaker constraints than Arrow depending on
how much of proc notation you use.<br>
</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This version has the benefit of fitting pretty close to the
existing arrow desugaring and not needing new language
extensions.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Edward</div>
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="http://www-kb.is.s.u-tokyo.ac.jp/%7Easada/papers/arrStrMnd.pdf">http://www-kb.is.s.u-tokyo.ac.jp/~asada/papers/arrStrMnd.pdf</a><br>
</div>
<div>[2] <a moz-do-not-send="true"
href="http://hackage.haskell.org/package/profunctors-5.2/docs/Data-Profunctor-Strong.html">http://hackage.haskell.org/package/profunctors-5.2/docs/Data-Profunctor-Strong.html</a></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Dec 2, 2016 at 10:57 AM, Jan
Bracker via ghc-devs <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:ghc-devs@haskell.org"
target="_blank">ghc-devs@haskell.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Simon, Richard,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Best,</div>
<div>Jan</div>
<div><br>
</div>
<div>[Joseph 2014] <a moz-do-not-send="true"
href="https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-130.pdf"
target="_blank">https://www2.eecs.berkel<wbr>ey.edu/Pubs/TechRpts/2014/<wbr>EECS-2014-130.pdf</a><br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-11-29 12:41 GMT+00:00
Simon Peyton Jones <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:simonpj@microsoft.com"
target="_blank">simonpj@microsoft.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-GB">
<div
class="m_34741211521753758m_6725992496896091287WordSection1">
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">Jan,</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">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.</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">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.</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">In
the light of that understanding, I think
rebindable syntax will be easier.</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">I
don’t know if you are up for that, but
it’s a rather un-tended part of GHC.</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">Thanks</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif">Simon</span></p>
<p class="MsoNormal"><span
style="font-family:"Calibri",sans-serif"> </span></p>
<div style="border:none;border-left:solid blue
1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid
#e1e1e1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"
lang="EN-US">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"
lang="EN-US"> ghc-devs [mailto:<a
moz-do-not-send="true"
href="mailto:ghc-devs-bounces@haskell.org"
target="_blank">ghc-devs-bounces@haske<wbr>ll.org</a>]
<b>On Behalf Of </b>Richard
Eisenberg<br>
<b>Sent:</b> 28 November 2016 22:30<br>
<b>To:</b> Jan Bracker <<a
moz-do-not-send="true"
href="mailto:jan.bracker@googlemail.com"
target="_blank">jan.bracker@googlemail.com</a>><br>
<b>Cc:</b> <a
moz-do-not-send="true"
href="mailto:ghc-devs@haskell.org"
target="_blank">ghc-devs@haskell.org</a><br>
<b>Subject:</b> Help needed:
Restrictions of proc-notation with
RebindableSyntax</span></p>
</div>
</div>
<div>
<div class="m_34741211521753758h5">
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Can anyone else
help Jan here?</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Richard</p>
</div>
<p class="MsoNormal"> </p>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Nov 23,
2016, at 4:34 AM, Jan Bracker
via ghc-devs <<a
moz-do-not-send="true"
href="mailto:ghc-devs@haskell.org"
target="_blank">ghc-devs@haskell.org</a>>
wrote:</p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Hello,</p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Best,</p>
</div>
<div>
<p class="MsoNormal">Jan</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">[1] <a
moz-do-not-send="true"
href="https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F%7Eghc%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"
target="_blank">https://downloads.haskell.<wbr>org/~ghc/latest/docs/html/user<wbr>s_guide/glasgow_exts.html#rebi<wbr>ndable-syntax-and-the-implicit<wbr>-prelude-import</a></p>
</div>
</div>
<p class="MsoNormal">______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a moz-do-not-send="true"
href="mailto:ghc-devs@haskell.org"
target="_blank">ghc-devs@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a moz-do-not-send="true" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
<a moz-do-not-send="true"
href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"
rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-<wbr>bin/mailman/listinfo/ghc-devs</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ghc-devs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a>
</pre>
</blockquote>
<br>
</body>
</html>