- ghc-devs - Haskell.org

magicDict
by Simon Peyton Jones 26 Apr '21

26 Apr '21

Ed, and other ghc-devs We are busy tidying up magicDict, and making it much more type-safe: see * https://gitlab.haskell.org/ghc/ghc/-/issues/16646 * https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5573 As part of that change we're think of changing its currently-rather-obscure name. I rather favour "reflectDict". Any other views? Simon

5 14

[ANNOUNCE] GHC 9.2.1-alpha2 released
by Ben Gamari 22 Apr '21

22 Apr '21

Hi all, The GHC developers are very happy to announce the availability of the second alpha release in the 9.2.1 series. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-alpha2 GHC 9.2 will bring a number of exciting features including: * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [-hi profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Introduction of Haddock documentation support in TemplateHaskell (#5467) * Proper support for impredicative types in the form of Quick-Look impredicativity. * A native code generator backend for AArch64. This pre-release brings nearly 50 fixes relative to the first alpha, although the long-awaited ARM NCG backend hasn't quite landed yet. As always, do give this a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

Integrating more base Instances in the `stock` deriving strategy?
by Hécate 15 Apr '21

15 Apr '21

Hi folks! I would like to start a discussion (if it hasn't already been done) around the idea of integrating the various type-classes that Base offers, that are hidden behind language extensions, in the `stock` deriving strategy. I wasn't around when it was all implemented, but I've always lived with it in my code bases, and I'd like to know if there are deeper issues pertaining to their exclusion from the `stock` deriving strategy. Here is the link to the discussion ticket: https://gitlab.haskell.org/ghc/ghc/-/issues/19707 Cheers, and have a nice week! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

1 0

instance {Semigroup, Monoid} (Bag a) ?
by Richard Eisenberg 15 Apr '21

15 Apr '21

Hi devs, In the work on simplifying the error-message infrastructure (heavy lifting by Alfredo, in cc), I've been tempted (twice!) to add > instance Semigroup (Bag a) where > (<>) = unionBags > > instance Monoid (Bag a) where > mempty = emptyBag to GHC.Data.Bag. The downside to writing these is that users might be tempted to write e.g. mempty instead of emptyBag, while the latter gives more information to readers and induces less manual type inference (to a human reader). The upside is that it means Bags work well with Monoid-oriented functions, like foldMap. I favor adding them, and slipped them into !5509 (a big commit with lots of other stuff). Alfredo rightly wondered whether this decision deserved more scrutiny, and so I'm asking the question here. What do we think? Thanks, Richard

7 7

What's the modern way to apply a polymorphic function to a Dynamic value in GHC 8.8 and onwards?
by YueCompl 13 Apr '21

13 Apr '21

Dear Cafe and GHC devs, There used to be a "principled way with pattern match on the constructor": ```hs data Dynamic where Dynamic :: Typeable a => a -> Dynamic apD :: Typeable f => (forall a. a -> f a) -> Dynamic -> Dynamic apD f (Dynamic a) = Dynamic $ f a ``` Source: https://www.reddit.com/r/haskell/comments/2kdcca/q_how_to_apply_a_polymorph… But now with GHC 8.8 as in my case, `Dynamic` constructor has changed its signature to: ```hs Dynamic :: forall a. TypeRep a -> a -> Dynamic ``` Which renders the `apD` not working anymore. And it seems missing dependencies now for an older solution Edward KMETT provides: ```hs apD :: forall f. Typeable1 f => (forall a. a -> f a) -> Dynamic -> Dynamic apD f a = dynApp df a where t = dynTypeRep a df = reify (mkFunTy t (typeOf1 (undefined :: f ()) `mkAppTy` t)) $ \(_ :: Proxy s) -> toDyn (WithRep f :: WithRep s (() -> f ())) ``` Source: https://stackoverflow.com/questions/10889682/how-to-apply-a-polymorphic-fun… So, how can I do that nowadays? Thanks, Compl

4 9

Newcomer looking for help with changes to kind system
by Shant Hairapetian 07 Apr '21

07 Apr '21

Hello, I’m a master’s student working on implementing the changes outlined in “Kinds are Calling Conventions“ ( https://www.microsoft.com/en-us/research/uploads/prod/2020/03/kacc.pdf) I have been working directly with Paul Downen but have hit some roadblocks. To sum up the changes to the kind system, I am attempting to modify the “TYPE” type constructor to accept, rather than just a RuntimeRep, a record type (called RuntimeInfo) comprised of a RuntimeRep and a CallingConv (calling convention). The calling convention has an “Eval” constructor which accepts a levity (effectively moving the levity information from the representation to the calling convention. LiftedRep and UnliftedRep would also be collapsed into a single PtrRep constructor) and a “Call” constructor (denoting the arity of primitive, extensional functions, see: Making a Faster Curry with Extensional Types <https://www.microsoft.com/en-us/research/uploads/prod/2019/07/arity-haskell…>) which accepts a list of RuntimeRep’s. I have created and wired-in the new RuntimeInfo and CallingConv types in GHC.Builtin.Types, as well as the corresponding primitive types in GHC.Builtin.Types.Prim and have modified the “TYPE” constructor to accept a RuntimeInfo rather than a RuntimeRep. My issue (well, one of my issues) is that, for unboxed tuples, though the actual kind is being built up correctly, the expected type is still in the old (or current) representation. (expected) Couldn't match type: 'TupleRep ('[] @RuntimeRep) (actual) with: 'RInfo ('TupleRep ('[] @RuntimeRep)) 'GHC.Types.ConvEval I have not been able to locate where this expected kind is being constructed. Any help this issue or general guidance would be greatly appreciated. Thanks, Shant

2 4

How to ensure optimization for large immutable vectors to be shared w.r.t. Referential Transparency
by YueCompl 06 Apr '21

06 Apr '21

Hello Cafe and respected GHC Devs, I would like to ensure some immutable vectors (can be quite large) are always shared instead of copied, and I think that should be straight forward w.r.t. referential transparency we enjoy. In an attempt to determine whether two immutable vectors can be treated as the same one to enable specific optimizations for that case, I tried to use ST to determine their respective backing foreign ptrs for comparison. But appears it can be copied when wrapped in a newtype, I wonder why it is the case, and how to avoid the copy? Here's my minimum reproducible snippet: ```hs λ> :set -XBangPatterns λ> λ> :set -package vector package flags have changed, resetting and loading new packages... λ> λ> import Prelude λ> λ> import Control.Monad.ST λ> import qualified Data.Vector.Storable as VS λ> λ> :{ λ| λ| newtype SomeVector = SomeVector (VS.Vector Int) λ| λ| isSameVector :: SomeVector -> SomeVector -> Bool λ| isSameVector (SomeVector !x) (SomeVector !y) = runST $ do λ| mx(a)(VS.MVector !x'offset !x'fp) <- VS.unsafeThaw x λ| my(a)(VS.MVector !y'offset !y'fp) <- VS.unsafeThaw y λ| _ <- VS.unsafeFreeze mx λ| _ <- VS.unsafeFreeze my λ| return $ x'offset == y'offset && x'fp == y'fp λ| λ| :} λ> λ> let !v = VS.fromList [3,2,5] in isSameVector (SomeVector v) (SomeVector v) False λ> λ> let !v = SomeVector (VS.fromList [3,2,5]) in isSameVector v v True λ> ``` Thanks with best regards, Compl

3 11

Re: How does GHC implement layout?
by Ian Lynagh 06 Apr '21

06 Apr '21

On Mon, Apr 05, 2021 at 05:09:21PM +0000, Simon Peyton-Jones wrote: > Two people who may know more about the alternative layout rule are Simon Marlow and Ian Lynagh (cc'd). It was originally designed by John Meacham: https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html It isn't exactly equivalent to the Haskell layout rule, but it's fairly close and much simpler (due to not having the "on a parse error" case). Thanks IAn

3 2

How does GHC implement layout?
by Alexis King 05 Apr '21

05 Apr '21

Hi all, I’m wondering if there are any resources that discuss the design of GHC’s implementation of layout. (I haven’t been able to find any.) From looking at the code, here’s what I’ve gathered so far: * Layout is implemented in the lexer (compiler/GHC/Parser/Lexer.x). * The implementation is similar in some respects to the approach described in the Haskell Report, but still fairly different. Virtual braces and semicolons are inserted during the lexing process itself with the assistance of Alex lexer states (aka “start codes”). * In order to handle particularly tricky cases like if e then do x; y else z where the virtual close brace must be inserted in the middle of a line, tokens such as in and else are given special context-sensitive treatment. This appears to be quite subtle. Overall, I can mostly follow the code, but I still have a few unanswered questions: * The layout-related code consistently uses the phrase “alternative layout rule”—what does “alternative” mean here? Does it refer to GHC’s implementation of layout? Or maybe it refers to NondecreasingIndentation? It isn’t clear. * The implementation of layout seems quite complex, in large part because it has to worry about parsing concerns in the lexer in order to handle tricky cases like the one I provided above. Is there are reason all this is done in the lexer, rather than deferring some more of the work to the parser? I’ve found remarkably little information about implementing layout in general, so perhaps I’m missing some resources or keywords to search for, but any information or perspectives would be appreciated! Thanks, Alexis

5 5

GHC Proposal: GHC Maintainer Preview
by Hécate 03 Apr '21

03 Apr '21

Hi everyone! I would like to share with you all the proposal I opened, called "GHC Maintainer Preview", to shape the release schedule of our beloved compiler. The concept is that we let a certain period of time pass between the final "release" of a major (X.Y) GHC version, and its official, public, user-targeting release, so that we can focus our efforts in helping library maintainers to migrate and change their code to accommodate the whatever breaking change the new major version introduces. The proposal is located here: https://github.com/ghc-proposals/ghc-proposals/pull/417 Have a nice week-end! -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

1 0