Re: [Haskell-cafe] Haskell 2010 report nit?

[Mario Blažević]

On 2019-12-16 1:42 a.m., Viktor Dukhovni wrote:


Not sure where to post about this, and it has likely been noted
elsewhere already, but reading through the report I see in Section
3.17.2


I'm not sure either, but one place you could report it is at 
https://github.com/haskell/rfcs/issues


No guarantees, but it would make the issue slightly less likely to be 
forgotten.






• Consider the following declarations:

   newtype N = N Bool
   dataD = D !Bool

These examples illustrate the difference in pattern matching between types 
defined by data and newtype:

(\  (N True) -> True) ⊥ ⇒⊥
(\  (D True) -> True) ⊥ ⇒⊥
(\ ~(D True) -> True) ⊥ ⇒True

Additional examples may be found in Section 4.2.3.


But unlike the examples in 4.2.3, which do show differences
between "newtype" and "data", the above does not seem to
show any actual difference.  For that the pattern after the
constructor would I believe have to be irrefutable, which
"True" is not.

Thus, e.g. the below (which duplicates 4.2.3) would do the job:

   (\  (N _) -> True) ⊥ ⇒True
   (\  (D _) -> True) ⊥ ⇒⊥

Perhaps I misunderstood something, but if not, and this has
not been noted before, it may be worth fixing in the next
revision.



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Proposal: Fix a "bug" in the layout interpretation algorithm in Section 10.3 of Report 2010

[Mario Blažević]

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  []
  = "{ 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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: cert on prime expired?

[Mario Blažević]

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 
 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 (b...@well-typed.com 
) wrote:



Gershom B mailto:gersh...@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


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Unabbreviation of Haskell's grammar tokens for readability

[Mario Blažević]

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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Mario Blažević]

On 2019-01-16 3:10 p.m., Oliver Charles wrote:
Is there information anywhere on the process for acceptance/rejection 
criteria. It sounds like hvr can outright reject any proposal - are 
there others with that power? What is generally required for acceptance? 
Not meant critically, just interested


	Every active member of the commitee has that power. We could 
contemplate a different approach, like voting, if all members of the 
commitee were active. When you have only a couple of responses to a 
proposal, consensus among those who respond is the only possible way to go.





On Wed, 16 Jan 2019, 8:01 pm Mario Blažević <mailto:mblaze...@stilo.com> wrote:


A month passed since the last call, and I'm sorry to say that the
Applicative/Monad proposal has been rejected. Herbert has vetoed it on
the grounds that it doesn't come packaged with MonadFail and
MonadOfNoReturn proposals.

This is very unfortunate because (I thought) there was finally a
glimmer
of hope for Haskell 2020. The new process used to complete the
RelaxedPolyRec proposal seemed promising, as it worked around the
commitee's letargy problem. As it turns out, that wasn't the only
problem.

In all fairness, Herbert did state [1] he intends to write up the
combination of AMP, MFP, and MNRP the way he likes it. I do hope that
happens, but when and if he submits the combined proposal, I would not
be surprised if, for example, Philippa should veto it on the grounds
that it doesn't include the ApplicativeDo proposal that she's been
vocal
about. This committee is a far cry from the one that gave us Haskell
'98.

A Haskell 2020 report with no AMP would be pointless, in my opinion, so
I'm going to suspend my work on the report until this issue is
resolved.
I still think the best course of action may be to disband the current
disfunctional committee and form a new one, as I proposed [2] before
establishing the new process.

[1] https://github.com/haskell/rfcs/pull/1#issuecomment-448126690
[2]
https://mail.haskell.org/pipermail/haskell-prime/2018-October/004370.html

___
Haskell-prime mailing list
Haskell-prime@haskell.org <mailto:Haskell-prime@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime




--
Mario Blazevic
mblaze...@stilo.com
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Mario Blažević]

A month passed since the last call, and I'm sorry to say that the 
Applicative/Monad proposal has been rejected. Herbert has vetoed it on 
the grounds that it doesn't come packaged with MonadFail and 
MonadOfNoReturn proposals.


This is very unfortunate because (I thought) there was finally a glimmer 
of hope for Haskell 2020. The new process used to complete the 
RelaxedPolyRec proposal seemed promising, as it worked around the 
commitee's letargy problem. As it turns out, that wasn't the only problem.


In all fairness, Herbert did state [1] he intends to write up the 
combination of AMP, MFP, and MNRP the way he likes it. I do hope that 
happens, but when and if he submits the combined proposal, I would not 
be surprised if, for example, Philippa should veto it on the grounds 
that it doesn't include the ApplicativeDo proposal that she's been vocal 
about. This committee is a far cry from the one that gave us Haskell '98.


A Haskell 2020 report with no AMP would be pointless, in my opinion, so 
I'm going to suspend my work on the report until this issue is resolved. 
I still think the best course of action may be to disband the current 
disfunctional committee and form a new one, as I proposed [2] before 
establishing the new process.


[1] https://github.com/haskell/rfcs/pull/1#issuecomment-448126690
[2] 
https://mail.haskell.org/pipermail/haskell-prime/2018-October/004370.html


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the Appicative/Monad Proposal

[Mario Blažević]

On 2018-12-18 7:25 p.m., Doug McIlroy wrote:

I am very glad to see Applicative take its place in the
report: one less mystery in understanding Haskell in the
wild. The following comments pertain to presentation.


Thank you for the comments. I will act on them if we end up accepting 
the proposal.




13.1 Functor class

"The Functor class is used for types that can be mapped over."

"is used for" is extremely vague. Better wording would be
"The functor class comprises types that can be mapped over."

The same comment applies to section 6.3.5.


    This was the wording in Haskell 2010, so I left it in place. I 
agree that this is a good time to improve it.




13.2 Applicative class

A verbal hint about the mnemonic intent of liftA2,
like those for liftA and liftA3 in 13.4, would be helpful.

Why is the "methods" subsection empty?


    Huh, good catch. I copied the output of Haddock into the TeX file, 
I don't know why the methods are missing. I'll have to examine the 
Haddock output more closely.




13.3 Alternative class

This class hasn't been fully integrated into the report.

It is missing from the Standard Prelude (Section 9)
and from its natural place after 6.3.6.


    This was intentional: the proposal is about Applicative, not about 
Alternative. I have added the Alternative class definition to the 
non-normative Control.Applicative module only to parallel the MonadPlus 
definition in the Control.Monad module. Note that Prelude contains no 
trace of MonadPlus either.


    If the present proposal is accepted (with the other repairs you 
suggested), we'll next have a choice to make regarding Alternative. We 
can leave it in its present non-normative state, we can add it to 
Prelude in its full glory, or we can completely excise it from the 
report. I don't have a strong opinion here, but I dislike the first 
option and I have a weak preference for the last one. I'd mete the same 
treatment to MonadPlus, in this case with more conviction, and I've 
created an RFC for it.




<|> appears here without definition and is not in the index.

Why is the "methods" subsection empty?

Doug McIlroy
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Mario Blažević]

On 2018-12-18 2:38 a.m., Herbert Valerio Riedel wrote:

Hello Mario et al.,

On Tue, Dec 18, 2018 at 4:17 AM Mario Blažević  wrote:

While you're reviewing AMP, please take a bit of time to also comment on
the related new MonadPlus excise proposal at
https://github.com/haskell/rfcs/pull/23

The proposal is very short so it should be an easy decision. Thank you.


As I've explained already on the RFC, I refuse (i.e. to make this very
clear: I'm exercising my veto) to accept the AMP change without also
at least a commitment to MFP and MRP. And note that the committee was
created with the explicit request from SPJ that it ought to be a
consensus-based decision process rather than a democratic voting
process -- and there isn't consensus in this matter as far as I'm
concerned.


	What exactly would you consider "a commitment to MFP and MRP"? As for 
myself, they are both on my to-do list. I just don't want to get lost in 
endless discussions without having anything done, so I performed the 
first step, the AMP. If that is accepted, I fully intend to prepare both 
MFP and MRP proposals - unless somebody else does it first. Is that 
commitment enough?


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the Applicative/Monad Proposal

[Mario Blažević]

While you're reviewing AMP, please take a bit of time to also comment on 
the related new MonadPlus excise proposal at 
https://github.com/haskell/rfcs/pull/23


The proposal is very short so it should be an easy decision. Thank you.


On 2018-12-15 6:46 p.m., Mario Blažević wrote:
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.



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

LAST CALL to comment on the Appicative/Monad Proposal

[Mario Blažević]

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.



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Helium II

[Mario Blažević]

On 2018-11-28 2:17 a.m., Jurriaan Hage wrote:

Dear all,

We’ve been active since September making the Helium compiler more Haskell 2010 
compliant.
In particular, we have a branch with support for Haskell 2010 type classes, a 
branch that
supports import/export following the standard, and a branch that compiles to 
LLVM instead
of the `old’ Helium-specific LVM that has become harder and harder to maintain.
These still need to be integrated. When I find time for that is hard to say.

Another project will be taking place in the period Feb-Apr and I expect we can 
tie up a lot of
loose ends then. Current loose ends include newtype, record syntax, integration 
of previous projects,
Cabal support, Quickcheck, strict data fields, improving the LLVM back-end.

One thing I have wondered about: do we actually have something like an 
extensive set of tests
to throw at any Haskell 2010 compliant compiler that would help find mistakes 
on our parr?
My students have come up with a range of examples to test their 
implementations, but there
is nothing like a set of programs you’ve never seen or heard about.



If you want to be really thorough:

1. start with all of Hackage,

2. filter out all packages with the extensions: field in the cabal file,

3. filter out all modules with the {-# LANGUAGE ... #-} pragma,

4. recursively filter out all modules that import any filtered-out module,

5. you're left with a large set of pure Haskell 2010 modules.


    If you'd rather start small, I suspect it's best to look at the 
existing Haskell implementations. For example, there is a test suite at 
https://github.com/ajhc/ajhc/tree/arafura/regress/tests



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

The first proposal has been merged

[Mario Blažević]

    Break out the champagne, because the first Haskell 2020 proposal 
has been fully merged [1]. By fully merged, I mean that the text of the 
report has been updated, so we have accomplished something material. 
Should the Haskell 2020 commitee agree so, we now have the option to 
declare the Haskell 2018 standard finished, merge the report text back 
into the official Haskell Report, and hand it over to future generations.


    Admittedly the RFC in question, -XRelaxedPolyRec, was probably the 
most trivial possible. My preference would be for the members of the 
committee to follow the lead of this proposal and apply the same process 
to more significant issues.


The process to follow is:

1. Take any RFC you're interested in from the In Discussion column of 
the repo project (https://github.com/haskell/rfcs/projects/1). 
Alternatively, write up a new proposal, put it up for discussion, and 
wait a decent time.


2. If there is no serious objection to the proposal after a while, make 
sure all technical objections are addressed and move the RFC to the Last 
Call column. Declare on the mailing list that you've done so.


3. Modify the text of the report on the same branch where the RFC is 
written up. If there is no objection to the proposal in the Last Call 
status in the following two weeks (and there is some approval), move the 
proposal into the Ready for Report column and declare so on the mailing 
list.


4. Leave at least another two weeks to refine the details of the Report 
text, then merge the RFC.


[1] https://github.com/haskell/rfcs/pull/17

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: LAST CALL to comment on the RelaxedPolyRec proposal

[Mario Blažević]

    Having received nothing but positive responses (both of them), the 
RFC for the relaxed dependency analysis 
(https://github.com/haskell/rfcs/pull/17) has been moved to the Ready 
for Report status. I'm going to leave it there for two weeks before I 
merge it in. Just in case there is any last-minute objection or 
amendment to the proposal.



On 2018-11-04 8:31 p.m., Mario Blažević wrote:
I hereby officially announce that the RFC for the relaxed dependency 
analysis (https://github.com/haskell/rfcs/pull/17) has attained the 
rarefied status of Last Call. Please take some time within the 
following two weeks to vote for or against the proposal, or just leave 
a comment to indicate you're still alive but didn't form an opinion on 
it. 


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

LAST CALL to comment on the RelaxedPolyRec proposal

[Mario Blažević]

I hereby officially announce that the RFC for the relaxed dependency 
analysis (https://github.com/haskell/rfcs/pull/17) has attained the 
rarefied status of Last Call. Please take some time within the following 
two weeks to vote for or against the proposal, or just leave a comment 
to indicate you're still alive but didn't form an opinion on it.



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Report merged, steps to follow

[Mario Blažević]

Four weeks having passed since the previous discussion with no 
objections, I have now merged the content of the Haskell Report


from https://github.com/haskell/haskell-report

into https://github.com/haskell/rfcs


    To remind everybody again, the point of this move was to enable 
adding an actionable change to the report to every RFC. From this point 
on, any proposal that passes the full process to becoming accepted can 
update the report by the simple act of getting merged.


    In order to test this process, over a year ago I've picked and 
submitted the least controversial RFC I could find, namely 
https://github.com/haskell/rfcs/pull/17. There has been no objection to 
the proposal. In fact there has been no comment whatsoever, but I 
suppose that's beside the point. So today I have moved the RFC to the 
"Last Call" column (https://github.com/haskell/rfcs/projects/1) as the 
first and only proposal to gain that awesome status.


    It's not at all clear what should happen to the RFC between this 
point and it getting merged, but I'm determined to test drive the 
process with it. This is my plan:


1. I'm going to add update the report with a patch to the report 
content, then


2. wait another two weeks for any objection before

3. moving the proposal from the Last Call to the Ready for Report 
status, then


4. announce that the proposal is Ready for Report and

5. wait another two weeks for the full approval, then finally

6. merge the RFC.


    The only flaw in my cunning plan above is defining what constitutes 
"the full approval". The committee being rather ... disengaged and 
scattered, there is little hope of getting 50% of votes from all its 
members. The criteria of no raised objection, which I've used so far, 
seems much too lax for a full approval. I think the only reasonable fair 
criteria of success would be a public and unanimous approval by at least 
N committee members. I have no idea what N should be, but I know that if 
this test proposal can't garner N approvals, no proposal will ever pass 
the hurdle.


    To make it plain, I suggest we take the number of committee members 
that comment on the test proposal as the maximum bound of N. I do hope 
max(N) > 1.



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Quo vadis?

[Mario Blažević]

On 2018-10-05 01:05 PM, Simon Peyton Jones wrote:

I think the difficulty has always been in finding enough people who are

* Well-informed and well-qualified
* Willing to spend the time to standardise language features

GHC does not help the situation: it's a de-facto standard, which reduces the 
incentives to spend time in standardisation.

I don’t think we should blame anyone for not wanting to invest this time -- no 
shame here.  It is a very significant commitment, as I know from editing the 
Haskell 98 report and the incentives are weak.  Because of that, I am not very 
optimistic about finding such a group -- we have been abortively trying for 
several years.



That sounds like we're stuck with the committee we have. In that case, 
Simon, could you at least pull some strings to have the actual Haskell 
Report placed in the same repository? This is a basic precondition if we 
expect individual efforts to accomplish anything. The minimal steps to 
actually updating the Haskell Report are:


1. write an RFC (we have some already),
2. have it provisionally accepted (not entirely clear how - would
   "no negative votes in 4 weeks" count?),
3. add the modification to the Haskell Report to the RFC,
4. receive the final approval,
5. merge the RFC into the report.

Steps #3 and #5 depend on having the report in the same repository with 
the RFCs. This has been agreed over a year ago:


https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html
https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2017-November/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2018-March/004356.html



If we want to change that, the first thing is to build a case that greater 
standardisation is not just an "abstract good" that we all subscribe to, but 
something whose lack is holding us back.


Neither an abstract good nor a good abstraction are something Haskell 
has ever shied away from. I don't know if you're actually asking for a 
list of "concrete goods"? To start with, every GHC extension that's 
added to a standard means:


- one less item to type in the ubiquitous {-# LANGUAGE ScaryExtension 
#-} pragma,

- one less item to understand for beginners,
- one less item whose necessity must be justified to the team, and
- one less item of whose future stability the management needs to be 
convinced.


I could go on.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Quo vadis?

[Mario Blažević]

On 2018-10-05 09:10 AM, Henrik Nilsson wrote:

Hi,

On 10/05/2018 01:20 PM, Mario Blažević wrote:

 I hereby propose we formally disband the present Haskell 2020
committee. Our performance has been so dismal


It has.

And I should apologise in particular: I've just had far less time than
I thought over the past year for a variety of reasons.


that I feel this is the
only course of action that gives Haskell 2020 any chance of fruition. A
new committee could then be formed with some more dedicated membership.


I'm less convinced about that, though. I believe those who signed up
for H2020 actually are people who believe in the value of an updated
standard and has core expertise to make it happen.


    Regarding the beliefs, if we really represent the most zealous 
group of Haskell enthusiasts, I have to say the community is in deep 
trouble. I have no evidence, but I can only hope you're wrong.


    As for the expertise, my impression is that *everybody* who 
self-nominated for the committee got accepted. My own self-nomination 
e-mail [1] explicitly said that



The main reason I'm applying is because I'm afraid that the commitee 
might disband like the previous one. If there are enough members 
already, feel free to ignore my nomination.


Yet I'm in. This was not a high bar to clear.


I can't see how giving up and forming a new group would speed things 
up or even

increase the chance of success.


    I was kinda hoping for a Simon ex machina, where a few 
universally-accepted members of the community hand-pick a new committee. 
Alternatively, we could come up with some stricter criteria for the next 
committee before we disband but that assumes we can even get a quorum.


    Lest I'm suspected of some Machiavellian plot, let me be clear that 
I refuse to be a part of the next committee, if my proposal should be 
accepted. Honestly I feel that all members of the present committee with 
any sense of shame should recuse themselves as well, but that's not up 
to me.




Instead, what about focusing on identifying a couple of things that
absolutely would have to be in H2020 to make a new standard
worthwhile, like multi-parameter type classes, possibly GADTs,
then figure out what else is needed to support that (like what
Anthony Clayden sketched), and with that as a basis, find out
exactly what technical problems, if any, are hindering progress?

If this could be neatly summarized, then we'd actually be in a position
to make some progress.


    That is much the plan we agreed on over a year ago during ICFP 
2018. The activity since then is plain to see.



[1] 
http://mail.haskell.org/pipermail/haskell-prime/2015-September/003939.html


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Quo vadis?

[Mario Blažević]

On 2018-10-04 09:41 PM, Anthony Clayden wrote:
> There was no Haskell 2020 meeting this year at ICFP. Sadly, interest 
seems to have waned here...
Yes that is sad. So either Haskell 2020 won't happen, or it'll be only 
minor tweaks over H2010, as that was over H98.


The former seems much more likely, judging by the pace so far.

    I hereby propose we formally disband the present Haskell 2020 
committee. Our performance has been so dismal that I feel this is the 
only course of action that gives Haskell 2020 any chance of fruition. A 
new committee could then be formed with some more dedicated membership.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Place to report non-textual (markup) issues on the haskell report?

[Mario Blažević]

Related to this, whatever happened to the fully-agreed task of copying 
the Haskell report LaTeX files over to the RFCs repository?


https://mail.haskell.org/pipermail/haskell-prime/2017-September/004319.html
https://mail.haskell.org/pipermail/haskell-prime/2017-October/thread.html
https://mail.haskell.org/pipermail/haskell-prime/2017-November/thread.html



On 2018-03-24 12:22 PM, Gershom B wrote:
In reviewing tickets, I noticed the following: 
https://github.com/haskell-infra/hl/issues/172


This is not an issue about the haskell homepage, but about the markup 
of the report, with some suggestions on how to make it easier to navigate.


The github repo for the report does not seem to have “issues” turned 
on — I suppose to discourage filing issues against the report itself, 
for which there is a different process.


Nonetheless, I would like to get this information captured in some 
appropriate place/way. I added a label for `haskell-report` to the 
issue, which I guess is a start.


Further suggestions?

—Gershom



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Shall the Haskell Report remain in LaTeX?

[Mario Blažević]

On 2017-10-31 05:28 AM, Nicolas Wu wrote:

It’s a yes from me for us to be using LaTeX, but I think it might be useful to 
use lhs2TeX to generate the LaTeX.

lhs2TeX makes it possible for us to write literate Haskell files as the source 
to the Report, which in turn allows us to type-check much of the code we write, 
which is nice.



	If we agree to use lhs2TeX, we can migrate the Haskell code fragments 
incrementally, after we check in the existing report. I suppose that 
would be just another RFC pull request, so feel free to submit it.




Best wishes,

Nick




On 30 Oct 2017, at 15:39, Mario Blažević <blama...@ciktel.net> wrote:

On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:

Long story short, is everyone ok to stay with (La)TeX, or is there some
compelling reason that would justify migrating to a different
documentation system?



Since nobody said no in the 7 weeks since, I think it's safe to assume yes. Can 
we proceed with this now?

Once the report is a part of the RFCs repository, I assume it will become the 
proper home that pull requests https://github.com/haskell/haskell-report/pull/3 
(if also accompanied by an RFC).


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Shall the Haskell Report remain in LaTeX?

[Mario Blažević]

On 2017-09-09 09:40 AM, Herbert Valerio Riedel wrote:

Long story short, is everyone ok to stay with (La)TeX, or is there some
compelling reason that would justify migrating to a different
documentation system?



Since nobody said no in the 7 weeks since, I think it's safe to assume 
yes. Can we proceed with this now?


Once the report is a part of the RFCs repository, I assume it will 
become the proper home that pull requests 
https://github.com/haskell/haskell-report/pull/3 (if also accompanied by 
an RFC).



___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Whose gonna be at icfp?

[Mario Blažević]

On 2017-08-25 06:48 PM, Carter Schonwald wrote:

I'll be this time! :)

We should coord a committee catch-up at icfp.

Also I would like to propose we shift back to email based discussion. 
There's still the valid and important need of then taking the 
discussion and revisions into a new standard. But let's at least make 
the first half lighter weight perhaps? the pattern that's working for 
ghc proposals doesn't seem to matchup with what works for h2020


I'll be there as well. As for the e-mail based discussion, my 
feeling for the last while has been that I'd rather bring something, 
anything, to completion. There's very little feedback and there's a real 
danger that the discussion doesn't lead to any concrete change to the 
standard.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Default module header `module Main where`

[Mario Blažević]

On 2017-05-24 10:28 AM, Joachim Breitner wrote:

I've ended up uncertain, so I'll just throw it out there: are unused
value warnings affected by this proposal?


that is a very good point, thanks for raising it. I have two different
answers:

A) You are right. Everything is exported, so without an explicit module
header, unused value warnings would not happen. This is undesirable,
and thus this proposal should probably be killed.

B) Warnings are not specified by the report, and the implementation is
free to warn about unused bindings in a headerless Main module, based
on the implementation’s knowledge that even though these are exported,
they are not used.


I would say

B') Warnings are not specified by the report.

We can pretty much stop there. If you want to go deeper, IMO the 
compiler should just suppress the warnings by default. A headerless 
module would normally be used only for examples and quick tests, unused 
binding warnings would be a nuisance for that use case.




But answer B is less convincing in the corner case of Main being
mutually recursive with another module. (Who would do that without
naming Main? But yes, it is a problem.)


	When dicussing a software-engineering issue like compiler warnings, as 
opposed to a language-design issue, it doesn't make sense to concentrate 
on corner cases. A non-root Main module is already a corner case. A 
non-root header-less Main module is a corner inside a corner case. 
Whoever does that may miss some compiler warnings, depending on the 
compiler implementation. I won't lose any sleep over that. If the 
compiler developers do, they have the option to issue the unused-binding 
warnings only when a header-less module is imported.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Default module header `module Main where`

[Mario Blažević]

On 19/05/17 07:12 PM, Francesco Ariis wrote:

On Fri, May 19, 2017 at 06:32:30PM -0400, Joachim Breitner wrote:

I thought about this. But I fear that this will require a language
extension or flag, and then the developers (quite rightly) say that it
does not pull its weight of supporting both variants, and it gets lost.
But maybe I should give it a shot if they accept it.

Indeed this strikes me as a not a good extension to have: every extension
further fragments the ecosystem and is yet another thing to care about if
you are reading someone else's code, etc. - the cost probably outweights
the benefit on this one.

But it seems a good proposal for H2020, as (if it is accepted), the costs
linked with an extension/flag (added complexity, fragmentation of the
community) aren't there.

The "extensions before report modification" is a solid rule, maybe
the committee wants to add an exception for proposals which cannot
realistically be "packaged" (and achieve widespread use) into
extensions?


I feel it's rather ironic that there exists a class of proposals 
that are considered acceptable for Haskell' but too radical for GHC, 
considering that the stands are usually completely opposite.


The obvious way out of this conundrum is to communicate with GHC. 
If the Haskell' committee gives a proposal some sort of conditional 
acceptance status, that should count for something with the GHC HQ. 
After all, they'd presumably have to implement it once it's officially a 
part of the next standard, so implementing it sooner as a proposal is 
not that much more to ask.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Default module header `module Main where`

[Mario Blažević]

On 2017-05-16 10:18 AM, Joachim Breitner wrote:

Hi,

a very small proposal to be considered for Haskell':


	I like it, but it should probably be a GHC proposal first. I don't 
think Haskell' is supposed to make any change to the standard that 
hasn't been already implemented and tested. In this particular case, GHC 
HQ might opt to implement your proposal but hide it behind a 
command-line option, or to enable it by default only in GHCi. There are 
already precedents for this.





Currently, the report states

An abbreviated form of module, consisting only of the module body,
is permitted. If this is used, the header is assumed to be ‘module
Main(main) where’.

I propose to change that to

An abbreviated form of module, consisting only of the module body,
is permitted. If this is used, the header is assumed to be ‘module
Main where’.

The rationale is that a main-less main module is still useful, e.g.
when you are working a lot in GHCi, and offload a few extensions to a
separate file. Currently, tools like hdevtools will complain about a
missing main function when editing such a file.

It would also work better with GHC’s -main-is flag, and avoid problems
like the one described in https://ghc.haskell.org/trac/ghc/ticket/13704


I don’t see any downsides. When compiling to a binary, implementations
are still able to detect that a Main module is not imported by any
other module and only the main function is used, and optimize as if
only main were exported.

Greetings,
Joachim





___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime




--
Mario Blazevic
mblaze...@stilo.com
Stilo International

This message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient(s) please contact the sender by reply email and destroy
all copies of the original message and any attachments.
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Proposal: accept tuple sections

[Mario Blažević]

On 2016-10-12 12:41 PM, Iavor Diatchki wrote:

Hello,

it seems that there isn't much controversy over the TupleSections
propsal, so I'd like to move the we accept it for the next language
standard.

Does anyone have any objections?


	I have no objection to the proposal in the abstract, but I don't think 
the concrete proposal is completely fleshed out. I'd prefer to see the 
actual modifications to Haskell 2010 grammar, at least, before the final 
vote.


	The above comment should really be in the RFCs repository, attached to 
the proposal. Is that doable?


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Process question

[Mario Blažević]

On 2016-10-04 01:09 PM, Iavor Diatchki wrote:

Hello,

Now that we've started with a few proposal, I am realizing that I have
no idea how to proceed from here.  In particular:

1. How would I request I proposal to be rejected
2. How would I request that a proposal be accepted


	I don't know if we need to fix the acceptance/rejection process so 
early on. Once a new proposal is merged in, it need not be immediately 
accepted or rejected. It could just collect comments and adjustments. I 
see no point in voting for acceptance or rejection until the time comes 
to prepare Haskell 2020.


	If my understanding of the process is correct, this raises two more 
groups of questions.


1. I assume we'd use GitHub issues to discuss and/or point flaws in a 
particular proposal?


1a. If so, it would be nice to group together all issues related to a 
paricular proposal, but GitHub issues don't come with much metadata. Do 
we prescribe some keyword that has to be specified in the subject of 
each proposal-related issue?


1b. There could be a special "Accept me" issue for each proposal used 
for tracking its status. GitHub issues can be assigned to milestones, 
such as "Accepted for Haskell2020", "Last Call for Votes", "Awaiting 
Comments", or "Work In Progress".


2. How do we prepare the actual Haskell 2020 language report? The report 
is more than a collection of disparate proposals. The Haskell 2010 
report also contains errors whose fixing shouldn't require writing up a 
whole language proposal.


2a. Would the current text of the Haskell' language report be stored in 
the same GitHub repository with the RFCs? If not, where else?


2b. Would we merge each proposal into the language report as soon as 
it's accepted? Whose responsibility would this (largely mechanical) 
process be?


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Meet up at ICFP?

[Mario Blažević]

On 2016-09-14 02:17 PM, José Manuel Calderón Trilla wrote:

Richard has also volunteered to act as secretary for the meeting so
that the minutes of the meeting can be posted. Thanks Richard!


Thanks from all of us who can't attend as well. Please do post the minutes!

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Infrastructure & Communication

[Mario Blažević]

On 04/29/2016 07:15 AM, Francesco Ariis wrote:

Hello,
 personally I would be more likely to read/participate in the
discussions if such discussions were hosted here or on Trac rather
than Github.


There are two or three distinct components we need to keep track 
of: the draft standard, discussions, and potentially RFCs.


Discussions can be hosted on this mailing list, on Trac, or as Git 
issues. Each of them would serve fine, but we should choose exactly one 
and stick to it. The mailing list looks pretty good in isolation, but 
the best choice depends on whether we want to have RFCs or not.


If we support Requests for Comments, we'll need to also support 
their public submissions and Git pull requests or something to the same 
effect. In that case, at least the inevitable comments on RFCs would 
best be placed close to the RFCs themselves - if the RFCs end up on 
GitHub the discussions of them should be kept as GitHub issues.


___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

Re: Breaking Changes and Long Term Support Haskell

[Mario Blažević]

On 15-10-22 09:29 AM, Geoffrey Mainland wrote:

...

1) What is the master plan, and where is it documented, even if this
document is not up to the standard of a proposal? What is the final
target, and when might we expect it to be reached? What is in the
pipeline after MRP?

Relatedly, guidance on how to write code now so that it will be
compatible with future changes helps mitigate the stability issue.


	I have been fully in favour of all the proposals implemented so far, 
and I think that having an explicit master plan would be a great idea. 
It would address some of the process-related objections that have been 
raised, and it would provide a fixed long-term target that would be much 
easier to make the whole community aware of and contribute to.


	For that purpose, the master plan should be advertised directly on the 
front page of haskell.org. Once we have it settled and agreed, the 
purpose of the base-library commitee would essentially become to figure 
out the details like the timeline and code migration path. One thing 
they wouldn't need to worry about is whether anybody disagrees with 
their goals.




2) How can I write code that makes use of the Prelude so that it will
work with every new GHC release over the next 3 years? 5 years? For
example, how can I write a Monad instance now, knowing the changes that
are coming, so that the instance will work with every new GHC release
for the next 3 years? 5 years? If the answer is "you can't," then when
might I be able to do such a thing? As of 8.4? 8.6? I'm embarrassed to
say I don't know the answer!


	From the discussions so far it appears that the answer for 3 years (or 
at least the next 3 GHC releases) would be to write the code that works 
with the current GHC and base, but this policy has not been codified 
anywhere yet. Knowing the upcoming changes doesn't help with making your 
code any more robust, and I think that's a shame. We could have a 
two-pronged policy:


- code that works and compiles with the latest GHC with no *warnings* 
will continue to work and compile with no *errors* with the following 2 
releases, and
- code that also follows the forward-compatibility recommendations 
current for that version of GHC will continue to work and compile with 
no *errors* with the following 4 releases.


	The forward-compatibility recommendations would become a part of the 
online GHC documentation so nobody complains they didn't know about 
them. Personally, I'd prefer if the recommendations were built into the 
compiler itself as a new class of warnings, but then (a) some people 
would insist on turning them on together with -Werror and then complain 
when their builds break and (b) this would increase the pressure on GHC 
implementors.




Finally, if none of these changes broke Prelude backwards compatibility,
far fewer people would be complaining :) Of course, we can't always make
progress without breaking things, but a more deliberative process might
offer an opportunity to make progress while still preserving backwards
compatibility. Take AMP for example. There were at least two [3] [4]
proposals for preserving backwards compatibility. Investigating them
would have taken time and delayed AMP, yes, but why the rush?


Because they have been investigated for years with no effect.



3) Can we have a process that allows more deliberation over, and wider
publicity for, changes that break backwards compatibility? The goal of
such a process would not be to prevent change, but to allow more time to
find possible solution to the issue of backwards compatibility.


I doubt we can, but this question has already been answered by others.

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime

A reluctant self-nomination

[Mario Blažević]

	I'm hereby self-nominating for the Haskell' commitee. The main reason 
I'm applying is because I'm afraid that the commitee might disband like 
the previous one. If there are enough members already, feel free to 
ignore my nomination.


That being said, here are my qualifications:

	I started programming in Haskell around the turn of the century. I 
first published on Hackage in 2008 [1]. I have published 9 packages so 
far [2], 2 of which are deprecated, and I made small contributions to 
several other Haskell projects over the years. My projects generally use 
the minimal set of GHC's extensions that's necessary for the job.


	While I occasionally comment on Reddit and the mailing lists, I don't 
publicise much [3][4]. Last year I've managed to get Haskell into 
production at work.


	Outside Haskell, my job involves plenty of language maintenance and DSL 
design, though I wouldn't consider any of it close to the Haskell level 
of sophistication. In particular, I'm sorely lacking the expertise in 
type theory. On the other hand, I have plenty of experience in DSL 
support and language evolution. I can provide more details if necessary.


[1] http://hackage.haskell.org/package/scc-0.1
[2] http://hackage.haskell.org/user/MarioBlazevic
[3] https://themonadreader.files.wordpress.com/2011/10/issue19.pdf
[4] 
https://github.com/blamario/monoid-subclasses/wiki/Files/HaskellSymposium2013.pdf

___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime