- Haskell-prime - Haskell.org

Re: A question about run-time errors when class members are undefined
by Anthony Clayden 13 Oct '18

13 Oct '18

On Mon, 8 Oct 2018 at 8:41 PM, Simon Peyton Jones wrote You may be interested in Carlos Camarao’s interesting work. For a long > time now he has advocated (in effect) making each function into its own > type class, rather that grouping them into classes. Perhaps that is in > line with your thinking. > Could I ask Simon direct, since it was he who introduced the topic. When you say "interesting work", what is that evaluation based on? Is there a paper or summary you've seen that expresses the ideas? (Because despite the exhaustive and exhausting rounds on github last year, and further comment on this thread, I just can't see anything workable. And the papers that Carlos references ring alarm bells for me, just looking at the Abstracts, let alone delving into the impenetrable type theory.) And could I ask Carlos: are we allowed to know who peer-reviewed your papers? Specifically, was it someone who's up with the state of the art in GHC? Carlos/his team are making bold claims: to provide the functionality of FunDeps/Type functions, Overlapping Instances/Closed Type Families, to avoid the infamous `read . show` ambiguity, to avoid the equally infamous 'orphan instances' incoherence, to preserve principal typing, and to keep it "simple". Then I have to say that if there's evidence for those claims, it's not appearing in the papers. Really the only example presented is `read . show` (plus record field disambiguation). Yes I'd hope the approach for a simple example is "simple". It doesn't seem any more simple than putting an explicit type signature (or we could use type application `@` these days). But I don't expect that would be the place to show off the power/expressivity. Thank you AntC

2 2

Re: Quo vadis?
by Anthony Clayden 09 Oct '18

09 Oct '18

> 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. It's hard to imagine any serious Haskelling without FlexibleInstances/FlexibleContexts, MultiParamTypeClasses, UndecidableInstances -- and yet all of those are beyond Haskell 2010. And they were available in at least 2 compilers by around 2000. (Possibly they weren't by then entirely polished. I saw a claim on a StackOverflow answer that Hugs, last release 2006, is not H2010 compliant: not true; indeed several of the H2010 changes since H98 were proposed by the Hugs dev team, and agreed by the GHC team because GHC had copied Hugs.) I've had comments from non-Haskellers that they won't take Haskell seriously, because it seems to be a bunch of 'risky'/unstable/experimental features. Whereas I know those features have been stable at least a dozen years. And yet we still face the same conundrums as did H2010: With FlexibleInstances we can write overlapping instances. With FlexibleContexts we can put overlapping constraints on an instance, even if the head's types are H98 (non-Flexible). With MultiParamTypeClasses (which were anticipated in Wadler's very earliest 1988 proposal for typeclasses) we're bound to choose FunDeps and/or type families. FunDep instances either need repeated tyvars -- which brings us straight back to FlexibleInstances, or UndecidableInstances -- which will almost certainly lead to FlexibleInstances somewhere. I feel those parts of Haskell have been in suspended animation/arrested development since ~2006: that was the last release of Hugs; the 'FunDeps via CHRs' paper [**]; the start of associated types/type families. [**] AFAICT, that paper was a purely academic exercise: GHC was not changed in light of its findings, so has a bogus implementation of FunDeps that persists to this day. The paper did not address the combo of FunDeps + Overlaps, so said nothing about what had been a stable cottage industry of type-level programming since at least 2004 (the HList paper). Is there a terms of ref for Haskell 2020? Would any of the above issues be within its scope? (Supposing there were any interest ...) AntC

7 14

Quo vadis?
by Mario Blažević 03 Oct '18

03 Oct '18

I could not attend ICFP this year. Has there been any discussion at all of Haskell 2020 there? If so, can the rest of us get a summary?

2 1

A question about run-time errors when class members are undefined
by Jurriaan Hage 01 Oct '18

01 Oct '18

Hello, We are adding classes and instances to Helium. We wondered about the aspect that it is allowed to have a class instance of which not all fields have a piece of code/value associated with them, and that as a result when you happen to call these, a run-time error results. (see Sec. 4.3.2 of the Haskell 2010 report). Does anyone know of a rationale for this choice, since it seems rather unhaskell-like. best, Jur

2 1

Local types and instances
by M Farkas-Dyck 29 Apr '18

29 Apr '18

Idea: Allow local type and instance declarations, i.e. in `let` or `where` clause. Primary motivation: defining `ordNubBy` and such, i.e. functions which take an effective class dictionary In Haskell now, we can readily write `ordNubOn :: Ord b => (a -> b) -> [a] -> [a]` in terms of `Set` [0], but not `ordNubBy :: (a -> a -> Ordering) -> [a] -> [a]`, as `Set` requires an `Ord` instance. This is for good reason — incoherence would destroy the guaranties of `Set` — but in the case of `ordNubBy`, the `Set` would never escape, so it's fine. I needed `ordNubBy` in a past job, so we actually copied much of the `Set` code and modified it to take an `(a -> a -> Ordering)` rather than have an `Ord` constraint, which works but is unfortunate. This proposal would allow the following: ``` ordNubBy :: (a -> a -> Ordering) -> [a] -> [a] ordNubBy f = let newtype T = T { unT :: a } instance Ord T where compare = f in fmap unT . ordNub . fmap T ``` Secondary motivation: defining local utility types in general Note: The primary motivation is a subcase of this, with local instances defined in terms of local arguments. It is sometimes convenient or necessary to define a utility type which is only used in the scope of a single term. It would be nice to be able to define this in a `let` or `where` clause rather than at top level, for the same reason it is nice to be able to define helper functions there. Semantics: My thought is the local type is unique to each use of the term it is defined in, to not cause incoherence. I believe the implementation should be feasible as typeclass constraints are lowered to dictionary arguments anyhow. But i am neither a type theorist nor an expert in GHC so please point out any flaws in my idea. I'm also thinking the type of the term where the local type is defined is not allowed to contain the local type. I'm not sure what the soundness implications of allowing this (unique) type to escape would be, but it seems like it might lead to confusing error messages when types which seem to have the same name can't be unified, and generally trips my informal mental footgun alarm. Thoughts? [0] https://gist.github.com/strake/333dfd697a1ade4fea69e6c36536fc16

4 4

Place to report non-textual (markup) issues on the haskell report?
by Gershom B 25 Mar '18

25 Mar '18

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

2 1

Haskell Report 2010: pattern bindings
by Simon Peyton Jones 19 Mar '18

19 Mar '18

Thanks Jose. The other issue I have in mind is that of pattern bindings. Currently in the 2010 Haskell Report * The text on the monomorphism restriction<https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-880004…> (4.5.5) refers to “simple pattern bindings”. * It claims that a simple pattern binding “is a pattern binding in which the pattern consists of a single variable” * You’d expect “simple pattern binding” to be defined in 3.17.1 Patterns<https://www.haskell.org/onlinereport/haskell2010/haskellch3.html#x8-580003.…>. But it isn’t. * Instead, 4.4.3.2 Pattern bindings<https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-800004…> explicitly contradicts 4.5.5 by saying “a simple pattern binding has form p=e”. What a mess! The simplest way out is probably: * Define “simple pattern binding” to be of form x=e, in 3.17.1. * Fix the first para of 4.4.3.2. * Fix the cross-ref in 4.5.5 to refer to the definition of simple pattern. Sadly, 4.4.3.2 still is not very well defined. It’s supposed to say what pattern bindings mean, including top-level ones; but it does so by referring to 3.12 which does not handle top-level bindings. I’m not sure if this is worth fixing. Simon From: José Manuel Calderón Trilla <jmct(a)jmct.cc> Sent: 15 March 2018 23:17 To: Simon Peyton Jones <simonpj(a)microsoft.com>; haskell-prime(a)haskell.org; ghc-devs(a)haskell.org Subject: Re: [Haskell] The Haskell Report: who maintains it? All of us on the Haskell Language Committee have the ability to commit on that repo. I think typos are uncontroversial and I'll happily merge pull requests like that. I think the pull-request you point out suffered from the bystander effect, unfortunately. I'll review and merge it now. If you let me know the typo you'd like fixed I'll make sure that gets done as well. Cheers, José Manuel On Thu, Mar 15, 2018, at 6:52 PM, Simon Peyton Jones via Haskell wrote: Friends Does anyone know who, if anyone, feels responsible for committing updates to the Haskell 2010 Report? Who even has commit rights? There’s Frank’s pull request below, and I have another important typo to fix. Thanks Simon From: Frank Steffahn [mailto:notifications@github.com] Sent: 11 March 2018 17:03 To: haskell/haskell-report <haskell-report(a)noreply.github.com> Cc: Subscribed <subscribed(a)noreply.github.com> Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4) Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / mistake. I’m not 100% sure if this is the right branch (or even in general the right place) to note this, but I hope it will get fixed ;-) This seems like it is an artifact of copy-and-pasting from “Semantics of Case Expressions, Part 1 (c)” without properly adapting the thing, especially in commit bc94554. ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/haskell/haskell-report/pull/4<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> Commit Summary * Fix a typo in: Semantics of Case Expressions, Part 3 (s) File Changes * M report/exps.verb<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> (1) Patch Links: * https://github.com/haskell/haskell-report/pull/4.patch<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> * https://github.com/haskell/haskell-report/pull/4.diff<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>. _______________________________________________ Haskell mailing list Haskell(a)haskell.org<mailto:Haskell@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…>

1 0

The Haskell Report: who maintains it?
by Simon Peyton Jones 15 Mar '18

15 Mar '18

Friends Does anyone know who, if anyone, feels responsible for committing updates to the Haskell 2010 Report? Who even has commit rights? There’s Frank’s pull request below, and I have another important typo to fix. Thanks Simon From: Frank Steffahn [mailto:notifications@github.com] Sent: 11 March 2018 17:03 To: haskell/haskell-report <haskell-report(a)noreply.github.com> Cc: Subscribed <subscribed(a)noreply.github.com> Subject: [haskell/haskell-report] Fix a typo in: Semantics of Case Expressions, Part 3 (s) (#4) Hi. I noticed this in the Haskell 2010 report, which is an obvious typo / mistake. I’m not 100% sure if this is the right branch (or even in general the right place) to note this, but I hope it will get fixed ;-) This seems like it is an artifact of copy-and-pasting from “Semantics of Case Expressions, Part 1 (c)” without properly adapting the thing, especially in commit bc94554<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>. ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/haskell/haskell-report/pull/4<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> Commit Summary * Fix a typo in: Semantics of Case Expressions, Part 3 (s) File Changes * M report/exps.verb<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> (1) Patch Links: * https://github.com/haskell/haskell-report/pull/4.patch<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> * https://github.com/haskell/haskell-report/pull/4.diff<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>, or mute the thread<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com…>.

2 1

Re: Shall the Haskell Report remain in LaTeX?
by Doug McIlroy 07 Nov '17

07 Nov '17

> The good thing about laTeX is that out of all the candidates it is the > most likely one to still work 40 years from now, If past results are any measure of future performance, the only candidate with demonstrated 40-year longevity is troff/groff :) Doug McIlroy

1 0

Re: Remove eq and show from num class
by Mario Blazevic 07 Nov '17

07 Nov '17

Sending to the mailing list instead of to Herbert alone... On Thu, Sep 7, 2017 at 2:20 PM, Herbert Valerio Riedel <hvriedel(a)gmail.com> wrote: Hello! > > On 2017-09-07 at 18:16:39 +0200, Mario Blazevic wrote: > >> Btw, here's an old commit which updates the class diagram to this > >> effect for the report: > >> > >> https://github.com/hvr/haskell-report/commit/ > >> 339ea257ee8b0451fbba388480566efac6ecbbd3 > >> > > Ha, I wasn't aware of that repository. > > I set up the hvr/haskell-report fork[1] shortly after I migrated and set > up the haskell/haskell-report repo back in 2015 to serve as an "updated" > inofficial Haskell201x report... > > While looking through the report it became apparent to me that more > updates may be needed, and that a new Haskell Prime committee was needed > because such an inofficial Haskell report wouldn't provide the desired > authority of a properly produced language standard, and you know the > rest... :-) > That looks farsighted for sure. > > We agreed today to move the report itself to the > > https://github.com/haskell/rfcs/ repository. > > Ok, so how does this change the procedure described at > > https://github.com/haskell/rfcs/blob/master/README.rst#succe > ssful-proposals > > ? > I think the only necessary change is to the strangely worded clause - No one is appointed responsible for actually implementing the change, in particular neither the shepherd nor the author of the proposal. I'd go with some alternative wording like - The successful proposal should include a complete delta to the text of The Haskell Report that can be automatically merged. > > And what is the intended relationship between the haskell/rfcs and the > haskell/haskell-report repos? > > > Should we move the build system around it as well? I'd say probably > > not, leave the haskell/haskell-report repository the canonical one and > > update it from haskell/rfcs/ once we're ready to publish. > > Well, depends... the build-system is a bit incomplete as it only tests > that TeX still builds, the intention was to provide a CI system which > publishes its draft aftifacts somewhere for convenient previewing. And > if I understand this correctly, you intend to have RFCs be accompanied > by deltas to the report in the same repository; and if that's the case I > think the build-system makes a lot of sense to duplicate in the > haskell/rfcs repo. > I'm not familiar with the build system, so I'll trust your judgement on this. The only reason for my earlier choice is that haskell/haskell-report sounds like a proper cannonical place for the official Haskell Report, much more so than haskell/rfcs. > If the report was written in reStructuredText we could simply use > something like the readthedocs.org service. But since it's LaTeX, we > have to do a little bit more work to publishes ("deploys" in newspeak) > .pdf drafts somewhere else, but it's doable. > I can take care to set it up, if it's clear what kind of CI/CD we want. > Is the current publishing system really that difficult? To my grizzled ears, this sounds like you're fishing for a volunteer to translate LaTeX to ReST. I'd actually be willing to do that, as I have plenty of experience with text transformations, but I'd need a buy-in from everybody. > > I wish GitHub made it possible to symlink files in two repositories > > like this. > > I wouldn't worry too much about that... we can cross that bridge when > we're close to a report worth publishing :-) > > Cheers, > HVR >

9 9