April 2019 - Haskell-prime

Proposal: Fix a "bug" in the layout interpretation algorithm in Section 10.3 of Report 2010
by 佐藤玄基 30 Apr '19

30 Apr '19

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

2 1

Re: cert on prime expired?
by Gershom B 19 Apr '19

19 Apr '19

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(a)well-typed.com) wrote: Gershom B <gershomb(a)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

2 1

Re: Unabbreviation of Haskell's grammar tokens for readability
by Solomon Ucko 09 Apr '19

09 Apr '19

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(a)gmail.com> wrote: > > > On 7 Apr 2019, at 6:36, Solomon Ucko <solly.ucko(a)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. > > >

1 0

Unabbreviation of Haskell's grammar tokens for readability
by Solomon Ucko 09 Apr '19

09 Apr '19

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.

2 3

LAST CALL to comment on the Appicative/Monad Proposal
by Mario Blažević 02 Apr '19

02 Apr '19

The very first RFC created (https://github.com/haskell/rfcs/pull/1) the Applicative/Monad Proposal, has now reached the Last Call stage. In order to ground the discussion, I have taken some time to update the Prelude and the text of the Haskell Report with its effects before the call. The rendered report is available at https://github.com/blamario/rfcs/blob/amp/report/report/haskell.pdf for your review. TL;DR: The proposed changes to the report add the latest design of the Applicative and Alternative classes, but otherwise are intentionally minimal. Any further modifications, like the MonadFail proposal or moving return out of the Monad class, should be relegated to new RFCs. In some more detail, the changes are: 1. Applicative has been added as a subclass of Functor and superclass of Monad, its methods and laws as currently defined in the base library. The class and all its methods (pure, (<*>), (<*), (*>), and liftA2) are exported from Prelude, but no other Applicative-related functions (like liftA3) are. 2. The Functor class definition has been moved from module Control.Monad to Control.Applicative in order to avoid circular imports. Note that neither module is a part of the language specification. 3. The Monad class has been left unmodified, apart from making Applicative its superclass and adding return a == pure a as a law. 4. Alternative has been added to the Control.Applicative module, but not to Prelude. This is the same treatment already meted to MonadPlus. I'm unsure why MonadPlus even exists in the report, as it has no relevance to the language specification, and I would gladly remove both classes. Please take some time within the following three weeks (including some extra allowance for the upcoming holiday breaks) to vote for or against the proposal, or to leave a comment with suggestions for its improvement.

8 25