- Haskell-prime - Haskell.org

Re: Humble message of support and concern from an interested newbie
by Cale Gibbard 12 Nov '21

12 Nov '21

To some extent I can agree with the view that certain small things should possibly be folded in, but from another perspective, I actually like the way that major language features are modular, and I can tell a lot about what to expect by looking at the top of a file. There are also things that most people agree are a decent part of the language, but should also probably never stop being extensions, like FFI and Template Haskell. But while warning users about certain things being controversial or unstable and certain things being less so could be something that one could put in the Report, I wouldn't want any change to the language to start there. If you try to make changes to the language as it exists while also documenting it, you'll end up in a season of bikeshedding that will never end, and at the same time end up describing a creature that doesn't exist. See the ghc-proposals mailing list for a more appropriate place to begin with changes to the language at present. See also this proposal: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0380-g… which has been implemented in the latest GHC 9.2 for defining a particular "GHC2021" agglomeration of some of the most commonly used extensions. There's also a table there containing some nice usage statistics that were collected from Hackage. >From the other side of things, I think the Report, if revived, should not shy away from trying to describe as many of the extensions as people have the energy to describe, controversial/unstable or not. The most important purpose for which I'd really like to have a Report at present would be to properly clarify the interactions between extensions. For example, how do you figure out what happens when you use functional dependencies and type equality constraints together? Exactly how does GHC know when to instantiate a quantified constraint, and how does that interact with type family expansion? Even the technical papers written about these features don't necessarily answer questions about these interactions, so if you start using them together, cases can arise where it can be difficult to determine what's going to happen. Often things will just work as you might hope, even if you're not entirely certain why. Once in a blue moon though, you might just get weird error messages that don't quite make sense, but seem to indicate that the compiler is very confused. Then perhaps you try a newer GHC, and find out that particular combination of things is now simply forbidden outright. So it would be nice to really get everything into a single framework of description, and there have been some rather large efforts in the direction of unifying large chunks of it, like the OutsideIn(X) paper (which is already perhaps too technical compared with the Report), but it's by no means easy. Also, typical users of the language eventually have to contend with most of the extensions, controversial or not, and it would be very nice to have a reference for what things are supposed to mean regardless of whether we'd rather they not be in the language at all. The Report would also be a great place to have a little bit of guidance and statistics on how stable/well-used these things are. - Cale On Mon, 8 Nov 2021 at 21:41, Haowen Liu <lhw(a)lunacd.com> wrote: > Hi Cale and others, > > Thank you Cale so so much for such a detailed explanation! > > I agree with you that an evolving standard is only useful as a > normalizing force if we have multiple compilers, like C/C++. Such is the > same for the standard as documentation since GHC documentation is really > what people should refer to. > > I realize I'm in no way qualified to make those points but in my meager > experience with Haskell, an evolving standard could serve as a very > valuable verdict of the merits of various GHC extensions. AFAIK, some > GHC extensions are very widely adopted and some are considered > misfeatures. The Haskell202X could simply incorporate a list of > agreeable extensions into the core language and those less agreeable > ones could stay as extensions or whatever the GHC community decides to > do with them. > > I think such kind of Haskell202X is advantageous in the following ways: > > 1. It is less time consuming than radical language changes. And the very > fact that the Haskell202X effort is halted proves that Haskell currently > demands no radical changes (at least not the ones that can't be > implemented as a GHC extension). > > 2. We no longer to enable a series of widely used plugins. Many of the > extensions integrate so nicely into the language that I don't think > programmers should be required to manually enable them to use them. > According to Sandy Maguire, "In GHC 8.6.5, there are 125 different > language extensions, and an analysis shows that 10% of Haskell files in > the wild enable 10 or more extensions." [1] > > 3. People are less likely to use those less agreeable extensions because > at that time enabling extensions would be a rare case of workaround (as > it should be, I believe) rather than a norm. > > 4. It gives people, especially newcomers, a sense that Haskell is still > very much alive. > > In addition to integrating extensions, in very rare cases, we could slip > in some feature removal or modifications in areas where people feel > strongly about. But even with those, I feel like this work is very much > doable. > > Best, > Haowen > On 11/8/2021 3:45 PM, Cale Gibbard wrote: > > The tricky thing is that while a new document describing the language in > > detail would be welcomed, it's hard for people to justify doing all the > > work that's involved in producing a new document that's substantially > > more helpful than the Haskell 2010 or '98 Report. Right at the moment, > > there's essentially one practically-usable implementation of the > > language, GHC (unless maybe you count GHCJS, and that's sharing GHC's > > frontend regardless). So the demand for a document that says what needs > > to be shared between implementations of the language is low. Personally, > > I think producing a description of what GHC is meant to be implementing, > > with as complete coverage of all the extensions as can be managed, i.e. > > a report, is something that would be quite valuable. However, that's a > > very large task, and most of the people who would be well-suited to > > produce that document have other constraints on their time. I don't > > think there's a pressing need for a normative standards document at the > > moment though. > > > > Maybe if some Haskell-using company were to get large enough to devote a > > team to working on a new general purpose Haskell compiler for some > > reason, or there was a big open-source push for a second Haskell > > compiler, there would be cause for a normative standard. But for now, > > everyone's been more or less content with working together extending GHC > > rather than building something entirely new. (I would have a fair amount > > of sympathy for someone wanting to start fresh though. I have my own > > list of reasons for which I can imagine wanting to take a shot at > > reimplementing the language, but I don't really have the time or energy > > for it myself.) > > > > For the descriptive side of things, most people get by right now with > > the GHC User's Guide, and failing that, there are often papers that go > > into much greater detail about the individual extensions. If you want to > > really understand the finer details of how those extensions all interact > > with one another though, there's presently nothing apart from the > > compiler itself (and even then, how they *ought* to interact is a > > different question from how they *do* interact). Understanding that and > > describing it all in a precise way is a big and difficult task, and it's > > one whose cost sadly might outweigh its benefits, especially if the > > progress toward a new Haskell Report is any indication. > > > > Even more, I think most would be delighted to see a denotational > > semantics for all of Haskell again. But it's one of those things which > > is difficult to produce in the first place, and then unless a process > > were in place to have it track the implementation, it would almost > > immediately fall out of date. > > > > That said, I can imagine there will be a point where the process to > > write a new Report kicks back off, I just don't think it's been at the > > forefront of most people's minds lately. > > > > - Cale > > > > On Mon, 8 Nov 2021 at 17:55, Haowen Liu via Haskell-prime > > <haskell-prime(a)haskell.org <mailto:haskell-prime@haskell.org>> wrote: > > > > Hi, > > > > I hope this email finds you all well. I'm a newbie only starting with > > Haskell very recently, but I LOVE what I'm discovering with Haskell > and > > its ecosystem. That's why I was shocked to see that the latest > Haskell > > standard is still Haskell2010, and activities on this list has halted > > for 3 years. > > > > I skimmed through the Haskell2010 spec and understand deeply that the > > next Haskell standard will be an equally challenging enterprise. I, > > although yet to be sufficiently familiar with Haskell, want to let > you > > all know that I'm hugely grateful for all the work you have done, and > > I'm more than willing to extend any kind of help moving forward with > > the > > next Haskell standard. If people are still interested in developing > > Haskell202X, and if people need some sort of secretary, editor, > errand > > runner, or whatever, please let me know and I can help. > > > > Grateful, concerned, and eager to help, > > Haowen Liu > > _______________________________________________ > > Haskell-prime mailing list > > Haskell-prime(a)haskell.org <mailto:Haskell-prime@haskell.org> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime > > <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime> > > >

3 6

Humble message of support and concern from an interested newbie
by Haowen Liu 08 Nov '21

08 Nov '21

Hi, I hope this email finds you all well. I'm a newbie only starting with Haskell very recently, but I LOVE what I'm discovering with Haskell and its ecosystem. That's why I was shocked to see that the latest Haskell standard is still Haskell2010, and activities on this list has halted for 3 years. I skimmed through the Haskell2010 spec and understand deeply that the next Haskell standard will be an equally challenging enterprise. I, although yet to be sufficiently familiar with Haskell, want to let you all know that I'm hugely grateful for all the work you have done, and I'm more than willing to extend any kind of help moving forward with the next Haskell standard. If people are still interested in developing Haskell202X, and if people need some sort of secretary, editor, errand runner, or whatever, please let me know and I can help. Grateful, concerned, and eager to help, Haowen Liu

2 1

Re: [Haskell-cafe] Haskell 2010 report nit?
by Mario Blažević 18 Dec '19

18 Dec '19

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 >> data D = 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. >

1 0

Re: [Haskell-cafe] Expired certificate for prime.haskell.org
by Simon Jakobi 01 Nov '19

01 Nov '19

Thanks a lot Ben! After a bit of searching I found the page for the SMP proposal: https://gitlab.haskell.org/haskell/prime/wikis/libraries/proposals/semigrou… I noticed that the code blocks there are a bit mangled. If your import tools could fix that programmatically, that would be very nice! Cheers, Simon Am Sa., 2. Nov. 2019 um 01:45 Uhr schrieb Ben Gamari <ben(a)well-typed.com>: > > Ben Gamari <ben(a)well-typed.com> writes: > > > Yes, running the gitlab import on prime.haskell.org is one of the last > > things on my list before that box can be torn down. I'll try to do it > > tomorrow. > > > I have gone ahead and imported the issues, wiki, and repository content > from prime.haskell.org to GitLab [1]. Do let me know whether anything > looks amiss. > > Cheers, > > - Ben > > > [1] https://gitlab.haskell.org/haskell/prime

1 0

Expired certificate for prime.haskell.org
by Simon Jakobi 31 Oct '19

31 Oct '19

Hi! I just wanted to give someone a link to the Semigroup-Monoid-proposal, but couldn't open the page in Chromium: https://prime.haskell.org/wiki/Libraries/Proposals/SemigroupMonoid There's already a short email thread regarding the issue from April on the haskell-prime mailing list: https://mail.haskell.org/pipermail/haskell-prime/2019-April/004448.html It would be nice if proposals like the SMP remained accessible! Cheers, Simon

1 0

Volunteer for a panel at HIW 2019
by Iavor Diatchki 26 Jul '19

26 Jul '19

Hello, I am sending this on behalf of Nikki Vazou, who is organizing this year's HIW---she is looking for a volunteer to represent Haskell' on a panel, but the haskell-prime list is restricted to only members. Details are in her message below. If you are interested, please respond directly to her. Cheers, -Iavor PS: Niki sorry for the multiple messages, my message also bounced because apparently I used the wrong e-mail address. > > > ---------- Forwarded message ---------- > From: Niki Vazou <nvazou(a)cs.ucsd.edu> > To: haskell-prime(a)haskell.org > Cc: > Bcc: > Date: Fri, 26 Jul 2019 14:13:36 +0200 > Subject: Haskell Implementors Working: Looking for Panelists > Hello, > > Haskell Implementors Workshop 2019 will be having a 45 min panel discussion (17.15-18.00 on Fri 23th August). > > The goal is to have panelists that represent the following committees: > - ghc steering committee > - Devops committee > - core libraries committee > - Haskell' committee > - Haskell.org committee > - Haskell Symposium & HiW steering committee > > Let me know if you > - want like to be in the panel > - if there are issues you want to raise in the panel discussion. > > Best, > Niki > Chair of HiW'19

1 0

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

29 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 08 Apr '19

08 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