- ghc-devs - Haskell.org

Compiling libraries
by Simon Peyton Jones 30 Apr '21

30 Apr '21

Ben and other friends What is the approved way to build libraries with (and for) a compiler that I've just built? I tried this: bash$ cabal v2-install --with-ghc=/home/simonpj/code/ghc-9.2-branch/inplace/bin/ghc-stage2 streamly --allow-newer but it failed with Data/Primitive/Types.hs:273:844: error: * Couldn't match expected type 'Word#' with actual type 'Word8#' * In the fourth argument of 'shimmedSetWord8Array#', namely 'x#' (This was for a compiler built from the ghc-9.2 branch.) I'd like to be able to do the same for HEAD. I need to do this to help with the numerous tickets asking about library regressions. For example, I want to be able repoduce @harendra's example<https://gitlab.haskell.org/ghc/ghc/-/issues/19557#note_348969>, but I can't because I can't build streamly. Thanks! Simon

4 4

[ANNOUNCE] Experimental Windows GHC 8.10.5 binary release. Supports Haskell DLLs.
by kyra 29 Apr '21

29 Apr '21

An experimental Windows GHC 8.10.5 64-bit Visual C/Native Windows SDK binary compatible distribution is released. Features: Supports Haskell DLLs. Both static and dynamic compilers are shipped. Uses LLVM tools exclusively, hence linking is blazing fast compared to the stock distro. Is position-independent (can be loaded to any address, not only the lower 2GBs) and generates position-independent code. Based on and targets Microsoft Visual C runtime and native Windows SDK. The "full" variant of distro contains 438 extra prebuilt packages and a set utilities, including not only the mandatory cabal, stack, Happy and Alex, but also linters, formatters, preprocessors, and even beasts like pandoc, haskell-language-server and even Agda compiler. Distribution site: https://awson.github.io/ghc-nw/. Cheers, K. Briantsev (aka awson)

1 0

simple Haskell help needed on #19746
by Richard Eisenberg 28 Apr '21

28 Apr '21

Hi devs, tl;dr: Is there any (efficient) way to get the String consumed by a `reads`? I'm stuck in thinking about a fix for #19746. Happily, the problem is simple enough that I could assign it in the first few weeks of a Haskell course... and yet I can't find a good solution! So I pose it here for inspiration. The high-level problem: Assign correct source spans to options within a OPTIONS_GHC pragma. Current approach: The payload of an OPTIONS_GHC pragma gets turned into a String and then processed by GHC.Utils.Misc.toArgs :: String -> Either String [String]. The result of toArgs is either an error string (the Left result) or a list of lexed options (the Right result). A little-known fact is that Haskell strings can be put in a OPTIONS_GHC pragma. So I can write both {-# OPTIONS_GHC -funbox-strict-fields #-} and {-# OPTIONS_GHC "-funbox-strict-fieds" #-}. Even stranger, I can write {-# OPTIONS_GHC ["-funbox-strict-fields"] #-}, where GHC will understand a list of strings. While I don't really understand the motivation for this last feature (I posted #19750 about this), the middle option, with the quotes, seems like it might be useful. Desired approach: change toArgs to have this type: RealSrcLoc -> String -> Either String [Located String], where the input RealSrcLoc is the location of the first character of the input String. Then, as toArgs processes the input, it advances the RealSrcLoc (with advanceSrcLoc), allowing us to create correct SrcSpans for each String. Annoying fact: Not all characters advance the source location by one character. Tabs and newlines don't. Perhaps some other characters don't, too. Central stumbling block: toArgs uses `reads` to parse strings. This makes great sense, because `reads` already knows how to convert Haskell String syntax into a proper String. The problem is that we have no idea what characters were consumed by `reads`. And, short of looking at the length of the remainder string in `reads` and comparing it to the length of the input string, there seems to be no way to recreate this lost information. Note that comparing lengths is slow, because we're dealing with Strings here. Once we know what was consumed by `reads`, then we can just repeatedly call advancedSrcLoc, and away we go. Ideas to get unblocked: 1. Just do the slow (quadratic in the number of options) thing, looking at the lengths of strings often. 2. Reimplement reading of strings to return both the result and the characters consumed 3. Incorporate the parsing of OPTIONS_GHC right into the lexer It boggles me that there isn't a better solution here. Do you see one? Thanks, Richard

3 4

External STG Interpreter blog post
by Csaba Hruska 27 Apr '21

27 Apr '21

Hello, I've written a blog post about GHC-WPC's external stg interpreter. https://www.patreon.com/posts/external-stg-49857800 Feedback is welcome. Cheers, Csaba

3 4

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 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 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