From cgibbard at gmail.com  Tue Apr  2 14:09:01 2019
From: cgibbard at gmail.com (Cale Gibbard)
Date: Tue, 2 Apr 2019 10:09:01 -0400
Subject: LAST CALL to comment on the Applicative/Monad Proposal
In-Reply-To: <q7qoa5$4lq5$1@blaine.gmane.org>
References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net>
 <e7846c5a-1de9-b344-bfe0-ead990d86d6a@stilo.com>
 <q7qoa5$4lq5$1@blaine.gmane.org>
Message-ID: <CAF3RzK8vse=ky-SGrnmVNHKXXBPbrW0iv7cqL88_nR5SS28mEg@mail.gmail.com>

Somehow every time I see messages from this list I'm again tempted to
suggest that it would all be so much easier if the goal were to document
the language as it exists in a fixed, already-released version of GHC. But
I'm not a member either. If I were, I'd pick a version and veto anything
which wasn't in that GHC. You could even pick a really old version of GHC
for this purpose and come out with a document that's far more relevant to
Haskell users of today than the Haskell 2010 Report. Just getting the
Report up to the point where it actually describes most of the stuff in GHC
6 would be fantastic progress, tbh.

Also I'd strongly consider just dropping the specification of the Prelude
altogether. I'm not sure it's even all that helpful to include it at this
point, given that whatever version someone is using is always going to have
Haddock documentation. It's both a point of contention, and of limited
usefulness to document.

On Sun, Mar 31, 2019, 12:02 Bardur Arantsson, <spam at scientician.net> wrote:

> On 16/01/2019 21.00, Mario Blažević wrote:
> >
> > In all fairness, Herbert did state [1] he intends to write up the
> > combination of AMP, MFP, and MNRP the way he likes it.
>
> Did anything come of this?
>
> Regards,
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190402/914fbf54/attachment.html>

From hvriedel at gmail.com  Tue Apr  2 15:15:34 2019
From: hvriedel at gmail.com (Herbert Valerio Riedel)
Date: Tue, 02 Apr 2019 17:15:34 +0200
Subject: LAST CALL to comment on the Applicative/Monad Proposal
In-Reply-To: <q7qoa5$4lq5$1@blaine.gmane.org> (Bardur Arantsson's message of
 "Sun, 31 Mar 2019 18:02:13 +0200")
References: <9a74525a-e44a-bc0a-6475-9d56dec13005@ciktel.net>
 <e7846c5a-1de9-b344-bfe0-ead990d86d6a@stilo.com>
 <q7qoa5$4lq5$1@blaine.gmane.org>
Message-ID: <87pnq4cuax.fsf@gmail.com>

On 2019-03-31 at 18:02:13 +0200, Bardur Arantsson wrote:
>> In all fairness, Herbert did state [1] he intends to write up the
>> combination of AMP, MFP, and MNRP the way he likes it.
>
> Did anything come of this?

Actually yes! I started prototyping how the library-report modules could
like like in H2020 as an actual working prototype (needs at least GHC
8.6, as only GHC 8.6 has the MonadFail desugaring properly setup to make
this work seamlessly w/o the need for consumers to enable {-# LANGUAGE
RebindableSyntax #-}):

 http://hackage.haskell.org/package/haskell2020

as this is the easiest way to empirically evaluate whether the
big picture makes any sense;

This is a real package with proper versioning that can be depended upon
by other packages on Hackage; breaking changes will be signalled via
major version bumps). This package can be used just like the old
`haskell2010` was used, i.e. in your `.cabal` file you simply state

  build-depends: haskell2020 == 0.1.*

and do *not* declare a dependency on the `base` package.

Unfortunately I got distracted and haven't yet finished the delta to the
library report for AMP+MRP. I hope to get back to it soon to tie this
up.

Best,
Herbert

From solly.ucko at gmail.com  Sun Apr  7 02:36:59 2019
From: solly.ucko at gmail.com (Solomon Ucko)
Date: Sat, 6 Apr 2019 22:36:59 -0400
Subject: Unabbreviation of Haskell's grammar tokens for readability
Message-ID: <CANtMP6pQGeq8U0k0Bhahvrx4NcJdgQaJJco6EDty7GY1baox=A@mail.gmail.com>

In the Haskell 1998 & 2010 reports, I found the names of the tokens for
Haskell's lexical structure / syntax / grammar very hard to read, as they
were highly abbreviated. I might get more familiar with them, but that
doesn't help newcomers, like me now. Anyone mind if I change them to use
full words? Mind if I separate the words with underscores? I made a few
changes with simple find & replace, and it made it so much more readable.
It did make the lines longer (duh!), but I see no reason for that to be
much of a problem. Or would horizontal scroll and/or line-wrapping be too
much of an issue? Where would the changes go, anyways?

Another thing that would be useful but could be harder to implement would
be links from usages to declarations of tokens.

Thanks,
Solomon Ucko

P.S. Please let me know if this has come up before, as I have just joined
this list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190406/23e8e8b9/attachment.html>

From mblazevic at stilo.com  Mon Apr  8 16:41:22 2019
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Mon, 8 Apr 2019 12:41:22 -0400
Subject: Unabbreviation of Haskell's grammar tokens for readability
In-Reply-To: <CANtMP6pQGeq8U0k0Bhahvrx4NcJdgQaJJco6EDty7GY1baox=A@mail.gmail.com>
References: <CANtMP6pQGeq8U0k0Bhahvrx4NcJdgQaJJco6EDty7GY1baox=A@mail.gmail.com>
Message-ID: <02c32a37-3f71-f973-faa8-39381bff3b74@stilo.com>

On 2019-04-06 10:36 p.m., Solomon Ucko wrote:
> In the Haskell 1998 & 2010 reports, I found the names of the tokens for 
> Haskell's lexical structure / syntax / grammar very hard to read, as 
> they were highly abbreviated. I might get more familiar with them, but 
> that doesn't help newcomers, like me now. Anyone mind if I change them 
> to use full words? Mind if I separate the words with underscores? I made 
> a few changes with simple find & replace, and it made it so much more 
> readable. It did make the lines longer (duh!), but I see no reason for 
> that to be much of a problem. Or would horizontal scroll and/or 
> line-wrapping be too much of an issue? Where would the changes go, anyways?

	If the idea is to submit the changes for the next version of the 
Haskell report, they would eventually have to be submitted as a GitHub 
pull request against https://github.com/haskell/rfcs - the key word 
being eventually. You should first create a proposal with the 
explanation of the changes you want and have it accepted.


> Another thing that would be useful but could be harder to implement 
> would be links from usages to declarations of tokens.
> 
> Thanks,
> Solomon Ucko
> 
> P.S. Please let me know if this has come up before, as I have just 
> joined this list.
> 

From solly.ucko at gmail.com  Mon Apr  8 19:14:29 2019
From: solly.ucko at gmail.com (Solomon Ucko)
Date: Mon, 8 Apr 2019 15:14:29 -0400
Subject: Unabbreviation of Haskell's grammar tokens for readability
In-Reply-To: <02c32a37-3f71-f973-faa8-39381bff3b74@stilo.com>
References: <CANtMP6pQGeq8U0k0Bhahvrx4NcJdgQaJJco6EDty7GY1baox=A@mail.gmail.com>
 <02c32a37-3f71-f973-faa8-39381bff3b74@stilo.com>
Message-ID: <CANtMP6r_dLDiL-wbBERTxaNrqxKci8OEMbpC5E280_2mq_pLUg@mail.gmail.com>

Thanks for pointing me to the repo. I'll work on the proposal when I get a
chance, but it sounds like it'll probably take a while anyways.

Thanks,
Solomon Ucko

On Mon, Apr 8, 2019, 12:41 Mario Blažević <mblazevic at stilo.com> wrote:

> On 2019-04-06 10:36 p.m., Solomon Ucko wrote:
> > In the Haskell 1998 & 2010 reports, I found the names of the tokens for
> > Haskell's lexical structure / syntax / grammar very hard to read, as
> > they were highly abbreviated. I might get more familiar with them, but
> > that doesn't help newcomers, like me now. Anyone mind if I change them
> > to use full words? Mind if I separate the words with underscores? I made
> > a few changes with simple find & replace, and it made it so much more
> > readable. It did make the lines longer (duh!), but I see no reason for
> > that to be much of a problem. Or would horizontal scroll and/or
> > line-wrapping be too much of an issue? Where would the changes go,
> anyways?
>
>         If the idea is to submit the changes for the next version of the
> Haskell report, they would eventually have to be submitted as a GitHub
> pull request against https://github.com/haskell/rfcs - the key word
> being eventually. You should first create a proposal with the
> explanation of the changes you want and have it accepted.
>
>
> > Another thing that would be useful but could be harder to implement
> > would be links from usages to declarations of tokens.
> >
> > Thanks,
> > Solomon Ucko
> >
> > P.S. Please let me know if this has come up before, as I have just
> > joined this list.
> >
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190408/0768ec01/attachment.html>

From solly.ucko at gmail.com  Tue Apr  9 01:41:02 2019
From: solly.ucko at gmail.com (Solomon Ucko)
Date: Mon, 8 Apr 2019 21:41:02 -0400
Subject: Unabbreviation of Haskell's grammar tokens for readability
In-Reply-To: <CANtMP6r_dLDiL-wbBERTxaNrqxKci8OEMbpC5E280_2mq_pLUg@mail.gmail.com>
References: <CANtMP6pQGeq8U0k0Bhahvrx4NcJdgQaJJco6EDty7GY1baox=A@mail.gmail.com>
 <02c32a37-3f71-f973-faa8-39381bff3b74@stilo.com>
 <CANtMP6r_dLDiL-wbBERTxaNrqxKci8OEMbpC5E280_2mq_pLUg@mail.gmail.com>
Message-ID: <CANtMP6rCJKRABzq7+-0g1Nfv==tepZBSNztDe4o4_iwguXtAaw@mail.gmail.com>

I have now submitted a pull request with a RFC:
https://github.com/haskell/rfcs/pull/25.

Solomon Ucko

On Mon, Apr 8, 2019 at 3:14 PM Solomon Ucko <solly.ucko at gmail.com> wrote:

> Thanks for pointing me to the repo. I'll work on the proposal when I get a
> chance, but it sounds like it'll probably take a while anyways.
>
> Thanks,
> Solomon Ucko
>
> On Mon, Apr 8, 2019, 12:41 Mario Blažević <mblazevic at stilo.com> wrote:
>
>> On 2019-04-06 10:36 p.m., Solomon Ucko wrote:
>> > In the Haskell 1998 & 2010 reports, I found the names of the tokens for
>> > Haskell's lexical structure / syntax / grammar very hard to read, as
>> > they were highly abbreviated. I might get more familiar with them, but
>> > that doesn't help newcomers, like me now. Anyone mind if I change them
>> > to use full words? Mind if I separate the words with underscores? I
>> made
>> > a few changes with simple find & replace, and it made it so much more
>> > readable. It did make the lines longer (duh!), but I see no reason for
>> > that to be much of a problem. Or would horizontal scroll and/or
>> > line-wrapping be too much of an issue? Where would the changes go,
>> anyways?
>>
>>         If the idea is to submit the changes for the next version of the
>> Haskell report, they would eventually have to be submitted as a GitHub
>> pull request against https://github.com/haskell/rfcs - the key word
>> being eventually. You should first create a proposal with the
>> explanation of the changes you want and have it accepted.
>>
>>
>> > Another thing that would be useful but could be harder to implement
>> > would be links from usages to declarations of tokens.
>> >
>> > Thanks,
>> > Solomon Ucko
>> >
>> > P.S. Please let me know if this has come up before, as I have just
>> > joined this list.
>> >
>> _______________________________________________
>> Haskell-prime mailing list
>> Haskell-prime at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190408/e770b21a/attachment.html>

From solly.ucko at gmail.com  Tue Apr  9 10:40:20 2019
From: solly.ucko at gmail.com (Solomon Ucko)
Date: Tue, 9 Apr 2019 06:40:20 -0400
Subject: Unabbreviation of Haskell's grammar tokens for readability
In-Reply-To: <2FA77F42-B32E-43E2-8FB3-D6C4E19BF3D8@gmail.com>
References: <CANtMP6pQGeq8U0k0Bhahvrx4NcJdgQaJJco6EDty7GY1baox=A@mail.gmail.com>
 <2FA77F42-B32E-43E2-8FB3-D6C4E19BF3D8@gmail.com>
Message-ID: <CANtMP6o=Sp7af3nwANZcvfqR_rk=qYe3a_rig6Y4FE5OcKSHtw@mail.gmail.com>

The HTML version might do either with the tables, though. It might also
change.

Also, wouldn't the PR page be a better place to discuss these issues?

On Tue, Apr 9, 2019, 03:02 Antonio Nikishaev <anton.nik at gmail.com> wrote:

>
> > On 7 Apr 2019, at 6:36, Solomon Ucko <solly.ucko at gmail.com> wrote:
> >
> > In the Haskell 1998 & 2010 reports, I found the names of the tokens for
> Haskell's lexical structure / syntax / grammar very hard to read, as they
> were highly abbreviated. I might get more familiar with them, but that
> doesn't help newcomers, like me now. Anyone mind if I change them to use
> full words? Mind if I separate the words with underscores? I made a few
> changes with simple find & replace, and it made it so much more readable.
> It did make the lines longer (duh!), but I see no reason for that to be
> much of a problem. Or would horizontal scroll and/or line-wrapping be too
> much of an issue? Where would the changes go, anyways?
>
> There is no scrolling in PDF.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190409/ec073714/attachment.html>

From gershomb at gmail.com  Fri Apr 19 04:40:28 2019
From: gershomb at gmail.com (Gershom B)
Date: Thu, 18 Apr 2019 21:40:28 -0700
Subject: cert on prime expired?
In-Reply-To: <87o952vgkc.fsf@smart-cactus.org>
References: <CAM8RHpFer05=-vg8G2U4RWPtiqA+Mdt+ssCgpca6QpSceZ8aRw@mail.gmail.com>
 <87o952vgkc.fsf@smart-cactus.org>
Message-ID: <CAM8RHpEcLMj7otC3FQMZ-+dKJHYuSYXX-+qNthRVY2bAKGpFAA@mail.gmail.com>

I don’t really have a stake in what happens to it. In my opinion at the
very least the domain should point somewhere where there’s a redirect in
place to the old content, or some pointer to it, so links don’t die :-)

Cheers,
Gershom


On April 18, 2019 at 11:07:22 PM, Ben Gamari (ben at well-typed.com) wrote:

Gershom B <gershomb at gmail.com> writes:

> geekosaur> looks like the cert on prime.haskell.org expired 6 days ago
>
> Ben, I think this is your dept?
>
I wrote to the Prime committee about their plans for this server but
never heard back. In light of this and the lack of traffic on it I was
operating on the assumption was that there was no need to keep this
server around beyond a static backup. If this isn't the case then we need
to work out who is going to be responsible for it since GHC won't be
administering a Trac instance once git.haskell.org is decommissioned.

I'd be happy to help move the instance to GitLab if that is helpful.

Cheers,

- Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190418/63650316/attachment.html>

From blamario at ciktel.net  Fri Apr 19 12:46:32 2019
From: blamario at ciktel.net (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Fri, 19 Apr 2019 08:46:32 -0400
Subject: cert on prime expired?
In-Reply-To: <CAM8RHpEcLMj7otC3FQMZ-+dKJHYuSYXX-+qNthRVY2bAKGpFAA@mail.gmail.com>
References: <CAM8RHpFer05=-vg8G2U4RWPtiqA+Mdt+ssCgpca6QpSceZ8aRw@mail.gmail.com>
 <87o952vgkc.fsf@smart-cactus.org>
 <CAM8RHpEcLMj7otC3FQMZ-+dKJHYuSYXX-+qNthRVY2bAKGpFAA@mail.gmail.com>
Message-ID: <47650fac-181f-8205-eb28-fde1fa9a301d@ciktel.net>

On 2019-04-19 12:40 a.m., Gershom B wrote:
> I don’t really have a stake in what happens to it. In my opinion at 
> the very least the domain should point somewhere where there’s a 
> redirect in place to the old content, or some pointer to it, so links 
> don’t die :-)


I, for one, was looking up the old proposals stored on prime.haskell.org 
<http://prime.haskell.org> when writing up the new ones. We shouldn't 
lose that content.


>
> Cheers,
> Gershom
>
>
> On April 18, 2019 at 11:07:22 PM, Ben Gamari (ben at well-typed.com 
> <mailto:ben at well-typed.com>) wrote:
>
>> Gershom B <gershomb at gmail.com <mailto:gershomb at gmail.com>> writes:
>>
>> > geekosaur> looks like the cert on prime.haskell.org 
>> <http://prime.haskell.org> expired 6 days ago
>> >
>> > Ben, I think this is your dept?
>> >
>> I wrote to the Prime committee about their plans for this server but
>> never heard back. In light of this and the lack of traffic on it I was
>> operating on the assumption was that there was no need to keep this
>> server around beyond a static backup. If this isn't the case then we 
>> need
>> to work out who is going to be responsible for it since GHC won't be
>> administering a Trac instance once git.haskell.org 
>> <http://git.haskell.org> is decommissioned.
>>
>> I'd be happy to help move the instance to GitLab if that is helpful.
>>
>> Cheers,
>>
>> - Ben
>
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



From gettaplacetogo at gmail.com  Mon Apr 29 07:54:13 2019
From: gettaplacetogo at gmail.com (=?UTF-8?B?5L2Q6Jek546E5Z+6?=)
Date: Mon, 29 Apr 2019 16:54:13 +0900
Subject: Proposal: Fix a "bug" in the layout interpretation algorithm in
 Section 10.3 of Report 2010
Message-ID: <CAAXfdvL=57epCdzoruX6wg+wv3e+XuwQpOQ6JOnVxCC0zJLbXg@mail.gmail.com>

Hello,

I found that the layout interpretation algorithm in Section 10.3 of Report
2010
produces parse-error when applied to the following code snippet:

[Snippet 1 : The code that fails to be parsed by Report]
main = print t where { t = s where s = 1 :: Int }
[/Snippet 1]

GHC 8.4.4 and GHC 8.6.4 accept this code, which is a good behavior in my
opinion.
If we regard the behavior of those current GHCs as correct,
this "bug" in the Report lies in the following lines in the definition of
the function L:

[Snippet 2 : A part of the layout interpretation algorithm in the Report]
L (} : ts) (0 : ms) = } : L ts ms (Note 3)
L (} : ts) ms = parse-error (Note 3)
[/Snippet 2]

I suggest this be modified to what follows:

[Snippet 3 : A Suggested modification to Snippet 2]
L (} : ts) (m : ms)
  | m == 0 = } : L ts ms
  | m > 0 = } : L (} : ts) ms
L (} : ts) [] = parse-error
[/Snippet 3]



Let me explain in detail.
First of all, how is Snippet 1 refused by the Report 2010 algorithm?
Let us emulate it by hand. Firstly pre-process Snippet 1:

[Snippet 4 : Pre-processed Snippet 1]
{1} main = print t where { t = s where {36} s = 1 :: Int }
[/Snippet 4]

I assumed that Snippet 1 is the only line in a file.
We may compute:

[Computation 5 : Apply L to Snippet 4]
L <Snippet 4> []
 = "{ main = print t where { t = s where { s = 1 :: Int"
       ++ L "}" [36,0,1]
[/Computation 5]

Wait here. What does L do next?
Looking from top to bottom, we hit the second line in Snippet 2,
which leads us to parse-error.
Now you might expect that the line

[Snippet 6 : Another part of the Report algorithm]
L (t : ts) (m : ms) = } : (L (t : ts) ms)   if m /= 0 and parse-error(t)
(Note 5)
[/Snippet 6]

would help, but unfortunately it doesn't work.
Even if we put aside the fact that Snippet 6 is lower in the text than
Snippet 2
and has lower priority of execution according to the usual Haskell matching
rule,
this line in L won't be triggered by this parse error at all,
since *parse-error('}') is false!*
Let us go back to the definition of parse-error(t).

[Quotation 7 : Note 5 in the Report algorithm]
The side condition parse-error(t) is to be interpreted as follows:
if the tokens generated so far by L together with the next token t
represent an invalid prefix of the Haskell grammar,
and the tokens generated so far by L followed by the token "}"
represent a valid prefix of the Haskell grammar, then parse-error(t) is
true.
[/Quotation 7]

Now, this is the point.
In this case, "the tokens generated so far by L together with the next
token t" is:

[Snippet 8]
{ main = print t where { t = s where { s = 1 :: Int }
[/Snippet 8]

This is a *valid prefix of the Haskell grammar*, and hence parse-error('}')
is false.



Therefore, any Haskell2010-compliant compiler should reject Snippet 1,
and this doesn't seem to be any sensible choice of specification.
Speaking generally, I guess the Report 2010's authors wanted
the case where a inner implicit brace and a outer explicit brace is closed
at the same time
to be processed by the rule in Snippet 6,
but it doesn't work since Snippet 2 is before Snippet 6 in the definition
of L
and parse-error(t) is always false if t = '}'.

The fix of this problem is easy: replace Snippet 2 with Snippet 3.
The added case of m > 0 is doing almost the same thing as Snippet 6, but
parse-error(t) is removed.
If we distinguish implicit close-braces and explicit close-braces,
the condition m > 0 fully does the job of parse-error('}'),
so I expect there will be no problem with this modification.



I apologize you if this long text has exhausted your eyes.
I hope this suggestion would help.

Sincerely yours,
Genki SATO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20190429/cf9e7165/attachment.html>

From mblazevic at stilo.com  Mon Apr 29 17:55:33 2019
From: mblazevic at stilo.com (=?UTF-8?Q?Mario_Bla=c5=beevi=c4=87?=)
Date: Mon, 29 Apr 2019 13:55:33 -0400
Subject: Proposal: Fix a "bug" in the layout interpretation algorithm in
 Section 10.3 of Report 2010
In-Reply-To: <CAAXfdvL=57epCdzoruX6wg+wv3e+XuwQpOQ6JOnVxCC0zJLbXg@mail.gmail.com>
References: <CAAXfdvL=57epCdzoruX6wg+wv3e+XuwQpOQ6JOnVxCC0zJLbXg@mail.gmail.com>
Message-ID: <ae3132f7-00af-35a4-b226-0b0268eec1d1@stilo.com>

On 2019-04-29 3:54 a.m., 佐藤玄基 wrote:
> Hello,
> 
> I found that the layout interpretation algorithm in Section 10.3 of 
> Report 2010
> produces parse-error when applied to the following code snippet:
> 
> [Snippet 1 : The code that fails to be parsed by Report]
> main = print t where { t = s where s = 1 :: Int }
> [/Snippet 1]
> 
> GHC 8.4.4 and GHC 8.6.4 accept this code, which is a good behavior in my 
> opinion.

	It's worth noting that the snippet is accepted by GHC even with 
-XAlternativeLayoutRule. Overall, I think I'd rather just have the 
concrete AlternativeLayoutRule algorithm in the specification than tweak 
the current broken and vague pseudo-code.


> If we regard the behavior of those current GHCs as correct,
> this "bug" in the Report lies in the following lines in the definition 
> of the function L:
> 
> [Snippet 2 : A part of the layout interpretation algorithm in the Report]
> L (} : ts) (0 : ms) = } : L ts ms (Note 3)
> L (} : ts) ms = parse-error (Note 3)
> [/Snippet 2]
> 
> I suggest this be modified to what follows:
> 
> [Snippet 3 : A Suggested modification to Snippet 2]
> L (} : ts) (m : ms)
>    | m == 0 = } : L ts ms
>    | m > 0 = } : L (} : ts) ms
> L (} : ts) [] = parse-error
> [/Snippet 3]
> 
> 
> 
> Let me explain in detail.
> First of all, how is Snippet 1 refused by the Report 2010 algorithm?
> Let us emulate it by hand. Firstly pre-process Snippet 1:
> 
> [Snippet 4 : Pre-processed Snippet 1]
> {1} main = print t where { t = s where {36} s = 1 :: Int }
> [/Snippet 4]
> 
> I assumed that Snippet 1 is the only line in a file.
> We may compute:
> 
> [Computation 5 : Apply L to Snippet 4]
> L <Snippet 4> []
>   = "{ main = print t where { t = s where { s = 1 :: Int"
>         ++ L "}" [36,0,1]
> [/Computation 5]
> 
> Wait here. What does L do next?
> Looking from top to bottom, we hit the second line in Snippet 2,
> which leads us to parse-error.
> Now you might expect that the line
> 
> [Snippet 6 : Another part of the Report algorithm]
> L (t : ts) (m : ms) = } : (L (t : ts) ms)   if m /= 0 and parse-error(t) 
> (Note 5)
> [/Snippet 6]
> 
> would help, but unfortunately it doesn't work.
> Even if we put aside the fact that Snippet 6 is lower in the text than 
> Snippet 2
> and has lower priority of execution according to the usual Haskell 
> matching rule,
> this line in L won't be triggered by this parse error at all,
> since *parse-error('}') is false!*
> Let us go back to the definition of parse-error(t).
> 
> [Quotation 7 : Note 5 in the Report algorithm]
> The side condition parse-error(t) is to be interpreted as follows:
> if the tokens generated so far by L together with the next token t
> represent an invalid prefix of the Haskell grammar,
> and the tokens generated so far by L followed by the token "}"
> represent a valid prefix of the Haskell grammar, then parse-error(t) is 
> true.
> [/Quotation 7]
> 
> Now, this is the point.
> In this case, "the tokens generated so far by L together with the next 
> token t" is:
> 
> [Snippet 8]
> { main = print t where { t = s where { s = 1 :: Int }
> [/Snippet 8]
> 
> This is a *valid prefix of the Haskell grammar*, and hence 
> parse-error('}') is false.
> 
> 
> 
> Therefore, any Haskell2010-compliant compiler should reject Snippet 1,
> and this doesn't seem to be any sensible choice of specification.
> Speaking generally, I guess the Report 2010's authors wanted
> the case where a inner implicit brace and a outer explicit brace is 
> closed at the same time
> to be processed by the rule in Snippet 6,
> but it doesn't work since Snippet 2 is before Snippet 6 in the 
> definition of L
> and parse-error(t) is always false if t = '}'.
> 
> The fix of this problem is easy: replace Snippet 2 with Snippet 3.
> The added case of m > 0 is doing almost the same thing as Snippet 6, but 
> parse-error(t) is removed.
> If we distinguish implicit close-braces and explicit close-braces,
> the condition m > 0 fully does the job of parse-error('}'),
> so I expect there will be no problem with this modification.
> 
> 
> 
> I apologize you if this long text has exhausted your eyes.
> I hope this suggestion would help.
> 
> Sincerely yours,
> Genki SATO
> 
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>