- ghc-devs - Haskell.org

Review of CONTRIBUTORS.md
by Ben Gamari 28 Sep '17

28 Sep '17

Hello everyone, Today I sat down and wrote a CONTRIBUTORS.md document for the ghc repository. This is recommended by GitHub to ensure that contributors can easily discover the first steps to contributing to the project. Moreover, it provided a nice blank slate to summarize the existing contributor documentation. It would be greatly appreciated if you could give it [1] a read-through and leave your feedback. Cheers, - Ben [1] https://phabricator.haskell.org/D4037 https://github.com/bgamari/ghc/blob/contributing/CONTRIBUTING.md

2 3

Re: Including libffi as a submodule
by David Feuer 28 Sep '17

28 Sep '17

Sorry; wasn't thinking straight! David FeuerWell-Typed, LLP -------- Original message --------From: "Boespflug, Mathieu" <m(a)tweag.io> Date: 9/28/17 3:56 AM (GMT-05:00) To: David Feuer <david(a)well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Re: Including libffi as a submodule Aren't we talking about the C project here? https://sourceware.org/libffi/ -- Mathieu Boespflug Founder at http://tweag.io. On 28 September 2017 at 06:27, David Feuer <david(a)well-typed.com> wrote: > On Tuesday, September 26, 2017 9:38:11 PM EDT Ben Gamari wrote: > >> Numerous attempts have >> been made to get the libffi maintainers to cut a new release but sadly >> no progress has been made in over six months of trying. > > Has anyone followed the process described in the somewhat poorly named > https://wiki.haskell.org/Taking_over_a_package to try to add one or more > maintainers upstream? If the current maintainer(s) object to that, would it make > sense to produce a proper fork on Hackage? > > David > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Including libffi as a submodule
by Ben Gamari 28 Sep '17

28 Sep '17

Hello everyone, As you may know, GHC carries a dependency on the libffi library. Libffi is used on most platforms (notably not x86 and x86-64) for foreign function invocation (see rts/Adjustor.c for details). While libffi works well, it is unfortunately not particularly actively maintained. In fact, it has been nearly three years since the last official release. A lot can happen in three years and there is now at least two bugs [1,2] present in the current release which makes it impossible to build GHC in some configurations. These bugs have been fixed upstream but these fixes are unreleased. Numerous attempts have been made to get the libffi maintainers to cut a new release but sadly no progress has been made in over six months of trying. In light of this I propose that we begin treating libffi as a submodule until a release is made. In particular, adding libffi as a submodule will ease development on ARM and AArch64 (especially Apple) targets, which have seen quite a bit of developer attention recently. Note that under this scheme it will still be possible to link against the system's libffi installation using ./configure's --enable-system-libffi flag. Are there any strong objections to plan? If so please speak up. If there is no objection by Saturday we will move ahead. Cheers, - Ben [1] https://github.com/libffi/libffi/issues/191 [2] https://github.com/libffi/libffi/pull/263

5 5

Re: [GHC] #14294: IndexError: pop from empty list
by Gabor Greif 27 Sep '17

27 Sep '17

Right. On 9/27/17, GHC <ghc-devs(a)haskell.org> wrote: > #14294: IndexError: pop from empty list > -------------------------------------+------------------------------------- > Reporter: heisenbug | Owner: (none) > Type: bug | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 8.2.1 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > | Unknown/Multiple > Type of failure: None/Unknown | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > > Comment (by bgamari): > > Was the URL you were requesting > https://ghc.haskell.org/trac/ghc/attachment/ticket/14293/ ? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14294#comment:2> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

Re: ghc-devs Digest, Vol 169, Issue 57
by Michael Baikov 26 Sep '17

26 Sep '17

> I, too, have wished for the ability to have a separator in large number literals. > > So a strong +1 from me. more +1 here

1 0

New primitive types?
by Michal Terepeta 26 Sep '17

26 Sep '17

Hi all, I'm working on making it possible to pack constructor fields [1], example: ``` data Foo = Foo {-# UNPACK #-} !Float {-# UNPACK #-} !Int32 ``` should only require 4 bytes for unpacked `Float` and 4 bytes for unpacked `Int32`, which on 64-bit arch would take just 1 word (instead of 2 it currently does). The diff to support packing of fields is in review [2], but to really take advantage of it I think we need to introduce new primitive types: - Int{8,16,32}# - Word{8,16,32}# along with some corresponding primops and with some other follow-up changes like extending `PrimRep`. Then we could use them in definitions of `Int{8,16,32}` and `Word{8,16,32}` (they're currently just wrapping `Int#` and `Word#`). Does that sound ok with everyone? (just making sure that this makes sense before I invest more time into this :) Thanks, Michal [1] https://ghc.haskell.org/trac/ghc/ticket/13825 [2] https://phabricator.haskell.org/D3809

4 9

Re: Why isn't this Typeable?
by Richard Eisenberg 25 Sep '17

25 Sep '17

I think we're a long way off from supporting Typeable for higher-kinded types, so I wouldn't worry about that dark, spider-ridden corner. Richard > On Sep 25, 2017, at 3:00 PM, David Feuer <david(a)well-typed.com> wrote: > > No. What led me down this path is that I was thinking about whether we could simplify the representation and reduce the TCB. The as-yet-incomplete ideas I had (largely based on the concept of using a constructor name as a singletons-style defunctionalization symbol) seem difficult to adapt to the generalization I describe, so I wanted to check first how much that matters. > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Richard Eisenberg <rae(a)cs.brynmawr.edu> > Date: 9/25/17 2:42 PM (GMT-05:00) > To: David Feuer <david(a)well-typed.com> > Cc: Ben Gamari <ben(a)smart-cactus.org>, ghc-devs(a)haskell.org > Subject: Re: Why isn't this Typeable? > > I suppose this is conceivable, but it would complicate the representation and solver for TypeReps considerably. Do you have a real use case? > > Richard > > > On Sep 25, 2017, at 2:28 PM, David Feuer <david(a)well-typed.com> wrote: > > > > My example wasn't quite the one I intended (although I think it should > > work as well, and it's simpler). Here's the sort of example I really intended: > > > > data Bar :: forall (j :: forall k. k -> Maybe k) (a :: Type). Proxy (j a) -> Type > > > > I would expect > > > > Bar :: Proxy ('Just Int) -> Type > > > > or, to abuse notation a bit, > > > > Bar @'Just @Int > > > > to be Typeable. What I'm really suggesting is that we should distinguish between things that are typeable and > > things that can be decomposed into typeable components. We already make a limited distinction > > here. For example, we have > > > > 'Just :: forall a. a -> Maybe a > > > > 'Just itself cannot be Typeable, but once it's applied to a kind variable, it is Typeable. > > 'Just @Int is Typeable even though that (kind) application cannot be broken with App. Similarly, I'd expect > > Foo 'Just to be Typeable even though that (type) application cannot be broken with App (or Fun). > > > > Putting things in terms of fingerprints, we can offer type-indexed fingerprints > > > > newtype Finger a = Finger Fingerprint > > > > for anything we can fingerprint. Is there any difficulty fingerprinting types like Foo 'Just and > > Bar @'Just @Int? Fingerprints are useful for lots of applications where decomposition isn't > > necessary. > > > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard Eisenberg wrote: > >> The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be Typeable, but it's 'Just invisibly instantiated at some monotype for `a`. > >> > >> So I think that this boils down to impredicativity and that the implementation is doing the right thing here. > >> > >> Richard > >> > >>> On Sep 24, 2017, at 5:45 AM, David Feuer <david(a)well-typed.com> wrote: > >>> > >>> data Foo :: (forall a. a -> Maybe a) -> Type > >>> > >>> Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? > >>> > >>> David Feuer > >>> Well-Typed, LLP > >>> _______________________________________________ > >>> ghc-devs mailing list > >>> ghc-devs(a)haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > > > >

1 0

Re: Why isn't this Typeable?
by David Feuer 25 Sep '17

25 Sep '17

No. What led me down this path is that I was thinking about whether we could simplify the representation and reduce the TCB. The as-yet-incomplete ideas I had (largely based on the concept of using a constructor name as a singletons-style defunctionalization symbol) seem difficult to adapt to the generalization I describe, so I wanted to check first how much that matters. David FeuerWell-Typed, LLP -------- Original message --------From: Richard Eisenberg <rae(a)cs.brynmawr.edu> Date: 9/25/17 2:42 PM (GMT-05:00) To: David Feuer <david(a)well-typed.com> Cc: Ben Gamari <ben(a)smart-cactus.org>, ghc-devs(a)haskell.org Subject: Re: Why isn't this Typeable? I suppose this is conceivable, but it would complicate the representation and solver for TypeReps considerably. Do you have a real use case? Richard > On Sep 25, 2017, at 2:28 PM, David Feuer <david(a)well-typed.com> wrote: > > My example wasn't quite the one I intended (although I think it should > work as well, and it's simpler). Here's the sort of example I really intended: > > data Bar :: forall (j :: forall k. k -> Maybe k) (a :: Type). Proxy (j a) -> Type > > I would expect > > Bar :: Proxy ('Just Int) -> Type > > or, to abuse notation a bit, > > Bar @'Just @Int > > to be Typeable. What I'm really suggesting is that we should distinguish between things that are typeable and > things that can be decomposed into typeable components. We already make a limited distinction > here. For example, we have > > 'Just :: forall a. a -> Maybe a > > 'Just itself cannot be Typeable, but once it's applied to a kind variable, it is Typeable. > 'Just @Int is Typeable even though that (kind) application cannot be broken with App. Similarly, I'd expect > Foo 'Just to be Typeable even though that (type) application cannot be broken with App (or Fun). > > Putting things in terms of fingerprints, we can offer type-indexed fingerprints > > newtype Finger a = Finger Fingerprint > > for anything we can fingerprint. Is there any difficulty fingerprinting types like Foo 'Just and > Bar @'Just @Int? Fingerprints are useful for lots of applications where decomposition isn't > necessary. > > On Sunday, September 24, 2017 1:16:37 PM EDT Richard Eisenberg wrote: >> The problem is that to get Typeable (Foo 'Just), we need Typeable 'Just. However, the kind parameter for Typeable 'Just would be (forall a. a -> Maybe a), making the full constraint Typable (forall a. a -> Maybe a) 'Just. And saying that would be impredicative. In other contexts, 'Just *can* be Typeable, but it's 'Just invisibly instantiated at some monotype for `a`. >> >> So I think that this boils down to impredicativity and that the implementation is doing the right thing here. >> >> Richard >> >>> On Sep 24, 2017, at 5:45 AM, David Feuer <david(a)well-typed.com> wrote: >>> >>> data Foo :: (forall a. a -> Maybe a) -> Type >>> >>> Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? >>> >>> David Feuer >>> Well-Typed, LLP >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >

1 0

Why isn't this Typeable?
by David Feuer 25 Sep '17

25 Sep '17

data Foo :: (forall a. a -> Maybe a) -> Type Neither Foo nor Foo 'Just is Typeable. There seems to be a certain sense to excluding Foo proper, because it can't be decomposed with Fun. But why not Foo 'Just? Is there a fundamental reason, or is that largely an implementation artifact? David FeuerWell-Typed, LLP

2 3

Re: RTS changes affect runtime when they shouldn’t
by David Feuer 24 Sep '17

24 Sep '17

I think changes to the RTS, code generator, and general heap layout are exactly where we *do* want to worry about these very low-level details. Changes in type checking, desugaring, core-to-core, etc., probably are not, because it's just too hard to tease out the relationship between what they do and what instructions are emitted in the end. David FeuerWell-Typed, LLP -------- Original message --------From: Sven Panne <svenpanne(a)gmail.com> Date: 9/24/17 2:00 PM (GMT-05:00) To: Joachim Breitner <mail(a)joachim-breitner.de> Cc: ghc-devs(a)haskell.org Subject: Re: RTS changes affect runtime when they shouldn’t 2017-09-23 21:06 GMT+02:00 Joachim Breitner <mail(a)joachim-breitner.de>: > what I want to do is to reliably catch regressions. The main question is: Which kind of regressions do you want to catch? Do you care about runtime as experienced by the user? Measure the runtime. Do you care abou code size? Measure the code size. etc. etc. Measuring things like the number of fetched instructions as an indicator for the experienced runtime is basically a useless exercise, unless you do this on ancient RISC processors, where each instruction takes a fixed number of cycles. > What are the odds that a change to the Haskell compiler (in particular to > Core2Core > transformations) will cause a significant increase in runtime without a > significant increase in instruction count? > (Honest question, not rhetoric). > The odds are actually quite high, especially when you define "significant" as "changing a few percent" (which we do!). Just a few examples from current CPUs: * If branch prediction has not enough information to do this better, it assumes that backward branches are taken (think: loops) and forward branches are not taken (so you should put "exceptional" code out of the common, straight-line code). If by some innocent looking change the code layout changes, you can easily get a very measurable difference in runtime even if the number of executed instructions stays exactly the same. * Even if the number of instructions changes only a tiny bit, it could be the case that it is just enough to make caching much worse and/or make the loop stream detector fail to detect a loop. There are lots of other scenarios, so in a nutshell: Measure what you really care about, not something you think might be related to that. As already mentioned in another reply, "perf" can give you very detailed hints about how good your program uses the pipeline, caches, branch prediction etc. Perhaps the performance dashboard should really collect these, too, this would remove a lot of guesswork.

1 0