- ghc-devs - Haskell.org

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

23 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 16 Apr '21

16 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 14 Apr '21

14 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 08 Apr '21

08 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 07 Apr '21

07 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 06 Apr '21

06 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 04 Apr '21

04 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

Error and Warning Messages practical migration guidelines
by Alfredo Di Napoli 03 Apr '21

03 Apr '21

*TL;DR If you recently had merge conflicts related to error and messages in GHC, here I give migration guidelines. Otherwise, feel free to ignore this email.* Good morning all, If you had some work-in-progress branch that was emitting errors or warnings (either adding new ones or modifying existing ones), chances are you noticed that now the API and types changed slightly and you had to deal with the conflicts. What you noticed was the initial chunk of work for [#18516]. See the [Wiki] for more info. Our work is not done yet, but the API changed enough to warrant me writing this little email to help folks out with their rebasing (because we are *all* rebasing at least daily, aren't we? :) ). First of all, sorry for all the churning! I am trying to stabilise the external interfaces (i.e the type signatures of the GHC API functions) so things will become a bit more stable in the future. In the meantime, I wanted to give you some practical guidelines on how to migrate your code: * Rather than "errors" or "warnings", we are trying to shift our vocabulary to talk about "diagnostics". In GHC this distinction is not so "strict", in the sense warnings can become errors and errors can become warnings if deferred. Rather we talk about diagnostics, i.e. facts about the compiled program, that can be, at the very end, classified as errors or warnings based on their `Severity`; * *If you skip this whole email, read just this:* the key insight is that there is a clear separation between the *reason* this diagnostic was created and the final `Severity`! Example: we emit a diagnostic because `Opt_WarnMonomorphism` is on. That's the raison d'être of this diagnostic. Therefore, we would create a new message (more on this later) with reason `WarningWithFlag Opt_WarnMonomorphism`; * A `Severity` of a diagnostic is computed using the `DynFlags`, because that's the only way to correctly classify a diagnostic. Back to our little example above, if `Opt_WarnMonomorphism` was set as fatal (or -Werror enabled), now the final `Severity` of the diagnostic above would be `SevError`. That's why it's important to keep them separate; * We separated out the logging messages with the diagnostics proper, this is why we now have a new [MessageClass] type which can be used to log all sort of messages (debug ones, informational etc) *and* diagnostics, which has a dedicated type constructor; * If you want to emit something which is not an error or a warning, use [putLogMsg]. Here is an example: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Core/Lint.hs#… (we could argue if the example shouldn't be a diagnostic, but we didn't go that far in the refactoring yet, this is just to give you an idea of the usage); * The most general function which can be used to produce a diagnostic is [mkMsgEnvelope], which takes as input the `DynFlags` to compute the `Severity` under the hood. * You can't just pass a random `DynFlags` to `mkMsgEnvelope`, but the former should be acquired as close as possible to the construction/emission site of the diagnostics. This is because `DynFlags` evolves and are mangled all the time inside GHC, and we want to produce the `Severity` using the most faithful "snapshot" of the state of the world at the time the diagnostic was produced. * Most of the times you don't have to worry about all of this; if you know for sure a diagnostic is an error and is not recoverable, then you can use `mkMsgErrorEnvelope` that doesn't need the `DynFlags` and always produces a diagnostic with `SevError` and `ErrorWithoutFlags`. * Once #18516 will be completed, this will require a bit less cognitive overhead. We will have proper types (not SDocs or generic `DecoratedMessage`s), and all the working GHC hacker will have to worry about would be to create a brand new Haskell type for the diagnostic, give it a `Diagnostic` instance (or extend the instance declaration if that's an existing type) and then just call whichever high-level API we will have available. Hope this helps! Alfredo [#18516]: https://gitlab.haskell.org/ghc/ghc/-/issues/18516 [Wiki]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Errors-as-(structured)-values [MessageClass]: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Types/Error.h… [putLogMsg]: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Logger.… [mkMsgEnvelope]: https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Utils/Error.h…

1 0