Re: [Haskell] [ANNOUNCE] GHC 9.2.4 released
Hi, > On a Mac it is still necessary to do > > xattr -rc . > > before doing > > sudo make install For 9.2.4, "xattr -rc ." is not good enough on my Mac (upgraded to v12.5 today). "sudo spctl --global-disable" is necessary, sigh. --Kazu _______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available
Hi George, > I've duplicated the issue on both of my machines. It would be good to know > if anybody else is seeing it. Kazu, I know you have seen this in the past. > Do you get the same error installing rc1? > When I run sudo make install I get a popup that says: I had no problem on 9.4.1-rc1. "xattr -rc ." and "make install" worked perfectly. macOS Monterey v12.4 Xcode 13.4.1 --Kazu ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 9.2.2 is not available
Hi George, FYI: https://twitter.com/kazu_yamamoto/status/1500643489985761282 --Kazu > Thanks Ben > > When I do an install on macos Monterey 12.2.1 (Intel) I get > > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified > > > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari wrote: > >> >> The GHC developers are very happy to at announce the availability of GHC >> >> 9.2.2. Binary distributions, source distributions, and documentation are >> >> available at downloads.haskell.org: >> >>https://downloads.haskell.org/ghc/9.2.2 >> >> This release includes many bug-fixes and other improvements to 9.2.1 >> including: >> >> * A number of bug-fixes in the new AArch64 native code generator >> >> * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is >> handled >>correctly on platforms lacking support for unaligned memory accesses >>(#21015, #20987). >> >> * Improvements to the compatibility story in GHC's migration to the >>XDG Base Directory Specification (#20684, #20669, #20660) >> >> * Restored compatibility with Windows 7 >> >> * A new `-fcompact-unwind` flag, improving compatibility with C++ >> libraries on >>Apple Darwin (#11829) >> >> * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime >> bounds >>checking of array primops (#20769) >> >> * Unboxing of unlifted types (#20663) >> >> * Numerous improvements in compiler performance. >> >> * Many, many others. See the [release notes] for a full list. >> >> As some of the fixed issues do affect correctness users are encouraged to >> >> upgrade promptly. >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous >> contributors whose on-going financial and in-kind support has >> facilitated GHC maintenance and release management over the years. >> Moreover, this release would not have been possible without the hundreds >> >> of open-source contributors whose work comprise this release. >> >> As always, do open a [ticket][] if you see anything amiss. >> >> Happy compiling, >> >> - Ben >> >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> [release notes]: >> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html >> >> ___ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: osx conundrum
Maybe you'd like to install a virtual instance of OSX and test things from clean scratch, I'd expect any routine installation of GHC should work, then add macports/homebrew etc. to bisect the culprit. Free VirtualBox should do, VMWare Fusion or Parallel Desktop can offer even smoother experience at some fees/cost. > On 2021-10-13, at 19:56, David Duke wrote: > > Thanks Steven. Looks like it might be something with my system. > I reinstalled from macports 8.10.7 > @ Carter yes I've been carefully check the compiler version on each trial. > However trying to compile a Haskell source gives the same libHSbase error > > > > ndefined symbols for architecture x86_64: > "_iconv", referenced from: > _hs_iconv in libHSbase-4.14.3.0.a(iconv.o > > > > > On Tue, Oct 12, 2021 at 2:54 AM Steven Smith <mailto:steve.t.sm...@gmail.com>> wrote: > I’m a maintainer of the MacPorts ghc port. The MacPorts installations do not > have this issue, whether installed from the buildbot binaries or compiled > from source, that all work on multiple macOS versions 10.9–11. Here’s the > build recipe: > https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile > <https://github.com/macports/macports-ports/blob/master/lang/ghc/Portfile> > > The iconv symbol issue is known, > https://gitlab.haskell.org/ghc/ghc/-/issues/18752 > <https://gitlab.haskell.org/ghc/ghc/-/issues/18752>, and packages like > MacPorts must build around it. > > This looks like something specific to your configuration. > > If you believe that there is an issue outside your system, please initiate a > trac ticket at https://trac.macports.org <https://trac.macports.org/>. > > >> On Oct 11, 2021, at 5:00 AM, David Duke > <mailto:duke.j.da...@gmail.com>> wrote: >> >> I have a conundrum on which advice would be appreciate. Does >> anyone know how to successfully install ghc on OSX >> I've tried various binary instalation routes: >> macports, brew, direct binary downloads from haskel.org <http://haskel.org/> > > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.da...@gmail.com <mailto:e%3aduke.j.da...@gmail.com> > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > <https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke>___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org <mailto:Glasgow-haskell-users@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > <http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: osx conundrum
Never met this issue myself (with currently osx 10.14.6 Mojave, and a few previous versions), I guess macports/homebrew or some other pieces aren't playing nicely with some others in your machine. Checkout https://newbedev.com/libiconv-or-iconv-undefined-symbol-on-mac-osx <https://newbedev.com/libiconv-or-iconv-undefined-symbol-on-mac-osx> maybe helpful. > On 2021-10-11, at 17:00, David Duke wrote: > > I have a conundrum on which advice would be appreciate. Does > anyone know how to successfully install ghc on OSX > I've tried various binary instalation routes: > macports, brew, direct binary downloads from haskel.org <http://haskel.org/> > All have the same result. when I try to compile a basic hello world program I > get > > Undefined symbols for architecture x86_64: > "_iconv", referenced from: > _hs_iconv in libHSbase-4.14.3.0.a(iconv.o) > (maybe you meant: _base_GHCziIOziEncodingziIconv_iconvEncoding1_closure, > _base_GHCziIOziEncodingziIconv_iconvEncoding1_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding4_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding15_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding4_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding7_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding6_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding6_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding8_info , _hs_iconv_open , > _base_GHCziIOziEncodingziIconv_iconvEncoding9_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding12_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding11_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding9_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding12_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding13_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding11_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding7_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding13_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding2_info , > _base_GHCziIOziEncodingziIconv_iconvEncoding14_bytes , > _base_GHCziIOziEncodingziIconv_iconvEncoding15_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding3_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding8_closure , > _base_GHCziIOziEncodingziIconv_iconvEncoding2_closure , _hs_iconv , > _base_GHCziIOziEncodingziIconv_iconvEncoding10_bytes , _hs_iconv_close , > _base_GHCziIOziEncodingziIconv_iconvEncoding5_closure ) > "_iconv_open", referenced from: > _hs_iconv_open in libHSbase-4.14.3.0.a(iconv.o) > (maybe you meant: _hs_iconv_open) > "_iconv_close", referenced from: > _hs_iconv_close in libHSbase-4.14.3.0.a(iconv.o) > (maybe you meant: _hs_iconv_close) > "_locale_charset", referenced from: > _localeEncoding in libHSbase-4.14.3.0.a(PrelIOUtils.o) > ld: symbol(s) not found for architecture x86_64 > > I've triedgiong through ghcup > > 8.8.4 > 8.6.5. > 8.10.2 > 8.10.7 > 9.0.1 > > all have the same problem. > I'd be happy to build from source. Small problem: what Haskell compiler do I > use? > > Any advice on installs that works along with any changes to paths to avoid > the iconv problems would be appreciated as currently my Haskell-related > activities have come to a grinding halt. Switchig to a different OS would be > nice but its not a > feasible option a at present.Writing a compiler is starting to look > attractive.. > > thanks > David > > -- > David Duke > Emeritus Professor of Computer Science > School of Computing University of Leeds UK > E:duke.j.da...@gmail.com <mailto:e%3aduke.j.da...@gmail.com> > W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke > <https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke>___ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Pattern synonym constraints :: Ord a => () => ...
must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. I think that is confusing too! How about this: * ⟨CReq⟩ are the constraints required to match the pattern, in a pattern match. * ⟨CProv⟩ are the constraints made available (provided) by a successful pattern match. *and are both required when P is used as a constructor in an expression. That makes the constructor form explicit. The only mechanism for getting the constraints needed for building is by polluting the constraints needed for matching. Yes I agree that’s bad. It is acknowledge as such in the paper, and is the subject of accepted proposal #42. Simon PS: I am leaving Microsoft at the end of November 2021, at which point simo...@microsoft.com<mailto:simo...@microsoft.com> will cease to work. Use simon.peytonjo...@gmail.com<mailto:simon.peytonjo...@gmail.com> instead. (For now, it just forwards to simo...@microsoft.com.) From: Anthony Clayden Sent: 06 October 2021 11:42 To: Simon Peyton Jones Cc: Gergő Érdi ; GHC users Subject: Re: Pattern synonym constraints :: Ord a => () => ... On Wed, 6 Oct 2021 at 21:24, Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. The user manual<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.gitlab.haskell.org%2Fghc%2Fdoc%2Fusers_guide%2Fexts%2Fpattern_synonyms.html%3Fhighlight%3Dpattern%2520syn%23typing-of-pattern-synonyms=04%7C01%7Csimonpj%40microsoft.com%7C941ec01fb46743eefb4d08d988b5e64a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637691137569565464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=B7ZHX1fB5hRZkVuvId1OhnC6j5oYoqeSaD2hByBAPRM%3D=0> does already speak about the type of a builder, here: ... How could we make that clearer? This point in that section of the Guide is wrong/misleading: · ⟨CReq⟩ are the constraints required to match the pattern. must be the union of the constraints required to match the pattern, _plus_ required to build with the pattern -- if it is bidirectional. Then thank you Simon, but it's the type of the _matcher_ that's problematic. The only mechanism for getting the constraints needed for building is by polluting the constraints needed for matching. Here's a (crude, daft) example, using guards to 'raise' a required-for-failing-to-build that isn't required-for-successful-building nor for-matching >pattern TwoNode :: (Show a, Ord a) => () => a -> a -> Tree a > -- GHC insists on both constraints as Req'd > >pattern TwoNode x y <- Node Empty x (Leaf y) where > TwoNode x y | x > y = Node Empty x (Leaf y) > | otherwise = error (show x ++ " not greater " ++ show y) To quote you from May 1999 >But when you take a constructor *apart*, the invariant must hold >by construction: you couldn't have built the thing you are taking >apart unless invariant held. So enforcing the invariant again is >redundant; and in addition it pollutes the type of selectors. `Show a` must have "held by construction" of the `Node`. But the PatSyn's constraints are requiring more than that was true in some distant line of code: it wants evidence in the form of a dictionary at the point of deconstructing; since the build was successful, I ipso facto don't want to `show` anything in consuming it. An `instance Foldable Tree` has no mechanism to pass in any such dictionaries (which'll anyway be redundant, as you say). ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Pattern synonym constraints :: Ord a => () => ...
Perhaps I'm just stupid, and should be disqualified from using such features. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. You are not stupid. And since you misunderstood despite effort, the presentation is - by definition - not as good as it should be. The paper focuses pretty much entirely on matching, and takes building for granted. But I can now see that it is not explicit on this point, and that leaves it open to misinterpretation. I think the paper is reasonably careful to say "match on" rather than "use", but I wouldn't bet on it. I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. The user manual<https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pattern_synonyms.html?highlight=pattern%20syn#typing-of-pattern-synonyms> does already speak about the type of a builder, here: * For a bidirectional pattern synonym, a use of the pattern synonym as an expression has the type (CReq, CProv) => t1 -> t2 -> ... -> tN -> t So in the previous example, when used in an expression, ExNumPat has type ExNumPat :: (Num a, Eq a, Show b) => b -> T t Notice that this is a tiny bit more restrictive than the expression MkT 42 x which would not require (Eq a). That does seem to directly address the use of a pattern synonym in an expression, and means that both CReq and Cprov are required at use sites in expressions. It even includes an example of the sort you wanted. How could we make that clearer? Thanks Simon PS: I am leaving Microsoft at the end of November 2021, at which point simo...@microsoft.com<mailto:simo...@microsoft.com> will cease to work. Use simon.peytonjo...@gmail.com<mailto:simon.peytonjo...@gmail.com> instead. (For now, it just forwards to simo...@microsoft.com.) From: Glasgow-haskell-users On Behalf Of Anthony Clayden Sent: 06 October 2021 06:25 To: Gergő Érdi Cc: GHC users Subject: Re: Pattern synonym constraints :: Ord a => () => ... Thanks Gergö, I've read that paper many times (and the User Guide). Nowhere does it make the distinction between required-for-building vs required-for-matching. And since most of the syntax for PatSyns (the `where` equations) is taken up with building, I'd taken it that "required" means required-for-building. There is one paragraph towards the end of section 6 that kinda hints at the issue here. It's so cryptic it's no help. "An alternative would be to carry two types for each pattern synonym: ...". But already PatSyns carry two sets of _constraints_. The matrix type after the constraints is determined by the mapping to/from the data constructor. Why would there be two of those? What this paragraph might mean (?) is 'carry three sets of constraints', but put one set in a completely different signature. As per the proposal. > they [Required constraints] are "required" to be able to use the pattern > synonym. Is highly misleading. Only as a result of this thread (not from the User Guide nor from the paper) do I discover "use" means match-on. The paper really does not address typing for "use" for building. I agree with SPJ's comment (quoted in the proposal) "This turns out to be wrong in both directions." I suggest the User Guide needs an example where a constraint needed for matching (presumably via a View pattern) is not amongst the constraints carried inside the data constructor, nor amongst those needed for building. Then the limitations in the current design would be more apparent for users. Perhaps I'm just stupid, and should be disqualified from using such features. (I keep away from GADTs for those reasons.) So I'm not going to volunteer to revise the User Guide further. On Wed, 6 Oct 2021 at 15:26, Gergő Érdi mailto:ge...@erdi.hu>> wrote: If you haven't yet, it is probably a good idea to read section 6 of https://gergo.erdi.hu/papers/patsyns/2016-hs-patsyns-ext.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgergo.erdi.hu%2Fpapers%2Fpatsyns%2F2016-hs-patsyns-ext.pdf=04%7C01%7Csimonpj%40microsoft.com%7Cf208f3e0240646a9829f08d98889d751%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637690948080937568%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=YhqSQ%2BWSfz5Ycmt8aynh9jJaUVNiiK3kkPrLj1pILx4%3D=0> On Wed, Oct 6, 2021 at 10:23 AM Gergő Érdi mailto:ge...@erdi.hu>> wrote: > > > I'm afraid none of this is apparent from the User Guide -- and I even > > contributed some material to the Guide, without ever understanding that. > > Be
RE: -dinline-check for symbolic names?
| First, reading the ghc source code suggests I can only have one -ddinline- | check. Correct? Yes. The last one wins. This should be in the user manual. Would anyone like to offer a PR? | Also, I'm guessing that the inlining I didn't see reported by -dinline-check | happened inside the simplifier pass inserted by the ConCat plugin. (And | hence INLINE [0] moved it out of that pass.) Is it possible that the flag | isn't getting propagated there? I don't see how that could happen, but I only have a vague idea of what is going on. Simon | -Original Message- | From: Michael Sperber | Sent: 18 August 2021 14:14 | To: Simon Peyton Jones | Cc: glasgow-haskell-users@haskell.org | Subject: Re: -dinline-check for symbolic names? | | | On Tue, Aug 10 2021, Simon Peyton Jones wrote: | | > It's hard to tell what is happening without a repro case. Can you share | one? | | Haven't been able to do that with <10MB of output, I'm afraid ... | | > You suggested that it might have something to do with using an | > operator. Does the same thing happen if you replace the operator with | > an alpha-numeric name? | | I've now concluded several things are coming together. As things started | working with INLINE [0] instead of INLINE, it's not the symbolic name. | | First, reading the ghc source code suggests I can only have one -ddinline- | check. Correct? | | Also, I'm guessing that the inlining I didn't see reported by -dinline-check | happened inside the simplifier pass inserted by the ConCat plugin. (And | hence INLINE [0] moved it out of that pass.) Is it possible that the flag | isn't getting propagated there? | | (Sorry for being vague - if you don't know offhand, it's not worth digging | without more info from me.) | | -- | Regards, | Mike _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Avoiding construction of dead dictionaries
Hi Mike Repro case is something like * Here is a source or files * Compile like this * Look at the generated Core...observe silly thing happening Evidence of importance could be as simple as "in my application I'm seeing a lot of these redundant dictionaries being built for no reason". Or, stronger "this is slowing my application down by 5%". TL;DR: is this just a curiosity that you noticed, or is it something that matters to you, and if so why? | Is there any way to see how far evaluates the dictionary construction to be | able to match on that unboxed tuple? Not sure what you mean here, but once we have a repro case we can discuss. Worth opening a ticket too -- email is easily lost. Thanks Simon | -Original Message- | From: Michael Sperber | Sent: 12 August 2021 10:15 | To: Simon Peyton Jones | Cc: Sebastian Graf ; glasgow-haskell-users@haskell.org | Subject: Re: Avoiding construction of dead dictionaries | | | On Mon, Aug 09 2021, Simon Peyton Jones wrote: | | > Could you offer a small repro case, with a pointer to evidence that it | matters in practice, and open a ticket? | | I'll try my best, but I'm unsure how I would generate evidence. Could you | give me a hint? | | Is there any way to see how far evaluates the dictionary construction to be | able to match on that unboxed tuple? | | -- | Regards, | Mike ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: InstanceSigs -- rationale for the "must be more polymorphic than"
Do you have a concrete example? I think that the recursive calls will all go via the original class method with its original type - we can't know that it's calling *this* instance till much later. So I still don't get it. An example would clear it up. Simon From: David Feuer Sent: 10 August 2021 12:01 To: Simon Peyton Jones Cc: Anthony Clayden ; GHC users Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than" Simon, there are times when a function has to be generalized to be made polymorphic recursive. Perhaps the method takes an argument of type x (not a class parameter), but to call itself, it needs to be able to take types x, T x, T (T x), etc. That additional polymorphism can be introduced in the instance signature. The alternative is to introduce a helper function with extra polymorphism. On Tue, Aug 10, 2021, 5:15 AM Simon Peyton Jones mailto:simo...@microsoft.com>> wrote: AntC, I think you see why the instance sig must be at least as polymorphic than the instantiated signature from the class - because that's what the client is going to expect. We are building a record of functions, and they must conform to the class signature. I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of which I quite understand. There is no compelling reason to make the instance signature more polymorphic - that is, doing so does not increase expressiveness. But it might make a briefer, more comprehensible type for the reader. The only alternative would be to insist that the two types are the same, a completely redundant test, but one you might conceivably want on stylistic grounds. All in all, no big deal. Instance signature are a convenience, never a necessity. If you would like to offer a patch for the user manual to explain this better, that would be great. Simon From: Glasgow-haskell-users mailto:glasgow-haskell-users-boun...@haskell.org>> On Behalf Of David Feuer Sent: 08 August 2021 09:37 To: Anthony Clayden mailto:anthony.d.clay...@gmail.com>> Cc: GHC users mailto:glasgow-haskell-users@haskell.org>> Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than" To the best of my knowledge, `InstanceSigs` are never strictly necessary. They can, however, be useful for at least four purposes: 1. To provide a compiler-checked reminder of the type. 2. To bind type variables with `ScopedTypeVariables`. 3. To generalize the type so you can use polymorphic recursion. 4. To enhance parametricitry/polymorphism for internal documentation purposes. The third reason is probably the main technical one to allow a more general signature, but the fourth is likely helpful too. On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden mailto:anthony.d.clay...@gmail.com>> wrote: I can't help but feel InstanceSigs are either superfluous or upside-down. It's this bit in the User Guide: > The type signature in the instance declaration must be > more polymorphic than (or the same as) the one in the class declaration, > instantiated with the instance type. Usually if you give a signature, it must be _less_ polymorphic (or the same as) the type inferred from the term: >lessPolyPlus :: Integral a => a -> a -> a >lessPolyPlus x y = x + y Or >lessPolyPlus (x :: a) y = x + y :: Integral a => a The examples in the User Guide aren't helping: you could just drop the InstanceSigs, and all is well-typed. (Even the example alleging to use -XScopedTypeVariables in a where sub-decl: you could just put random `xs :: [b]` without scoping `b`.) Dropping the Sigs altogether works because the type from the class decl, suitably instantiated, is less polymorphic than inferred from the term. IOW the suitably instantiated type restricts what would otherwise be inferred. Situation normal. I suppose it might be helpful to give an explicit InstanceSig as 'belt and braces' for the instantiated -- possibly because the instantiation is hard to figure out; possibly because you want to use -XScopedTypeVariables within a where-bound sub-decl, as an extra piece of string. I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably instantiated. But the docos don't give any example where it's essential to provide an InstanceSig _and_ make it strictly more polymorphic. Here all the sigs and annotations are just superfluous: >maxPolyPlus :: Num a => a -> a -> a >maxPolyPlus = (+) > >class C a where foo :: a -> T a >instance Integral a => C a where > foo :: Num a => a -> T a > foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a) Is there a persuasive example (to put in the User Guide)? AntC ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org> ht
RE: -dinline-check for symbolic names?
It's hard to tell what is happening without a repro case. Can you share one? You suggested that it might have something to do with using an operator. Does the same thing happen if you replace the operator with an alpha-numeric name? Simon | -Original Message- | From: Glasgow-haskell-users | On Behalf Of Michael Sperber | Sent: 06 August 2021 13:44 | To: glasgow-haskell-users@haskell.org | Subject: Re: -dinline-check for symbolic names? | | [You don't often get email from sper...@deinprogramm.de. Learn why this | is important at http://aka.ms/LearnAboutSenderIdentification.] | | On Fri, Aug 06 2021, Michael Sperber wrote: | | > On Wed, Aug 04 2021, Carter Schonwald | wrote: | > | >> I'm not sure about the pragma debugging, but are you using it in | >> point free style? Cause I'm that case it may not be inclined because | >> it's not being fully applied on the left hand side? | > | > Good point, but I checked, and it's fully applied. :-( | | Another note: Once I change the INLINE to INLINE [0], everything works: | (&&&) gets inlined, and -dinline-check works. Explanation welcome ... | | -- | Regards, | Mike | | ___________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell- | usersdata=04%7C01%7Csimonpj%40microsoft.com%7C7b8c76634e3c4ce86a7008 | d958d801ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63763850704993823 | 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C3000sdata=DZHraN9nVbZMWxmekmYP2sAqRBh1qNbVWUlo | JQdKnkc%3Dreserved=0 _______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: InstanceSigs -- rationale for the "must be more polymorphic than"
AntC, I think you see why the instance sig must be at least as polymorphic than the instantiated signature from the class - because that's what the client is going to expect. We are building a record of functions, and they must conform to the class signature. I agree with David's (1) and (2) reasons, but not with (3) or (4), neither of which I quite understand. There is no compelling reason to make the instance signature more polymorphic - that is, doing so does not increase expressiveness. But it might make a briefer, more comprehensible type for the reader. The only alternative would be to insist that the two types are the same, a completely redundant test, but one you might conceivably want on stylistic grounds. All in all, no big deal. Instance signature are a convenience, never a necessity. If you would like to offer a patch for the user manual to explain this better, that would be great. Simon From: Glasgow-haskell-users On Behalf Of David Feuer Sent: 08 August 2021 09:37 To: Anthony Clayden Cc: GHC users Subject: Re: InstanceSigs -- rationale for the "must be more polymorphic than" To the best of my knowledge, `InstanceSigs` are never strictly necessary. They can, however, be useful for at least four purposes: 1. To provide a compiler-checked reminder of the type. 2. To bind type variables with `ScopedTypeVariables`. 3. To generalize the type so you can use polymorphic recursion. 4. To enhance parametricitry/polymorphism for internal documentation purposes. The third reason is probably the main technical one to allow a more general signature, but the fourth is likely helpful too. On Sun, Aug 8, 2021, 3:04 AM Anthony Clayden mailto:anthony.d.clay...@gmail.com>> wrote: I can't help but feel InstanceSigs are either superfluous or upside-down. It's this bit in the User Guide: > The type signature in the instance declaration must be > more polymorphic than (or the same as) the one in the class declaration, > instantiated with the instance type. Usually if you give a signature, it must be _less_ polymorphic (or the same as) the type inferred from the term: >lessPolyPlus :: Integral a => a -> a -> a >lessPolyPlus x y = x + y Or >lessPolyPlus (x :: a) y = x + y :: Integral a => a The examples in the User Guide aren't helping: you could just drop the InstanceSigs, and all is well-typed. (Even the example alleging to use -XScopedTypeVariables in a where sub-decl: you could just put random `xs :: [b]` without scoping `b`.) Dropping the Sigs altogether works because the type from the class decl, suitably instantiated, is less polymorphic than inferred from the term. IOW the suitably instantiated type restricts what would otherwise be inferred. Situation normal. I suppose it might be helpful to give an explicit InstanceSig as 'belt and braces' for the instantiated -- possibly because the instantiation is hard to figure out; possibly because you want to use -XScopedTypeVariables within a where-bound sub-decl, as an extra piece of string. I can see you mustn't make the InstanceSig _less_ polymorphic than the suitably instantiated. But the docos don't give any example where it's essential to provide an InstanceSig _and_ make it strictly more polymorphic. Here all the sigs and annotations are just superfluous: >maxPolyPlus :: Num a => a -> a -> a >maxPolyPlus = (+) > >class C a where foo :: a -> T a >instance Integral a => C a where > foo :: Num a => a -> T a > foo (x :: a) = MkT (maxPolyPlus x x :: Num a => a) Is there a persuasive example (to put in the User Guide)? AntC _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users=04%7C01%7Csimonpj%40microsoft.com%7C51928cea45a84d24d62508d95a47ba3c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640086425578886%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=qY9jOKGv3RIFPCuVT%2FZIBfaBBofcm6p7PG3yfq%2FJRiM%3D=0> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Avoiding construction of dead dictionaries
Hi Mike
| The right-hand argument of <+ leads to a dictionary construction that is a
| proof of a certain property, but the dictionary itself ends up being dead,
| like so:
|
|case $w$dOpCon_r2kGJ ...
|of
|{ (# ww1_s27L3 #) -> ... }
| ^
| never used
GHC needs to figure out that $w$dOpCon_r2kGJ always terminates, without
throwing an exception etc. That can't be too hard, and Sebastian Graf has
thought about it quite a bit.
Could you offer a small repro case, with a pointer to evidence that it matters
in practice, and open a ticket?
Thanks
Simon
| -Original Message-
| From: Glasgow-haskell-users On
| Behalf Of Michael Sperber
| Sent: 06 August 2021 14:06
| To: glasgow-haskell-users@haskell.org
| Subject: Avoiding construction of dead dictionaries
|
| [You don't often get email from sper...@deinprogramm.de. Learn why this is
| important at http://aka.ms/LearnAboutSenderIdentification.]
|
| I have another optimization problem. ConCat includes this definition:
|
| (<+) :: Con a => (Con b => r) -> (a |- b) -> r r <+ Entail (Sub Dict) = r
|
| The right-hand argument of <+ leads to a dictionary construction that is a
| proof of a certain property, but the dictionary itself ends up being dead,
| like so:
|
|case $w$dOpCon_r2kGJ ...
|of
|{ (# ww1_s27L3 #) -> ... }
| ^
| never used
|
| Yet, ghc (8.10.4) never elides this code. (I'm naively assuming because of
| the unboxed tuple, but actually have no clue.)
|
| Is there any chance of convincing ghc of erasing the dictionary
| construction?
|
| Help would be much appreciated!
|
| --
| Regards,
| Mike
|
| ___________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel
| l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| usersdata=04%7C01%7Csimonpj%40microsoft.com%7C301c6f15cc1142fc645908d95
| 8dc725a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637638526127543532%7CUn
| known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
| VCI6Mn0%3D%7C2000sdata=fh2YiJ5NuDMPzpzzxsAL0MyceMFH0MuveNgvTo7ZNow%3D
| mp;reserved=0
___________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Avoiding construction of dead dictionaries
> . So apparently it is possible for a dictionary to be bottom somehow. That should not happen. Except in the case of single-method dictionaries like class C a where op :: a -> a In these cases the "dictionary" is represented by a newtype, like this newtype C a = MkC (a->a) Then you could say instance C Int where op = bottom and now a (C Int) dictionary is simply bottom. It would be easy to change this decision, and use a data constructor even for single-method classes. Some programs would become slightly less efficient, but things would be a bit more uniform. If there was a real advantage to doing this, it'd definitely be worth measuring the perf cost (if any). Simon From: Glasgow-haskell-users On Behalf Of Brandon Allbery Sent: 09 August 2021 16:32 To: Tom Smeding Cc: GHC users ; sper...@deinprogramm.de Subject: Re: Avoiding construction of dead dictionaries We haven't figured out what they did, but the other day we had someone in #haskell with an infinite loop evaluating a dictionary. So apparently it is possible for a dictionary to be bottom somehow. On Mon, Aug 9, 2021 at 11:27 AM Tom Smeding mailto:x...@tomsmeding.com>> wrote: Hi Mike, > But wouldn't that imply that ghc can build dictionary-construction code > that evaluates to bottom? Can that happen? I assume no, but here the dictionary is embedded as a field in the GADT, right? So if the data value is bottom, there is not even a dictionary to be found, let alone not-bottom. This assumes that the Dict in `Entail (Sub Dict)` is a GADT like Dict :: Con b => Dict something where the Con dictionary is contained in the GADT. Remember that in Core, dictionaries are values, and there is no difference between => and ->. - Tom Original Message On 9 Aug 2021, 15:24, Michael Sperber < sper...@deinprogramm.de<mailto:sper...@deinprogramm.de>> wrote: Thanks for thinking about this one! On Fri, Aug 06 2021, Tom Smeding mailto:x...@tomsmeding.com>> wrote: > Would it not be unsound for ghc to elide dictionary construction here? > After all, the right-hand side might actually be a bottom > (e.g. undefined) at run-time, in which case the pattern match cannot > succeed according to the semantics of Haskell. But wouldn't that imply that ghc can build dictionary-construction code that evaluates to bottom? Can that happen? > I suspect that if you make the pattern match lazy (i.e. ~(Entail (Sub > Dict))) or ignore the argument altogether (i.e. _), dictionary > construction will be elided. Thanks for the hint! ghc gives me this unfortunately, implying that it agreed with your first comment: src/ConCat/Category.hs:190:29: error: * Could not deduce: Con b arising from a use of 'r' from the context: Con a bound by the type signature for: (<+) :: forall a b r. Con a => (Con b => r) -> (a |- b) -> r at src/ConCat/Category.hs:189:1-46 * In the expression: r In an equation for '<+': r <+ ~(Entail (Sub Dict)) = r * Relevant bindings include r :: Con b => r (bound at src/ConCat/Category.hs:190:1) (<+) :: (Con b => r) -> (a |- b) -> r (bound at src/ConCat/Category.hs:190:3) | 190 | r <+ ~(Entail (Sub Dict)) = r | ^ Other ideas welcome! -- Regards, Mike ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users=04%7C01%7Csimonpj%40microsoft.com%7C7bf3769704884ed6592e08d95b4aeb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641199636853840%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=ix06XQPvpu%2B1PLzoc5rRQM6cMv8yPF6o87uVwD0sUwQ%3D=0> ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users=04%7C01%7Csimonpj%40microsoft.com%7C7bf3769704884ed6592e08d95b4aeb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637641199636863837%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=sQDTBnklNv7YLRvhiY5CEtbZgcZT8p7RR%2Bw57sCqFJk%3D=0> -- brandon s allbery kf8nh allber...@gmail.com<mailto:allber...@gmail.com> ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Does newByteArray clear?
David Feuer wrote: > I'm looking to play around with an array-based structure with > sub-linear worst-case bounds. Array is pretty awkward in that context > because creating a new one takes O(n) time to initialize it. Is that > all true of newByteArray, or can I get one with arbitrary garbage in it > for cheap? newByteArray# does not actively clear memory. However, for large arrays, I think the memory is likely to be freshly allocated from the OS, and the OS will have cleared it for security reasons. Cheers, Bertram _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: What does freezing an array really do?
David Feuer wrote:
> I know that a frozen array doesn't have to be searched for elements in
> a younger generation, but how does it differ from an unfrozen array
> that hasn't been mutated since the last collection?
Frozen arrays are not put on the mutable list once they're clean
(meaning they have no references to younger generations). Thawed
arrays are always on the mutable list.
Cheers,
Bertram
You can crash a program by updating a clean frozen array in the old
generation, then doing a minor GC, and then accessing the updated
entry:
import Data.Array
import Data.Array.Base (unsafeFreezeIOArray, unsafeThawIOArray)
import Data.Array.IO
import Data.Array.Unsafe
import System.Mem
import Control.Monad (forM_)
main = do
arr <- newArray (0, 1024) 42 :: IO (IOArray Int Int)
-- `arr` points to a MUT_ARR_PTRS closure
arr' <- unsafeFreezeIOArray arr :: IO (Array Int Int)
-- unsafeFreezeIOArray changes the closure type to
-- MUT_ARR_PTRS_FROZEN_DIRTY
performMajorGC
-- the first major GC changes it to MUT_ARR_PTRS_FROZEN
performMajorGC
-- the second GC kicks it off the mutable list??
-- unsafeThaw would change the closure type to MUT_ARR_PTRS_DIRTY
-- *and* put the array on the mutable list.
-- _ <- unsafeThawIOArray arr'
-- in contrast, `writeArray` changes the closure type to
-- MUT_ARR_PTRS_DIRTY but does not touch the `mutable list`
forM_ [0..1023] $ \i -> do
writeArray arr i $ f i
print $ sum [1..100]
-- Evaluating the sum produces a lot of garbage, and the minor GCs
-- will not scan the array.
arr' <- unsafeFreezeIOArray arr :: IO (Array Int Int)
print $ arr' ! 0
print $ arr' ! 1
-- so these array entries have a good chance to point to utter garbage.
{-# NOINLINE f #-}
f x = x*x
{-
> ghc -O0 Crash.hs && ./Crash
[1 of 1] Compiling Main ( Crash.hs, Crash.o )
Linking Crash ...
Crash: internal error: evacuate: strange closure type 29041
(GHC version 8.6.5 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
> ghc -O1 Crash.hs && ./Crash
[1 of 1] Compiling Main ( Crash.hs, Crash.o )
Linking Crash ...
5050
482299980870
Segmentation fault (core dumped)
> ghc -O2 Crash.hs && ./Crash
[1 of 1] Compiling Main ( Crash.hs, Crash.o ) [Optimisation flags
changed]
Linking Crash ...
5050
482299980870
Segmentation fault (core dumped)
-}
_______________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: exhausted simplifier ticks and hs-boot files
Ganesh
It's an old bug that has somehow reappeared.
I opened https://gitlab.haskell.org/ghc/ghc/issues/17140
But it seems OK in HEAD, and hence probably in GHC 8.8. Can you try?
Maybe put further comments on the issue tracker, rather than here.
thanks
Simon
| -Original Message-
| From: Glasgow-haskell-users On
| Behalf Of Ganesh Sittampalam
| Sent: 05 August 2019 14:02
| To: glasgow-haskell-users@haskell.org
| Subject: exhausted simplifier ticks and hs-boot files
|
| Hi,
|
| The code below (also attached - unzip and run go.sh) triggers the GHC
| panic "Simplifier ticks exhausted", and I'm unsure whether I should view
| it as an instance of the known infelicity in the inliner
| (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html
| #bugs-ghc)
|
| My code does have a recursive datatype, but the recursion isn't
| contravariant, which is the case described in "Secrets of the GHC inliner"
| (https://www.microsoft.com/en-us/research/wp-
| content/uploads/2002/07/inline.pdf,
| section 4).
|
| It's cut down from some real code where I have a mutually recursive
| datatype that I want to define across two modules for code structuring
| reasons, meaning I need a .hs-boot file. I haven't been able to reproduce
| it without the .hs-boot file - if I put everything in one module it stops
| happening.
|
| I've tried with a range of GHC versions from 8.2.x to an early version of
| 8.8. It happens with -O1 and not -O0, but I haven't managed to find a
| specific optimisation that triggers it.
|
| Is this just an instance of the known problem in a different guise, or is
| it something different and worth a bug report?
|
| Cheers,
|
| Ganesh
|
| T2.hs-boot
| ---
| module T2 where
|
| data T2
|
| mapP_T2 :: (Int -> Int) -> T2 -> T2
|
| T1.hs
| -
| module T1 where
|
| import {-# SOURCE #-} T2
|
| data T1 = T1 T2
|
| mapP_T1 :: (Int -> Int) -> T1 -> T1
| mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs)
|
| T2.hs
| -
|
| module T2 where
|
| import T1
|
| data T2 = T2 T1
|
| mapP_T2 :: (Int -> Int) -> T2 -> T2
| mapP_T2 f (T2 t) = T2 (mapP_T1 f t)
|
| go :: T1 -> T1
| go = mapP_T1 id
|
| GHC output
| --
| $ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...]
| ghc.exe: panic! (the 'impossible' happened)
| (GHC version 8.2.2 for x86_64-unknown-mingw32):
| Simplifier ticks exhausted
| When trying UnfoldingDone mapP_T2
| To increase the limit, use -fsimpl-tick-factor=N (default 100)
| If you need to do this, let GHC HQ know, and what factor you needed
| Total ticks: 61203
|
| 24481 PreInlineUnconditionally
| 6121 ds_i17h
| 6120 f_a16p
| 6120 ds_d17d
| 6120 ds1_i17i
| 12241 UnfoldingDone
| 6121 mapP_T1
| 6120 mapP_T2
| 24481 BetaReduction
| 6121 ds_i17h
| 6120 f_a16p
| 6120 ds_d17d
| 6120 ds1_i17i
_______________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Equality constraints (~): type-theory behind them
I'd far rather see GHC's implementation of FunDeps made more coherent (and learning from Hugs) than squeezing it into the straitjacket of System FC and thereby lose expressivity. To call System FC a straitjacket is to suggest that there is a straightforward alternative that would serve the purpose better – let’s take off the straitjacket! I’m all for that, but then we do need to describe what the new alternative is, at a comparable level of precision. For better or worse, GHC uses FC as a statically-typed intermediate language. Vanishingly few compilers do this; almost all use an untyped intermediate language. With an untyped IR, all you need do is typecheck the source program, and then you are done with typechecking --- provided that all the subsequent transformations and optimisations are sound. But with a statically typed IR, we have to ensure that every transformation produces a program that is itself well-typed; and that in turn pretty much rules out complicated inference algorithms, because they are fragile to transformation. Instead, GHC uses a complicated inference algorithm on the (implicitly typed) source program, but under the straitjacket restriction that the type inference algorithm must also translate the program into an explicitly-typed IR. This is a choice that GHC makes. It’s a choice that I love, and one that makes GHC distinctive. But I accept that it comes with a cost. There may be an IR based on fundeps, or CHRs or something, that has similar properties to FC. It would be a great research goal to work on such a thing. That said, there may be aspects of GHC’s implementation fundeps that are unsatisfactory or argualbly just plain wrong, and which could be fixed and still translate into FC. If anyone would like to work on that, I’d be happy to help explain how the current machinery works. Simon From: Glasgow-haskell-users On Behalf Of Anthony Clayden Sent: 25 March 2019 11:50 To: GHC Users List ; Tom Schrijvers Subject: Re: Equality constraints (~): type-theory behind them > On Mon, Dec 10, 2018 at 8:36:42 AM Tom Schrijvers wrote: > Maybe our Haskell'17 paper about Elaboration on Functional Dependencies sheds > some more light on your problem: Thanks Tom, I've also been working through the 2011 expanded version of 'System F with Type Equality Coercions' that Adam suggested. I'm finding your 2017 paper's proposals not up to the job, because it doesn't consider FunDeps for Overlapping Instances; and unnecessary because the examples it's addressing can be fixed purely using FunDeps, with their semantics per the 2006 'via CHRs' paper. The chief problems with using FunDeps in GHC code is GHC doesn't follow that semantics; neither does it follow any other well-principled/documented semantics.You can get it to accept a bunch of instances then find that taken together they're not consistent and confluent, in the sense of the 'via CHRs' paper. Specifically, re the 2017's paper Challenge 1: Enforcing (essentially Trac #10675). That set of instances in the example is not valid by the 'via CHRs' rules, and should be rejected. Hugs indeed rejects that code. GHC accepts it and #10675 shows what sort of incoherence can result. I'm not seeing we need to translate to Type Families/System FC to explain it. Re Challenge 2: Elaborating (which is Trac #9627 that gives the main example for the paper). We can fix that code with an extra `~` constraint: class C a b | a -> b instance C Int Bool f :: (C Int b, b ~ Bool) => b -> Bool f x = x (Or in Hugs with a `TypeCast` instead of the `~`.) Is that extra constraint onerous? The signature already has `Bool` hard-coded as the return type, so I don't see it's any more onerous. Or put that signature as f :: (C Int b) => b -> b Which also has the effect `b` must be `Bool`. I'd far rather see GHC's implementation of FunDeps made more coherent (and learning from Hugs) than squeezing it into the straitjacket of System FC and thereby lose expressivity. AntC ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Guidelines for respectful communication
Friends As many of you will know, I have been concerned for several years about the standards of discourse in the Haskell community. I think things have improved since the period that drove me to write my Respect email<https://mail.haskell.org/pipermail/haskell/2016-September/024995.html>, but it's far from secure. We discussed this at a meeting of the GHC Steering Committee<https://github.com/ghc-proposals/ghc-proposals> at ICFP in September, and many of us have had related discussions since. Arising out of that conversation, the GHC Steering Committee has decided to adopt these Guidelines for respectful communication<https://github.com/ghc-proposals/ghc-proposals/blob/master/GRC.rst> We are not trying to impose these guidelines on members of the Haskell community generally. Rather, we are adopting them for ourselves, as a signal that we seek high standards of discourse in the Haskell community, and are willing to publicly hold ourselves to that standard, in the hope that others may choose to follow suit. We are calling them "guidelines for respectful communication" rather than a "code of conduct", because we want to encourage good communication, rather than focus on bad behaviour. Richard Stallman's recent post<https://lwn.net/Articles/769167/> about the new GNU Kind Communication Guidelines<https://gnu.org/philosophy/kind-communication.html> expresses the same idea. Meanwhile, the Stack community is taking a similar approach<https://www.snoyman.com/blog/2018/11/proposal-stack-coc>. Our guidelines are not set in stone; you can comment here<https://github.com/ghc-proposals/ghc-proposals/commit/373044b5a78519071b9a24b3681cfd1af06e57e0>. Perhaps they can evolve so that other Haskell committees (or even individuals) feel able to adopt them. The Haskell community is such a rich collection of intelligent, passionate, and committed people. Thank you -- I love you all! Simon <>_______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Summit on Advances in Programming Languages 2019
Haskellers The Summit oN Advances in Programming Languages<http://snapl.org/2017/index.html> (SNAPL) is a biennial venue for discussions about programming languages. SNAPL focuses on experience-based insight, innovation, and visionary ideas spanning from foundations to applications of programming languages. SNAPL welcome perspectives from both industry and academia. Ras Bodik and Shriram Krishnamurthi are looking for community input in where and when to hold SNAPL 2019, and how long it should be. Here is their survey<https://goo.gl/forms/pNydkzP4RwLuIa4p1>. Do consider making your views known to them. Simon _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Natural number comparisons with evidence
I see this in GHC.TypeNats sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~: b) sameNat x y | natVal x == natVal y = Just (unsafeCoerce Refl) | otherwise= Nothing The unsafeCoerce says that sameNat is part of the trusted code base. And indeed, it’s only because SNat is a private newtype (i.e its data constructor is private to GHC.TypeNats) that you can’t bogusly say(SNat 7 :: SNat 8) You want exactly the same thing, but for a comparison oriented data CompareEv, rather than its equality counterpart :~:. So the same approach seems legitimate. I always want code with unsafeCoerce to be clear about (a) why it’s necessary and (b) why it’s sound. Simon From: Glasgow-haskell-users <glasgow-haskell-users-boun...@haskell.org> On Behalf Of Conal Elliott Sent: 24 May 2018 00:39 To: glasgow-haskell-users@haskell.org Subject: Natural number comparisons with evidence When programming with GHC's type-level natural numbers and `KnownNat` constraints, how can one construct *evidence* of the result of comparisons to be used in further computations? For instance, we might define a type for augmenting the results of `compare` with evidence: > data CompareEv u v > = (u < v) => CompareLT > | (u ~ v) => CompareEQ > | (u > v) => CompareGT Then I'd like to define a comparison operation (to be used with `AllowAmbiguousTypes` and `TypeApplications`, alternatively taking proxy arguments): > compareEv :: (KnownNat m, KnownNat n) => CompareEv u v With `compareEv`, we can bring evidence into scope in `case` expressions. I don't know how to implement `compareEv`. The following attempt fails to type-check, since `compare` doesn't produce evidence (which is the motivation for `compareEv` over `compare`): > compareEv = case natVal (Proxy @ u) `compare` natVal (Proxy @ v) of > LT -> CompareLT > EQ -> CompareEQ > GT -> CompareGT Can `compareEv` be implemented in GHC Haskell? Is there already an implementation of something similar? Any other advice? Thanks, -- Conal ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Open up the issues tracker on ghc-proposals
I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) That’s a fair question. We have lots of forums, but your point is that certain sorts of discussions never get going with the right audience – you especially point to “confused beginners”. I don’t know how to engage that audience effectively, and by definition I’m the wrong person even to have a well-informed view. It’s quite a challenge because beginners tend not to be vocal, and yet they are a crucial set of Haskell users. Every Haskell user started as a beginner. The title of this thread, “Open up the issues tracker on ghc-proposals”, identifies a solution rather than a problem. Perhaps a constructive place to start would be to articulate the challenge directly, in a new thread, and invite input from others about whether it’s a problem they encounter, and what possible solutions might be? Thanks! Simon From: Glasgow-haskell-users <glasgow-haskell-users-boun...@haskell.org> On Behalf Of Anthony Clayden Sent: 03 May 2018 00:17 To: GHC users <glasgow-haskell-users@haskell.org> Cc: Joachim Breitner <m...@joachim-breitner.de> Subject: Re: Open up the issues tracker on ghc-proposals On Th, 3 May 2018 at 13:53 UTC, Joachim Breitner wrote: … > hmm, some of that sounds like it would be better suited for haskell-cafe, > StackOverflow, ... My point about "sometimes it's more of a niggle" was aimed at exactly your (Joachim's) series of proposals 'Resurrect Pattern Signatures'. The motivation is it helps "confused beginners". But those beginners won't be providing feedback on github. Instead you've got feedback from experienced users who've all said they see no point in the proposal. So the discussion has gone round and round and spun off other proposals. That whole series of discussions would be better happening somewhere else: where? David's quite correct >> Haskell-cafe might work, but it's a bit tricky to pull up all the language >> extension ideas discussed there. My impression is not many people who could help refine a pre-proposal ever take part in the cafe. Stackoverflow likewise. (I did raise a 'how do I do this?' type question there. It was David who responded, thank you. But I ended up answering it myself; and it turned out there was already a proposal on the slate.) >> My limited experience with glasgow-haskell-users is that it's where threads >> go to die. (I did try to continue one of David's threads there a few months ago.) But yes, my experience too. And that's sad because it's a wasted resource. I'm grateful to Simon for noticing this thread; but most topics I've raised on ghc-users have gone nowhere. So then I've tried pursuing them by poaching on Trac or github -- which is an abuse, I know. > Most vague ideas get better when the proposer is nudged to sit down and write > it up properly! (And some get dropped in the process, which is also good :-)). Yes exactly what I'm trying to get to happen. How/where? Here's a specific example: there's talk of baking ScopedTypeVariables into the H2020 standard. There's also people unhappy with ScopedTypeVariables as currently (I'm one, but I don't know if my reservations are the same as others'). If we don't have an alternative proposal (and preferably an experimental extension) by 2020, the committee can only go with the as currently fait accompli or continue the H2010 status quo. I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) AntC ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Open up the issues tracker on ghc-proposals
| > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. The Right Thing is surely for the main GHC proposals pave https://github.com/ghc-proposals/ghc-proposals to describe how you can up a "pre-proposal". That is, document the entire process in one, easy to find, place. Mind you, I'm unclear about the distinction between a pre-proposal and a proposal. Both are drafts that invite community discussion, prior to submitting to the committee for decision. Simon | -Original Message----- | From: Glasgow-haskell-users On Behalf Of Anthony Clayden | Sent: 02 May 2018 02:34 | To: glasgow-haskell-users@haskell.org; ghc-d...@haskell.org | Subject: Re: Open up the issues tracker on ghc-proposals | | > On May 1, 2018, at 2:24 PM, David Feuer wrote: | > | > Sometimes, a language extension idea could benefit from | some community discussion before it's ready for a formal proposal. | | Can I point out it's not only ghc developers who make proposals. I'd | rather you post this idea more widely. | | As a datapoint, I found ghc-users and the café just fine for those | discussions. | Ghc-users seems to have very low traffic/is rather wasted currently. | And I believe a lot of people pre-discuss on reddit. | For ideas that have been on the back burner for a long time, there's | often wiki pages. (For example re Quantified | Constraints.) | | > I'd like to propose that we open up the GitHub issues | tracker for ghc-proposals to serve as a place to discuss pre-proposal | ideas. Once those discussions converge on one or a few specific plans, | someone can write a proper proposal. | | I'm not against that. There gets to be a lot of cruft on some | discussions about proposals, so I'd expect we could archive it all | once a proposal is more formalised. | | AntC | | ___________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users _______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
"strange" error
Hello, I have compiled the latest veersion of ghc under OpenIndiana (Solaris) and now I am trying to compile cabal. I downloaded the source code from https://www.haskell.org/cabal/download.html and I tried to compile. I used the bootstrap.sh script bit it failed: Configuring cabal-install-2.0.0.1... Setup: Encountered missing dependencies: HTTP >=4000.1.5 && <4000.4, async >=2.0 && <3, cryptohash-sha256 ==0.11.*, hackage-security >=0.5.2.2 && <0.6, hashable >=1.0 && <2, tar >=0.5.0.3 && <0.6 Error during cabal-install bootstrap: Configuring the cabal-install package failed. The script downloaded all these packages so I tried to see why they fail: $ cd HTTP-4000.3.7 $ ls CHANGES HTTP.cabal Network test distLICENSE Setup.lhs $ runhaskell Setup configure Configuring HTTP-4000.3.7... Setup: Encountered missing dependencies: base >=4.3.0.0 && <4.11 Of course this package is already installed and this means that for some reason it cannot find it. It is quite possible that I am doing something stupid but I would like to know how can I proceed? Thanks in advance for your help/assistance. A.S. -- Apostolos Syropoulos Xanthi, Greece ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: [ANNOUNCE] GHC 8.4.1 released
Hello, I tried to compile the latest bits on OpenIndiana (the open version of Solaris) and compilation never starts because: checking target system type... i386-pc-solaris2.11 Build platform inferred as: i386-unknown-solaris2 Host platform inferred as: i386-unknown-solaris2 Target platform inferred as: i386-unknown-solaris2 Unknown OS solaris2.11 The configure script mentions Solaris... On my system I get $ uname -m i86pc $ uname -r 5.11 $ uname -s SunOS $ uname -v illumos-87446a5213 Any idea that migh help me go beyond this point? Thanks in advance! A.S. -- Apostolos Syropoulos Xanthi, Greece ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: How to highlighting subexpressions in dumped core?
I'm not keen on adding more Tick complexity -- it's a bit out of hand already, and all transformations must "do the right thing". AnnExpr adds an annotation at every node. You could, I guess use that to annotate -- but then you'd need a pretty printer for it so you'd end up with duplication. Worth looking at #8809 and related tickets S | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Joachim Breitner | Sent: 06 March 2018 15:27 | To: GHC users <glasgow-haskell-users@haskell.org> | Subject: How to highlighting subexpressions in dumped core? | | Hi, | | one of my plugins dumps core output to the user, and this core output | contains “interesting subexpressions”. I would like to highlight them | (for example, with `bold :: SDoc -> SDoc`). | | As far as I can see, I have these options: | | * I copy all, or most of PprCore, and extend ppr_expr to look for the |subexpressions that I care about. | |Obviously not nice, because of a code copy. | | * I extend GHC to support that. One way would be to add a new |constructor to `data Tickish id = … | Highlight` so that |I can wrap the interesting subexpressions in |`Tick Highlight e`. | |That’s a bit better, and could even be useful in GHC (e.g. a linter |error could highlight the lint error location), but it’d mean |waiting for new compiler versions until I can make use of that, |and it is still limited to subexpressions – highlighting a binder |would require yet another support. | | * Could we extend SDoc with an operation | | highlightIn :: SDoc -> SDoc -> SDoc | |or | | highlightIn :: Doc -> Doc -> Doc | |where `highlightIn doc1 doc2` is like doc2, but any subdocument that |is “ismorphic to doc1” (for whatever that means) gets highlighted? | | | Are there other options that I might not see right now? | | | | Cheers, | Joachim | | -- | Joachim Breitner | m...@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joach | im- | breitner.de%2F=04%7C01%7Csimonpj%40microsoft.com%7Cd3680548aafa49c82 | 7e708d58376c5e7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636559468531 | 359492%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi | I6Ik1haWwifQ%3D%3D%7C- | 2=VodWxNvTtF4Asflj%2FeC7%2FbQy0FExq2zq53hvtWoF98s%3D=0 ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Why is EvTerm limited?
| What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? This has come up before. I think that'd be a solid win. In fact, eliminate all the existing evidence constructors with "smart constructors" that produce an EvExpr. That'd mean moving stuff from the desugarer into these smart constructors, but that's ok. I /think/ I didn't do that initially only because there were very few forms and it mean that there was no CoreExpr stuff in the type checker. But as we add more forms that decision looks and less good. You'd need to add zonkCoreExpr in place of zonkEvTerm. evVarsOfTerm is called quite a bit; you might want to cache the result in the EvExpr constructor. Make a ticket and execute? Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Joachim Breitner | Sent: 19 January 2018 14:01 | To: Glasgow-Haskell-Users users <glasgow-haskell-users@haskell.org> | Subject: Why is EvTerm limited? | | Hi, | | I had some funky idea where a type checker plugin would have to | synthesize code for a custom-solved instances on the fly. But it seems | that does not work because EvTerm is less expressive than Core | (especially, no lambdas): | https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa | ds.haskell.org%2F~ghc%2F8.2.2%2Fdocs%2Fhtml%2Flibraries%2Fghc- | 8.2.2%2FTcEvidence.html%23t:EvTerm=02%7C01%7Csimonpj%40microsoft. | com%7C513ff7ae83914913225008d55f452dec%7C72f988bf86f141af91ab2d7cd011d | b47%7C1%7C0%7C636519673089385423=kFkUugVn02Nfu4QXJ6dkVwtx8KWFrTM | fWcVEiwf6KyI%3D=0 | | What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? | | Cheers, | Joachim | | -- | Joachim “nomeata” Breitner |m...@joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j | oachim- | breitner.de%2F=02%7C01%7Csimonpj%40microsoft.com%7C513ff7ae839149 | 13225008d55f452dec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636519 | 673089385423=Vh4BvbeEVUBIntKcf3XEseOzwUTx2RHPuANTY328dpM%3D | rved=0 _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: GHC rewrite rule type-checking failure
* Is it feasible for GHC to combine the constraints needed LHS and RHS to
form an applicability condition?
I don’t think so.
Remember that a rewrite rule literally rewrites LHS to RHS. It does not
conjure up any new dictionaries out of thin air. In your example, (D k b) is
needed in the result of the rewrite. Where can it come from? Only from
something matched on the left.
So GHC treats any dictionaries matched on the left as “givens” and tries to
solve the ones matched on the left. If it fails you get the sort of error you
see.
One way to see this is to write out the rewrite rule you want, complete with
all its dictionary arguments. Can you do that?
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 03 October 2017 01:03
To: Joachim Breitner <m...@joachim-breitner.de>
Cc: glasgow-haskell-users@haskell.org
Subject: Re: GHC rewrite rule type-checking failure
Thanks very much for the reply, Joachim.
Oops! I flubbed the example. I really `morph` to distribute over an application
of `comp`. New code below (and attached). You're right that I wouldn't want to
restrict the type of `morph`, since each `morph` *rule* imposes its own
restrictions.
My questions:
* Is it feasible for GHC to combine the constraints needed LHS and RHS to
form an applicability condition?
* Is there any way I can make the needed constraints explicit in my rewrite
rules?
* Are there any other work-arounds that would enable writing such
RHS-constrained rules?
Regards, -- Conal
``` haskell
{-# OPTIONS_GHC -Wall #-}
-- Demonstrate a type checking failure with rewrite rules
module RuleFail where
class C k where comp' :: k b c -> k a b -> k a c
instance C (->) where comp' = (.)
-- Late-inlining version to enable rewriting.
comp :: C k => k b c -> k a b -> k a c
comp = comp'
{-# INLINE [0] comp #-}
morph :: (a -> b) -> k a b
morph = error "morph: undefined"
{-# RULES "morph/(.)" forall f g. morph (g `comp` f) = morph g `comp` morph f
#-}
-- • Could not deduce (C k) arising from a use of ‘comp’
-- from the context: C (->)
-- bound by the RULE "morph/(.)"
```
On Mon, Oct 2, 2017 at 3:52 PM, Joachim Breitner
<m...@joachim-breitner.de<mailto:m...@joachim-breitner.de>> wrote:
Hi Conal,
The difference is that the LHS of the first rule is mentions the `C k`
constraint (probably unintentionally):
*RuleFail> :t morph comp
morph comp :: C k => k1 (k b c) (k a b -> k a c)
but the LHS of the second rule side does not:
*RuleFail> :t morph addC
morph addC :: Num b => k (b, b) b
A work-around is to add the constraint to `morph`:
morph :: D k b => (a -> b) -> k a b
morph = error "morph: undefined"
but I fear that this work-around is not acceptable to you.
Joachim
Am Montag, den 02.10.2017, 14:25 -0700 schrieb Conal Elliott:
> -- Demonstrate a type checking failure with rewrite rules
>
> module RuleFail where
>
> class C k where comp' :: k b c -> k a b -> k a c
>
> instance C (->) where comp' = (.)
>
> -- Late-inlining version to enable rewriting.
> comp :: C k => k b c -> k a b -> k a c
> comp = comp'
> {-# INLINE [0] comp #-}
>
> morph :: (a -> b) -> k a b
> morph = error "morph: undefined"
>
> {-# RULES "morph/(.)" morph comp = comp #-} -- Fine
> class D k a where addC' :: k (a,a) a
>
> instance Num a => D (->) a where addC' = uncurry (+)
>
> -- Late-inlining version to enable rewriting.
> addC :: D k a => k (a,a) a
> addC = addC'
> {-# INLINE [0] addC #-}
>
> {-# RULES "morph/addC" morph addC = addC #-} -- Fail
>
> -- • Could not deduce (D k b) arising from a use of ‘addC’
> -- from the context: D (->) b
>
> -- Why does GHC infer the (C k) constraint for the first rule but not (D k b)
> -- for the second rule?
>
> ___
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302=6dcqjyAYmKXKwZzQQExmWl1cJlCySmP1EvdjA03O19M%3D=0>
--
Joachim Breitner
m...@joachim-breitner.de<mailto:m...@joachim-breitner.de>
http://www.joachim-breitner.de/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F=02%7C01%7Csimonpj%40microsoft.com%7C3da5c75572694bab31aa08d509f25936%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636425858847457302=Uoe%2Bw8T3VMFLRsFY%2B8nacXIV0pUQOyCe4iHz%2FS5kGrA%3D=0>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Inhibiting the specialiser?
Did you try -fno-specialise?
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Conal Elliott
Sent: 15 September 2017 02:45
To: glasgow-haskell-users@haskell.org
Subject: Inhibiting the specialiser?
Is there a GHC flag for inhibiting the specializer (but not all optimizations)?
I'm seeing huge output from the Specialise phase killed at 4GB and growing. The
output starts as follows:
Result size of Specialise
= {terms: 29,639, types: 10,921,552, coercions: 4,425,185}
Sounds like a lot to me. Is it?. I get this behavior with -O2 and with -O.
-- Conal
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Trouble with injective type families
Functional dependencies and type-family dependencies only induce extra
"improvement" constraints, not evidence. For example
class C a b | a -> b where foo :: a -> b
instance C Bool Int where ...
f :: C Bool b => b -> Int
f x = x -- Rejected
Does the fundep on 'b' allow us to deduce (b ~ Int), GADT-like, in the body of
'f', and hence accept the definition. No, it does not. Think of the
translation into System F. We get
f = /\b \(d :: C Bool b). \(x::b). x |> ???
What evidence can I used to cast 'x' by to get it from type 'b' to Int?
Rather, fundeps resolve ambiguity. Consider
g x = foo True + x
The call to 'foo True' gives rise to a "wanted" constraint (C Bool beta), where
beta is a fresh unification variable. Then by the fundep we get an
"improvement" constraint (also "wanted") (beta ~ Int). So we can infer g :: Int
-> Int.
In your example we have
x :: forall a b. (T Int ~ b) => a
x = False
Think of the System F translation:
x = /\a b. \(d :: T Int ~ b). False |> ??
Again, what evidence can we use to cast False to 'a'.
In short, fundeps and type family dependencies only add extra unification
constraints, which may help to resolve ambiguous types. They don’t provide
evidence. That's not to say that they couldn't. But you'd need to extend
System FC, GHC's core language, to do so.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Wolfgang Jeltsch
| Sent: 05 July 2017 01:21
| To: glasgow-haskell-users@haskell.org
| Subject: Trouble with injective type families
|
| Hi!
|
| Injective type families as supported by GHC 8.0.1 do not behave like I
| would expect them to behave from my intuitive understanding.
|
| Let us consider the following example:
|
| > {-# LANGUAGE RankNTypes, TypeFamilyDependencies #-}
| >
| > class C a where
| >
| > type T a = b | b -> a
| >
| > instance C Bool where
| >
| > type T Bool = Int
| >
| > type X b = forall a . T a ~ b => a
| >
| > x :: X Int
| > x = False
|
| I would expect this code to be accepted. However, I get the following
| error message:
|
| > A.hs:14:5: error:
| > • Could not deduce: a ~ Bool
| > from the context: T a ~ Int
| > bound by the type signature for:
| > x :: T a ~ Int => a
| > at A.hs:13:1-10
| > ‘a’ is a rigid type variable bound by
| > the type signature for:
| > x :: forall a. T a ~ Int => a
| > at A.hs:11:19
| > • In the expression: False
| > In an equation for ‘x’: x = False
| > • Relevant bindings include x :: a (bound at A.hs:14:1)
|
| This is strange, since injectivity should exactly make it possible to
| deduce a ~ Bool from T a ~ Int.
|
| Another example is this:
|
| > {-# LANGUAGE GADTs, TypeFamilyDependencies #-}
| >
| > class C a where
| >
| > type T a = b | b -> a
| >
| > instance C Bool where
| >
| > type T Bool = Int
| >
| > data G b where
| >
| > G :: Eq a => a -> G (T a)
| >
| > instance Eq (G b) where
| >
| > G a1 == G a2 = a1 == a2a
|
| I would also expect this code to be accepted. However, I get the
| following error message:
|
| > B.hs:17:26: error:
| > • Could not deduce: a1 ~ a
| > from the context: (b ~ T a, Eq a)
| > bound by a pattern with constructor:
| > G :: forall a. Eq a => a -> G (T a),
| > in an equation for ‘==’
| > at B.hs:17:5-8
| > or from: (b ~ T a1, Eq a1)
| > bound by a pattern with constructor:
| > G :: forall a. Eq a => a -> G (T a),
| > in an equation for ‘==’
| > at B.hs:17:13-16
| > ‘a1’ is a rigid type variable bound by
| > a pattern with constructor: G :: forall a. Eq a => a -> G (T
| > a),
| > in an equation for ‘==’
| > at B.hs:17:13
| > ‘a’ is a rigid type variable bound by
| > a pattern with constructor: G :: forall a. Eq a => a -> G (T
| > a),
| > in an equation for ‘==’
| > at B.hs:17:5
| > • In the second argument of ‘(==)’, namely ‘a2’
| > In the expression: a1 == a2
| > In an equation for ‘==’: (G a1) == (G a2) = a1 == a2
| > • Relevant bindings include
| > a2 :: a1 (bound at B.hs:17:15)
| > a1 :: a (bound at B.hs:17:7)
|
| If b ~ T a and b ~ T a1, then T a ~ T a1 and subsequently a ~ a1, because
| of injectivity. Unfortunately, GHC does not join the two contexts (b ~ T
| a, Eq a) and (b ~ T a1, Eq a1).
|
| Are these behaviors really intended, or are these bugs s
RE: 8.2.1-rc2 upgrade report
Thanks for the report. Going from 67G to 56G allocation is a very worthwhile improvement in runtime! Hurrah. However, trebling compile time is very bad. It is (I think) far from typical: generally 8.2 is faster at compiling than 8.0 so you must be hitting something weird. Anything you can do to make a reproducible case would be helpful. -dshow-passes shows the size of each intermediate form, which at least sometimes shows where the big changes are. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Alberto Valverde Sent: 06 June 2017 12:39 To: GHC users <glasgow-haskell-users@haskell.org> Subject: 8.2.1-rc2 upgrade report Hi, I've finally managed to upgrade all the dependencies of the proprietary app I mentioned some days ago in this list and there are good and bad differences I've noticed between 8.0.2 that I'd like to share. The bad --- * An optimized cold build (-O2) is about 3 times slower (~53s vs. ~2m55s) and consumes more memory (~2Gb vs. ~7Gb) at it's peak. The good - * An un-optimized cold build (-O0) takes about the same time (~21s, phew! :) It's maybe even slightly faster with 8.2 (too few and badly taken measurements to really know, though) * The optimized executable is slightly faster and allocates less memory. For this app it makes up for the performance regression of the optimized build (which is almost always done by CI), IMHO. I did only a couple of runs and only wrote down [1] the last run results (which were similar to the previous results) so take these observations with a grain of salt (except maybe the optimized build slowdown, which doesn't have much margin for variance to be skewing the results). I also measured the peak memory usage by observing "top". In case gives a clue: The app is a multi-threaded 2D spread simulator which deals with many mmapped Storable mutable vectors and has been pretty optimized for countless hours (I mean by this that it has (too) many INLINE pragmas. Mostly on polymorphic functions to aid in their specialization). I think some of this information can be deduced from the results I'm linking at the footer. I believe the INLINEs are playing a big part of the slowdown since the slowest modules to compile are the "Main" ones which put everything together, along with the typical lens-th-heavy "Types" ones. I'd like to help by producing a reproducible and isolated benchmark or a better analysis or ... so someone more knowledgeable than me on GHC internals can someday hopefully attack the regression. Any pointers on what would help and where can I learn to do it? Thanks! [1] https://gist.github.com/albertov/46fbb13d940f67a569f9a25c1cb8154c<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Falbertov%2F46fbb13d940f67a569f9a25c1cb8154c=02%7C01%7Csimonpj%40microsoft.com%7Cce8170b01de84bacdab308d4acd0aef3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636323459695695689=iRWChz2fzNFuXBAhiYABO5OepSXYBLxvvIQ8CAiABYg%3D=0> _______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Unused import warning on re-export
| Is there a reason GHC considers this case an unused import? It seems that | the use of the import is explicitly stated right within the import | itself. Should I submit a ticket for this? Hmm. I think you are saying that module A where import B as A(f) g = True that is equivalent to module A( module A ) where ... which exports all things "x" in scope as "A.x". So it'll export both f and g. But GHC will report f as unused, but not g. And that's inconsistent. Fair point. Yes, file a ticket. Better still, offer a patch :-). Simon | -Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Yitzchak Gale | Sent: 10 May 2017 13:56 | To: GHC users <glasgow-haskell-users@haskell.org> | Subject: Unused import warning on re-export | | I have a module A with no export list, and a function f which from the | API point of view should part of the export list of A. But f must be | defined in module B, not module A, due an import cycle. I added this line | in module A to re-export f from A: | | import B as A (f) | | This resulted in an unused import warning. That is a problem for us - we | keep our large code base clean of warnings as a policy. | | Is there a reason GHC considers this case an unused import? It seems that | the use of the import is explicitly stated right within the import | itself. Should I submit a ticket for this? | | Thanks, | Yitz | ___________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell- | users=02%7C01%7Csimonpj%40microsoft.com%7C81b06c9737d540a597df08d497 | a413d0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636300178355700119 | ata=xHt1FXEF5r4WMaMF3FSW4jFBRlB4OK8DQdcNAxZ7HOc%3D=0 ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: join points and stream fusion?
Thank you!
| -Original Message-
| From: Christian Höner zu Siederdissen [mailto:choe...@bioinf.uni-
| leipzig.de]
| Sent: 28 April 2017 00:14
| To: Simon Peyton Jones <simo...@microsoft.com>
| Cc: glasgow-haskell-users@haskell.org
| Subject: Re: join points and stream fusion?
|
| Sorry,
|
| with the addendum, I have constructed a very small example:
| https://ghc.haskell.org/trac/ghc/ticket/13623
|
| This is new with ghc 8.2-rc1 and does not show up earlier.
|
| Viele Gruesse,
| Christian
|
| * Simon Peyton Jones <simo...@microsoft.com> [28.04.2017 00:35]:
| > I'm afraid I don't have enough context to understand this thread.
| >
| > Could you offer a concrete example (as small as possible), and
| explain how to reproduce the problem you are seeing. Don't forget to
| give the compiler version you are using, and any libraries you depend
| on (as few as poss).
| >
| > Is this a regression? I.e. did some earlier version of GHC do better
| on the exact same code?
| >
| > Maybe open a Trac ticket.
| >
| > Thanks
| >
| > Simon
| >
| > | -Original Message-
| > | From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| > | boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| > | Sent: 27 April 2017 23:10
| > | To: glasgow-haskell-users@haskell.org
| > | Subject: Re: join points and stream fusion?
| > |
| > | As an addendum,
| > |
| > | I think what causes this is the following. I have a function
| > | (|||) xs ys = \lu ij -> xs lu ij Stream.++ ys lu ij xs and ys are
| > | two stream-generating functions and (Stream.++) concatenates
| > | streams. In the example I have four streams:
| > | xs_1 ||| xs_2 ||| xs_3 ||| xs_4
| > |
| > | However, here I end up with a join point on (++). Further
| evidenced
| > | (?) by the curious occurance of s1uf4 ... (Left (Left (Left
| ...))).
| > | Additional calls then are (Left (Left (Right ))) and so on.
| > |
| > | It would be really good if (|||) is *not* turned into a join
| point.
| > |
| > | Best,
| > | Christian
| > |
| > | * Christian Höner zu Siederdissen <choe...@bioinf.uni-leipzig.de>
| > | [27.04.2017 23:30]:
| > | > Dear all,
| > | >
| > | > have some of you experienced bad code generation in ghc-8.2-rc1
| in
| > | > combination with stream fusion from the vector package?
| > | >
| > | > Unfortunately, the problem occurs with ADPfusion code which
| means
| > | > no simple example, but I'm asking because of the following core
| below.
| > | >
| > | > In ghc-8.0 I have nice core, here however constructor
| > | > specialization has not happened, neither with the Left/Right nor
| with the SPEC.
| > | >
| > | > The running time in ghc-8.0 is 2.6 seconds, in rc-1 10.9
| seconds.
| > | >
| > | > Best,
| > | > Christian
| > | >
| > | > joinrec {
| > | > $wfoldlM'_loop2_s1uf4
| > | > $wfoldlM'_loop2_s1uf4 w_s1ueX ww1_s1uf2 w1_s1ueZ
| > | > = case w_s1ueX of { __DEFAULT ->
| > | > case w1_s1ueZ of {
| > | > Left sa_au90 ->
| > | > case sa_au90 of {
| > | > Left sa1_XuNq ->
| > | > case sa1_XuNq of {
| > | > Left sa2_XuNe ->
| > | > case sa2_XuNe of {
| > | > SL s2_alTo k_alTp ->
| > | > case k_alTp of {
| > | > __DEFAULT ->
| > | > jump $wfoldlM'_loop2_s1uf4
| > | > SPEC ww1_s1uf2 lvl211_s1IDG;
| > | > 1# ->
| > | > jump $wfoldlM'_loop2_s1uf4
| > | > SPEC ww1_s1uf2 (Left (Left (Left (SR
| > | > s2_alTo
| > | >
| > | > ___
| > | > Glasgow-haskell-users mailing list
| > | > Glasgow-haskell-users@haskell.org
| > | >
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fma
| > | > il.h
| > | > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users&
| > | > data
| > | >
| =02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a08d48dba1
| > | > 57d%
| > | >
| 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289277756070800
| > | > ata=
| > | > DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D=0
| > | ___
| > | Glasgow-haskell-users mailing list
| > | Glasgow-haskell-users@haskell.org
| > |
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fm
RE: join points and stream fusion?
I'm afraid I don't have enough context to understand this thread.
Could you offer a concrete example (as small as possible), and explain how to
reproduce the problem you are seeing. Don't forget to give the compiler
version you are using, and any libraries you depend on (as few as poss).
Is this a regression? I.e. did some earlier version of GHC do better on the
exact same code?
Maybe open a Trac ticket.
Thanks
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Christian Höner zu Siederdissen
| Sent: 27 April 2017 23:10
| To: glasgow-haskell-users@haskell.org
| Subject: Re: join points and stream fusion?
|
| As an addendum,
|
| I think what causes this is the following. I have a function
| (|||) xs ys = \lu ij -> xs lu ij Stream.++ ys lu ij xs and ys are two
| stream-generating functions and (Stream.++) concatenates streams. In the
| example I have four streams:
| xs_1 ||| xs_2 ||| xs_3 ||| xs_4
|
| However, here I end up with a join point on (++). Further evidenced (?)
| by the curious occurance of s1uf4 ... (Left (Left (Left ...))).
| Additional calls then are (Left (Left (Right ))) and so on.
|
| It would be really good if (|||) is *not* turned into a join point.
|
| Best,
| Christian
|
| * Christian Höner zu Siederdissen <choe...@bioinf.uni-leipzig.de>
| [27.04.2017 23:30]:
| > Dear all,
| >
| > have some of you experienced bad code generation in ghc-8.2-rc1 in
| > combination with stream fusion from the vector package?
| >
| > Unfortunately, the problem occurs with ADPfusion code which means no
| > simple example, but I'm asking because of the following core below.
| >
| > In ghc-8.0 I have nice core, here however constructor specialization
| > has not happened, neither with the Left/Right nor with the SPEC.
| >
| > The running time in ghc-8.0 is 2.6 seconds, in rc-1 10.9 seconds.
| >
| > Best,
| > Christian
| >
| > joinrec {
| > $wfoldlM'_loop2_s1uf4
| > $wfoldlM'_loop2_s1uf4 w_s1ueX ww1_s1uf2 w1_s1ueZ
| > = case w_s1ueX of { __DEFAULT ->
| > case w1_s1ueZ of {
| > Left sa_au90 ->
| > case sa_au90 of {
| > Left sa1_XuNq ->
| > case sa1_XuNq of {
| > Left sa2_XuNe ->
| > case sa2_XuNe of {
| > SL s2_alTo k_alTp ->
| > case k_alTp of {
| > __DEFAULT ->
| > jump $wfoldlM'_loop2_s1uf4
| > SPEC ww1_s1uf2 lvl211_s1IDG;
| > 1# ->
| > jump $wfoldlM'_loop2_s1uf4
| > SPEC ww1_s1uf2 (Left (Left (Left (SR
| > s2_alTo
| >
| > ___
| > Glasgow-haskell-users mailing list
| > Glasgow-haskell-users@haskell.org
| > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
| > askell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users
| > =02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a08d48dba157d%
| > 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289277756070800=
| > DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D=0
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
| ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-
| users=02%7C01%7Csimonpj%40microsoft.com%7Cd36333a2218f4c513f5a08d48d
| ba157d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636289277756070800
| ata=DGsBNjZPuDbpEONyJBOy7BDimCELGHNM1trxjCP5luk%3D=0
___________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Option for Combinator Graphs in GHC?
Does the GHC compiler generate combinator terms/graphs of Haskell programs? Combinator terms are often derived during compilation for purposes of optimization by way of normal order graph reduction. But does GHC output, e.g., as an option, a given Haskell program's entire combinator term/graph? Very respectfully, Mark R. Nixon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Why isn't this Overlapping?
Moreover, as discussed in the user manual
section<http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html#overlapping-instances>,
GHC doesn’t complain about overlapping instances at the instance decl, but
rather where the instances are used. That’s why there is no overlap complaint
here
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of Iavor Diatchki
Sent: 18 April 2017 01:50
To: anthony_clay...@clear.net.nz
Cc: GHC Users Mailing List <glasgow-haskell-users@haskell.org>
Subject: Re: Why isn't this Overlapping?
Hello,
these two instances really should be rejected as they violate the FD of the
class: we can derive `TypeEq a a True` using the first instance and `TypeEq a a
False` using the second one. Unfortunately, the check that we are using to
validate FDs when `UndecidableInstances` is on, is not quite correct (relevant
tickets are #9210 and #10675 where there are similar examples).
-Iavor
On Sun, Apr 16, 2017 at 12:13 AM, Anthony Clayden
<anthony_clay...@clear.net.nz<mailto:anthony_clay...@clear.net.nz>> wrote:
--ghc 7.10 or 8.0.1
{-# LANGUAGE DataKinds, KindSignatures, GADTs,
MultiParamTypeClasses,
FunctionalDependencies, FlexibleInstances,
UndecidableInstances,
NoOverlappingInstances #-}
class TypeEq a a' (b :: Bool) | a a' -> b
instance (b ~ True) => TypeEq a a b
instance (b ~ False) => TypeEq a a' b
Those two instance heads are nearly identical, surely they
overlap?
And for a type-level type equality test, they must be
unifiable.
But GHC doesn't complain.
If I take off the FunDep, then GHC complains.
AFAICT none of those extensions imply Overlaps,
but to be sure I've put NoOverlapping.
AntC
_______________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org<mailto:Glasgow-haskell-users@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fglasgow-haskell-users=02%7C01%7Csimonpj%40microsoft.com%7Cc6be4bcfd23946f5f4fc08d485f4f93a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636280734593515972=Us2Ovast3dKEpNkfEDbejyBHGmGKh2ElAi6%2FqQY8iFE%3D=0>
___________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Accessing the "original" names via GHC API
The TyCon has a Name (use tyConName to get it). The Name has a Module and an OccName (use nameModule and nameOccName to get them) The OccName has a string (occNameString) The Module has a ModuleName and a Package. All of these will give the “original-name” info, ignoring what’s in scope. Does that help? S From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Ranjit Jhala Sent: 25 January 2017 00:09 To: glasgow-haskell-users@haskell.org Subject: Accessing the "original" names via GHC API Hi, I'm quite vexed trying to do the following. Suppose I have a file: ``` module Foo import qualified Data.Set as S baz :: S.Set Int baz = S.empty ``` My goal is to write a function tyconString :: TyCon -> String (perhaps with extra parameters) such that given the `TyCon` corresponding to `Set`, I get back the "original" name `S.Set`, or even `Data.Set.Set`. Everything I've tried, which is fiddling with different variants of `PprStyle`, end up giving me `Data.Set.Base.Set` Does anyone have a suggestion for how to proceed? Thanks! - Ranjit. ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: GHC rewrite rules for class operations & laws
| Indeed, we could eliminate several hundred lines of boilerplate in GHC if we | could lift this restriction. Can you be more specific? Which hundreds of lines? Do add this info to the ticket when Gorge makes it. Or just make one! Simon | -Original Message- | From: Ben Gamari [mailto:b...@smart-cactus.org] | Sent: 29 December 2016 14:50 | To: Conal Elliott <co...@conal.net>; George Colpitts | <george.colpi...@gmail.com> | Cc: glasgow-haskell-users@haskell.org; Simon Peyton Jones | <simo...@microsoft.com> | Subject: Re: GHC rewrite rules for class operations & laws | | On December 28, 2016 7:27:20 PM EST, Conal Elliott <co...@conal.net> wrote: | >Hi, George. Yes, please do add a task, hopefully to serve as a | >conversation anchor until the issues and path forward are clearer. From | >my perspective, class methods are among the most natural and useful | >candidates for rewrite rules, since they tend to have associated laws, | >many (but not all) of which are helpful in optimization. The | >alternative I know (and am using) is fairly inconvenient: replicating | >entire APIs just in order to delay inlining long enough to apply rules. | > | Indeed, we could eliminate several hundred lines of boilerplate in GHC if we | could lift this restriction. | | Cheers, | | - Ben | ___________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: GHC rewrite rules for class operations & laws
Conal Is it possible to apply GHC rewrite rules to class methods? Not currently. See https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples. https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more background. It’d be great if someone wanted to think through all this. Simon From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott Sent: 17 November 2016 16:40 To: glasgow-haskell-users@haskell.org Subject: GHC rewrite rules for class operations & laws Is it possible to apply GHC rewrite rules to class methods? From what I’ve read and seen, class methods get eliminated early by automatically-generated rules. Is there really no way to postpone such inlining until a later simplifier stage? The GHC Users Guide docs say no<https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloads.haskell.org%2F~ghc%2Flatest%2Fdocs%2Fhtml%2Fusers_guide%2Fglasgow_exts.html%23how-rules-interact-with-class-methods=02%7C01%7Csimonpj%40microsoft.com%7C8678611c4c57499f97be08d40f08662a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636149976146128136=GjkFhlWdNkT6eo85FvcLKkJYoir7Dui9xJ9kMTYKVmU%3D=0>, and suggests instead giving a duplicate vocabulary with somewhat awkward names for class methods. I’ve not seen this practice in libraries. I gather that we cannot therefore use class laws as optimizations in the form of rewrite rules, which seems a terrible loss. In Control.Category and Control.Arrow, I see rules for class laws but also header comments saying “The RULES for the methods of class Arrow may never fire e.g. compose/arr; see Trac #10528”. I’d appreciate a reality check about my conclusions as well as any strategies for using class laws in optimization. Thanks, -- Conal _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Getting rid of -XImpredicativeTypes
1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just
disappear, or are they also enabled anyway? (I would guess the former.)
Yes, they’d disappear.
2) There was a sketch drawn up around a year ago (I think) aiming to actually
fix ImpredicativeTypes. I don't recall who was working on it, but I think when
I mentioned it in the context of something else, you didn't seem to be aware of
it. I guess it's safe to say that nothing ever came of it, at least inasmuch as
no one ever showed you their proposal for a properly functioning
ImpredicativeTypes?
It’s just a swamp. I have tried multiple times to fix ImpredicativeTypes, and
failed every time. Which is not to say that someone shouldn’t try again, with
new thinking.
Simon
From: Dan Doel [mailto:dan.d...@gmail.com]
Sent: 26 September 2016 00:54
To: Simon Peyton Jones <simo...@microsoft.com>
Cc: ghc-us...@haskell.org; ghc-d...@haskell.org
Subject: Re: Getting rid of -XImpredicativeTypes
I don't use the extension, because it's more pleasant to use newtypes with
polymorphic contents. But here are some questions:
1) ImpredicativeTypes enables types like `Maybe (forall a. a)`. Do those just
disappear, or are they also enabled anyway? (I would guess the former.)
2) There was a sketch drawn up around a year ago (I think) aiming to actually
fix ImpredicativeTypes. I don't recall who was working on it, but I think when
I mentioned it in the context of something else, you didn't seem to be aware of
it. I guess it's safe to say that nothing ever came of it, at least inasmuch as
no one ever showed you their proposal for a properly functioning
ImpredicativeTypes?
Anyhow, if it can't be fixed, I think not having the extension is superior to
its current state. And really, I think even if fixing it were on the roadmap,
it'd be better to get rid of it until it were actually fixed.
-- Dan
On Sun, Sep 25, 2016 at 2:05 PM, Simon Peyton Jones via ghc-devs
<ghc-d...@haskell.org<mailto:ghc-d...@haskell.org>> wrote:
Friends
GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to
support impredicative polymorphism. But it is vestigial…. if it works, it’s
really a fluke. We don’t really have a systematic story here at all.
I propose, therefore, to remove it entirely. That is, if you use
-XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete
no-op) and you should remove it.
Before I pull the trigger, does anyone think they are using it in a
mission-critical way?
Now that we have Visible Type Application there is a workaround: if you want to
call a polymorphic function at a polymorphic type, you can explicitly apply it
to that type. For example:
{-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}
module Vta where
f x = id @(forall a. a->a) id @Int x
You can also leave out the @Int part of course.
Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a).
Is that sensible? Or should we allow it regardless? I rather think the
latter… if you have Visible Type Application (i.e. -XTypeApplications) then
applying to a polytype is nothing special. So I propose to lift that
restriction.
I should go through the GHC Proposals Process for this, but I’m on a plane, so
I’m going to at least start with an email.
Simon
___
ghc-devs mailing list
ghc-d...@haskell.org<mailto:ghc-d...@haskell.org>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=01%7C01%7Csimonpj%40microsoft.com%7Cf4d41103efc4487796c708d3e59f3720%7C72f988bf86f141af91ab2d7cd011db47%7C1=Ju37RVvZoNakCzz1dgTj%2F8mO9yz4ImbII14Hw%2FHWRpk%3D=0>
___________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
FW: Getting rid of -XImpredicativeTypes
Friends
GHC has a flag -XImpredicativeTypes that makes a half-hearted attempt to
support impredicative polymorphism. But it is vestigial…. if it works, it’s
really a fluke. We don’t really have a systematic story here at all.
I propose, therefore, to remove it entirely. That is, if you use
-XImpredicativeTypes, you’ll get a warning that it does nothing (ie. complete
no-op) and you should remove it.
Before I pull the trigger, does anyone think they are using it in a
mission-critical way?
Now that we have Visible Type Application there is a workaround: if you want to
call a polymorphic function at a polymorphic type, you can explicitly apply it
to that type. For example:
{-# LANGUAGE ImpredicativeTypes, TypeApplications, RankNTypes #-}
module Vta where
f x = id @(forall a. a->a) id @Int x
You can also leave out the @Int part of course.
Currently we have to use -XImpredicativeTypes to allow the @(forall a. a->a).
Is that sensible? Or should we allow it regardless? I rather think the
latter… if you have Visible Type Application (i.e. -XTypeApplications) then
applying to a polytype is nothing special. So I propose to lift that
restriction.
I should go through the GHC Proposals Process for this, but I’m on a plane, so
I’m going to at least start with an email.
Simon
___
ghc-devs mailing list
ghc-d...@haskell.org
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs=01%7C01%7Csimonpj%40microsoft.com%7Cfed1bf51dcf744f68fcd08d3e56e903b%7C72f988bf86f141af91ab2d7cd011db47%7C1=jwRX7Pxe62sp6xU2jmXyoAxHNzledV%2BPceCGW%2BxN%2FlQ%3D=0
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Type families in kind signatures with TypeInType
Interesting. Is this case also an example, or is it a non-feature? class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a Ah, that’s quite different! We should do strongly-connected-component analysis of the associated-type declarations within a single class declaration…. but we don’t currently do that. No difficulty in principle, I think. You could open a ticket. (Do include a link to this email thread and to #12088) Simon From: d4ve.menen...@gmail.com [mailto:d4ve.menen...@gmail.com] On Behalf Of David Menendez Sent: 23 September 2016 19:51 To: Simon Peyton Jones <simo...@microsoft.com> Cc: glasgow-haskell-users@haskell.org Mailing List <Glasgow-haskell-users@haskell.org> Subject: Re: Type families in kind signatures with TypeInType On Fri, Sep 23, 2016 at 3:19 AM, Simon Peyton Jones <simo...@microsoft.com<mailto:simo...@microsoft.com>> wrote: This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088. Interesting. Is this case also an example, or is it a non-feature? class C t where type K t :: Type type T t :: K t -> Type m :: t -> T t a min.hs:21:17: error: • Type constructor ‘K’ cannot be used here (it is defined and used in the same recursive group) • In the kind ‘K t -> Type’ Failed, modules loaded: none. GHC accepts this if K t is moved outside of C. The “type instance T List” declaration actually depends on the “type instance K List” declaration; the latter must be typechecked before the former. But this dependency is absolutely unclear. There’s a long discussion on the thread. Bottom line: we don’t know a solid automated way to spot this kind of problem, so I think we are going to ask for programmer assistance. In this case, we’d put a “separator” after the “type instance K List” decl, to explain that it must be done first: type instance K List = Type === type instance T List = [] Currently you have to write $(return []) to get the separator, but I think we’ll add a special separator. Yes, this works. Thanks. It would be disappointing if this is the best we can do, but I guess other dependent languages don’t need to deal with open type families and everything being potentially mutually recursive. -- Dave Menendez <d...@zednenem.com<mailto:d...@zednenem.com>> <http://www.eyrie.org/~zednenem/<https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fwww.eyrie.org%2F~zednenem%2F=01%7C01%7Csimonpj%40microsoft.com%7C89f26f5e599e49b96e0c08d3e3e29e26%7C72f988bf86f141af91ab2d7cd011db47%7C1=c8g6ahf%2F8lun%2BPBof97s03XbePVwT4Buh6ef2bDSjLg%3D=0>> _______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Type families in kind signatures with TypeInType
This is an example of https://ghc.haskell.org/trac/ghc/ticket/12088.
The “type instance T List” declaration actually depends on the “type instance K
List” declaration; the latter must be typechecked before the former. But this
dependency is absolutely unclear. There’s a long discussion on the thread.
Bottom line: we don’t know a solid automated way to spot this kind of problem,
so I think we are going to ask for programmer assistance. In this case, we’d
put a “separator” after the “type instance K List” decl, to explain that it
must be done first:
type instance K List = Type
===
type instance T List = []
Currently you have to write $(return []) to get the separator, but I think
we’ll add a special separator.
Simon
From: Glasgow-haskell-users [mailto:glasgow-haskell-users-boun...@haskell.org]
On Behalf Of David Menendez
Sent: 23 September 2016 05:48
To: glasgow-haskell-users@haskell.org Mailing List
<Glasgow-haskell-users@haskell.org>
Subject: Type families in kind signatures with TypeInType
Should the code below work in GHC 8.0.1?
{-# LANGUAGE TypeInType, TypeFamilies #-}
import Data.Kind (Type)
type family K t :: Type
type family T t :: K t -> Type
data List
type instance K List = Type
type instance T List = []
Right now, I get an error like this one:
min.hs:12:24: error:
• Expected kind ‘K List -> Type’, but ‘[]’ has kind ‘* -> *’
• In the type ‘[]’
In the type instance declaration for ‘T’
which is puzzling, since K List -> Type and * -> * should be the same.
Obviously, TypeInType is experimental and incomplete. I’m just wondering if
this sort of thing is expected to work, or if I’m doing something not yet
supported or never to be supported
In particular, the kind signature for T is forall t -> K t -> Type, which looks
like DependentHaskell.
--
Dave Menendez <d...@zednenem.com<mailto:d...@zednenem.com>>
<http://www.eyrie.org/~zednenem/<https://na01.safelinks.protection.outlook.com/?url=http:%2f%2fwww.eyrie.org%2f~zednenem%2f=01%7C01%7Csimonpj%40microsoft.com%7C740be9e2f66146e93b1308d3e36cdcda%7C72f988bf86f141af91ab2d7cd011db47%7C1=r83909O38f2c%2feaujupnsW%2fSy23XLouk2unQBGTCB8w%3d>>
_______________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Exposing target language in Haskell with GHC API
Hi, thanks for the response. On 26/08/2016, Christiaan Baaij <christiaan.ba...@gmail.com> wrote: > You mentioned that GHC does name mangling, but I must say I've never > seen GHC do this. I guess this was unclear: our compiler is mangling the names from GHC core, lest any clash with a BlueSpec keyword. We need to find a way to annotate the Haskell source to tell our compiler to not mangle a name. > What GHC does do is inlining and specialisation, which might optimise > away your carefully constructed "primitive". > > What I do in this case, is simply mark my "primitive" function, your > "exposed" BlueSpec functions, as NOINLINE. Ah, yes, it seems we will need to do this too. _______________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: GHC Performance / Replacement for R?
Sounds bad. But it'll need someone with bytestring expertise to debug. Maybe
there's a GHC problem underlying; or maybe it's shortcoming of bytestring.
Simon
| -Original Message-
| From: Glasgow-haskell-users [mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Dominic Steinitz
| Sent: 25 August 2016 10:11
| To: GHC users <glasgow-haskell-users@haskell.org>
| Subject: GHC Performance / Replacement for R?
|
| I am trying to use Haskell as a replacement for R but running into two
| problems which I describe below. Are there any plans to address the
| performance issues I have encountered?
|
| 1. I seem to have to jump through a lot of hoops just to be able to
| select the data I am interested in.
|
| {-# LANGUAGE ScopedTypeVariables #-}
|
| {-# OPTIONS_GHC -Wall #-}
|
| import Data.Csv hiding ( decodeByName )
| import qualified Data.Vector as V
|
| import Data.ByteString ( ByteString )
| import qualified Data.ByteString.Char8 as B
|
| import qualified Pipes.Prelude as P
| import qualified Pipes.ByteString as Bytes import Pipes import
| qualified Pipes.Csv as Csv import System.IO
|
| import qualified Control.Foldl as L
|
| main :: IO ()
| main = withFile "examples/787338586_T_ONTIME.csv" ReadMode $ \h -> do
|let csvs :: Producer (V.Vector ByteString) IO ()
|csvs = Csv.decode HasHeader (Bytes.fromHandle h) >-> P.concat
|uvectors :: Producer (V.Vector ByteString) IO ()
|uvectors = csvs >-> P.map (V.foldr V.cons V.empty)
|vec_vec <- L.impurely P.foldM L.vector uvectors
|print $ (vec_vec :: V.Vector (V.Vector ByteString)) V.! 17
|print $ V.length vec_vec
|let rockspring = V.filter (\x -> x V.! 8 == B.pack "RKS") vec_vec
|print $ V.length rockspring
|
| Here's the equivalent R:
|
| df <- read.csv("787338586_T_ONTIME.csv")
| rockspring <- df[df$ORIGIN == "RKS",]
|
| 2. Now I think I could improve the above to make an environment that
| is more similar to the one my colleagues are used to in R but more
| problematical is the memory usage.
|
| * 112.5M file
| * Just loading the source into ghci takes 142.7M
| * > foo <- readFile "examples/787338586_T_ONTIME.csv" > length foo
| takes me up to 4.75G. But we probably don't want to do this!
| * Let's try again.
| * > :set -XScopedTypeVariables
| * > h <- openFile "examples/787338586_T_ONTIME.csv" ReadMode
| * > let csvs :: Producer (V.Vector ByteString) IO () = Csv.decode
| HasHeader (Bytes.fromHandle h) >-> P.concat
| * > let uvectors :: Producer (V.Vector ByteString) IO () = csvs >->
| P.map (V.map id) >-> P.map (V.foldr V.cons V.empty)
| * > vec_vec :: V.Vector (V.Vector ByteString) <- L.impurely P.foldM
| L.vector uvectors
| * Now I am up at 3.17G. In R I am under 221.3M.
| * > V.length rockspring takes a long time to return 155 and now I am
| at 3.5G!!! In R > rockspring <- df[df$ORIGIN == "RKS",] seems
| instantaneous and now uses only 379.5M.
| * > length(rockspring) 37 > length(df$ORIGIN) 471949 i.e. there are
| 37 columns and 471,949 rows.
|
| Running this as an executable gives
|
| ~/Dropbox/Private/labels $ ./examples/BugReport +RTS -s ["2014-01-
| 01","EV","20366","N904EV","2512","10747","1074702","30747",
| "BRO","Brownsville, TX","Texas","11298","1129803","30194",
|"DFW","Dallas/Fort Worth, TX","Texas","0720","0718",
|"-2.00","8.00","0726","0837","7.00","0855","0844","-11.00","0.00",
|"","0.00","482.00","","","","","",""]
| 471949
| 155
|14,179,764,240 bytes allocated in the heap
| 3,378,342,072 bytes copied during GC
| 786,333,512 bytes maximum residency (13 sample(s))
|36,933,976 bytes maximum slop
| 1434 MB total memory in use (0 MB lost due to
| fragmentation)
|
| Tot time (elapsed) Avg pause
| Max pause
|Gen 0 26989 colls, 0 par1.423s 1.483s 0.0001s
| 0.0039s
|Gen 113 colls, 0 par1.005s 1.499s 0.1153s
| 0.6730s
|
|INITtime0.000s ( 0.003s elapsed)
|MUT time3.195s ( 3.193s elapsed)
|GC time2.428s ( 2.982s elapsed)
|EXITtime0.016s ( 0.138s elapsed)
|Total time5.642s ( 6.315s elapsed)
|
|%GC time 43.0% (47.2% elapsed)
|
|Alloc rate4,437,740,019 bytes per MUT second
|
|Productivity 57.
Exposing target language in Haskell with GHC API
A colleague and i are writing, as an unofficial side project, a
Haskell→Bluespec compiler, using GHC as our Haskell front-end. The
source language of the part we are writing is GHC Core. We need to
somehow expose some Bluespec terms and types to the Haskell source
program. We had a few ideas:
1. Some "NO_MANGLE" pragma which would tell GHC to not mangle the
emitted name, e.g. `x = {-# NO_MANGLE #-} x` to expose `x`
2. `foreign import prim`, not quite sure how yet
3. "CORE" pragmas, e.g. `x = {-# CORE "foo" #-} x` to expose `x`
4. "ANN" pragmas, e.g. `{-# ANN x "no_mangle" #-} x = x` to expose `x`
1 and 2 would mean modifying GHC which we'd rather not do. For 3,
we're not sure how to find the "CORE"-pragmatic annotations in a
`Core` AST. 4 seems it would work but be a little cumbersome, as the
annotation is not on the `Core` AST.
Anyone know a good way to do this?
___________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: ArgumentDo proposal updated
I've added record construction and update to the syntax, which makes it clearer how the other constructs are analogous to them. Simon | -Original Message- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | boun...@haskell.org] On Behalf Of Akio Takano | Sent: 11 July 2016 03:24 | To: glasgow-haskell-users@haskell.org | Subject: ArgumentDo proposal updated | | Hi glasgow-haskell-users, | | Thank you for all the feedback to the ArgumentDo proposal. Following | the discussion, I made changes to the proposal and updated the wiki | page [0]. | | Now the proposed grammar is greatly simplified: it doesn't add a new | non-terminal anymore, indeed it removes one instead. The proposed set | of accepted programs remains unchanged. | | I hope the this update addresses one major concern that was raised in | the previous discussion. | | Any feedback is appreciated. | | Regards, | Takano Akio | | [0]: https://ghc.haskell.org/trac/ghc/wiki/ArgumentDo | ___ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.h | askell.org%2fcgi-bin%2fmailman%2flistinfo%2fglasgow-haskell- | users=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c4ef11cd0d5d041 | 3ac28108d3a9327fd1%7c72f988bf86f141af91ab2d7cd011db47%7c1=flpo46 | T9CWuGH8ndJY3roC44iubY7U8xeYWkJ2J8Img%3d ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
RE: Rethinking GHC's approach to managing proposals
Just to be clear: * We are actively seeking feedback about the proposal [4] below. It's not a fait-accompli. * You can join the dialogue by (a) replying to this email, (b) via the "Conversations" tab of [4], namely https://github.com/ghc-proposals/ghc-proposals/pull/1 Doubtless via reddit too! If you don't like something, the more specific and concrete you can be about a better alternative, the better. E.g. Richard's comments on the "conversations" tab both ask questions and propose answers. Bravo! Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Ben | Gamari | Sent: 09 July 2016 21:46 | To: GHC developers <ghc-d...@haskell.org>; ghc-users | Subject: Rethinking GHC's approach to managing proposals | | Hello everyone, | | Recently there has been a fair bit of discussion[1,2] around the | mechanisms by which proposed changes to GHC are evaluated. While we have | something of a formal proposal protocol [3], it is not clearly | documented, inconsistently applied, and may be failing to serve a | significant fraction of GHC's potential contributor pool. | | Over the last few weeks, I have been doing a fair amount of reading, | thinking, and discussing to try to piece together a proposal scheme | which better serves our community. | | The resulting proposal [4] is strongly inspired by the RFC process in | place in the Rust community [5], the leaders of which have thought quite | hard about fostering community growth and participation. While no | process is perfect, I feel like the Rust process is a good starting | point for discussion, offering enough structure to guide new | contributors through the process while requiring only a modest | investment of developer time. | | To get a sense for how well this will work in our community, I propose | that we attempt to self-host the proposed process. To this end I have | setup a ghc-proposals repository [6] and opened a pull request for | discussion of the process proposal [4]. | | Let's see how this goes. | | Cheers, | | - Ben | | | [1] | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red | dit.com%2fr%2fhaskell%2fcomments%2f4oyxo2%2fblog_contributing_to_ghc%2f& | data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a6608 | d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1=Hl6GqRWfu7IOQtpE | jpfsNAkv3mmLgNKm2ciQDoMe6HA%3d | [2] | https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.red | dit.com%2fr%2fhaskell%2fcomments%2f4isua9%2fghc_development_outsidein%2f | =01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c99735311c5f64cac6a660 | 8d3a83a032a%7c72f988bf86f141af91ab2d7cd011db47%7c1=bj2AQqQirX3X%2f | 4%2fFr05eXFuD4yW0r9Nmrmdg7IGEF%2f8%3d | [3] | https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/AddingFeatures | [4] https://github.com/ghc-proposals/ghc- | proposals/pull/1/files?short_path=14d66cd#diff- | 14d66cda32248456a5f223b6333c6132 | [5] https://github.com/rust-lang/rfcs | [6] https://github.com/ghc-proposals/ghc-proposals ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Rethinking GHC's approach to managing proposals
>Recently there has been a fair bit of discussion[1,2] around the >mechanisms by which proposed changes to GHC are evaluated. While we have >something of a formal proposal protocol [3], it is not clearly >documented, inconsistently applied, and may be failing to serve a >significant fraction of GHC's potential contributor pool. I think the best thing to do is to fork the source code and modify it according to one's own needs. Having some sort of committees to decide about the syntax, etc. is a really bad idea. A.S. -- Apostolos Syropoulos Xanthi, Greece _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Proposal: ArgumentDo
Infix ($) is so noisy that I’ve adapted a code style that replaces it entirely with parentheses. And the hack to make ($) work with higher-rank types is pretty awkward too. Seen from these angles, I’m very much in favour of ArgumentDo. However, the clarity of `runST do ...` comes at a high price: only some of the missing ($) make the code clearer, where others make it much worse. You give a couple of examples yourself: > f > do x > do y I have to think a bit how this might be parsed even after reading the proposal. I’m a bit torn on whether I like or not like it, but I think the ArgumentDo syntax that I find awkward now is a matter of style, and one could probably get used to only using it in certain places, despite all of the possibilities. David/quchen _______ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Simon's email classified as spam
Dear GHC devs/users This is another test to see if email from me, relayed via Haskell.org, ends up in your spam folder. Gershom thinks he’s fixed it (below). Can I trespass on your patience once more? Just let me know if this email ends up in your inbox or spam. Can you cc John and Gershom (but perhaps not everyone else)? Thanks Simon | From: Gershom B [mailto:gersh...@gmail.com] | Sent: 18 June 2016 18:53 | To: Simon Peyton Jones <simo...@microsoft.com>; John Wiegley | <jo...@newartisans.com> | Cc: Michael Burge <michaelbu...@pobox.com> | Subject: Re: FW: CMM-to-SAM: Register allocation weirdness | | Simon — I just found two possible sources of the problem (first: the top | level config didn’t take hold due to other errors when updating — fixed that, | and second, it might be possible the top level config isn’t retroactively | applied to all lists — so i added the config to the relevant lists directly). | | I think if you try one more time it might work (fingers crossed). ___________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Kontakt Lenste yeni yil firsati 1 Kutu Lens 35 Milyon USTELIK ADRESE TESLIM KACIRMAYIN_____6357474__
En ucuz lensler icin lutfen tiklayin. Bir telefonla adrese teslim. http://www.akdenizgoz.com Akdeniz Goz Merkezi Fevzipaþa No:73 Fatih0 212 635 74 74 Listeden cikmak icin [EMAIL PROTECTED]adresine bos mail gonderiniz
