To clarify my comments in this thread around desugaring: I was referring to the
concrete Haskell code as written in GHC, not at all to an abstract desugaring
algorithm. The implementation of arrows in GHC uses fixM, which is a nuisance.
And I don't understand the code well enough to be able to u
On Wed, Dec 21, 2016 at 01:49:33PM -0600, amin...@gmail.com wrote:
> Additionally, Opaleye uses Arrow syntax pretty heavily iirc.
If I were writing the Opaleye tutorial today (and if I rewrite it) I will
shy away from arrows and encourage users to use applicative style. There's
only one operator
> El 21 dic 2016, a las 02:36, Simon Peyton Jones via ghc-devs
> escribió:
>
>
>
> I even wonder (whisper it) about taking it out altogether, when Edward says
> “many of the original applications for arrows have been shown to be perfectly
> suited to being handled by Applicatives” (i.e. wi
On Wed, Dec 21, 2016 at 05:52:34PM +0100, Boespflug, Mathieu wrote:
> And Opaleye (a successor to haskellDB, for safe interaction with SQL
> databases) also uses arrow notation last I checked. As I recall do-notation
> is too powerful, whereas proc-notation provides exactly the right
> expressive p
Exploring alternative formulations is great, but I think it's (mostly?)
orthogonal to this thread's original email: Jan found the RebindableSyntax
support for Arrow to be disappointing hamstrung. I've had a similar
experience in the past; the occurrences of the combinators seem to have
overly restr
And Opaleye (a successor to haskellDB, for safe interaction with SQL
databases) also uses arrow notation last I checked. As I recall do-notation
is too powerful, whereas proc-notation provides exactly the right
expressive power (no illegal SQL queries can be expressed). But that's not
to say Tom (a
On Wed, Dec 21, 2016 at 12:15 AM, Edward Kmett wrote:
>
> 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 th
The S&D parser I was referring to was based on tracking FIRST sets, and
provided a nice linear time parsing bound for (infinite) LL(1) grammars.
(You can't really compute FOLLOW sets without knowing the grammar has a
finite number of productions, but FIRST sets work perfectly well with
infinite gra
: Help needed: Restrictions of proc-notation with RebindableSyntax
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
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
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 a
> On Dec 17, 2016, at 9:19 AM, Ross Paterson wrote:
>
> On Tue, Nov 29, 2016 at 12:41:53PM +, Simon Peyton Jones wrote:
>> 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
You’re in the driving seat! By all means give it a go.
Simon
From: Jan Bracker [mailto:jan.brac...@googlemail.com]
Sent: 02 December 2016 15:58
To: Simon Peyton Jones
Cc: Richard Eisenberg ; ghc-devs@haskell.org; Ross
Paterson (r...@soi.city.ac.uk) ; Henrik Nilsson
Subject: Re: Help needed:
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 pr
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
perha
15 matches
Mail list logo
