- Glasgow-haskell-users

[ANN] Cabal-3.6.0.0
by Emily Pillmore 15 Aug '21

15 Aug '21

Hello All, The Cabal team is excited to announce the release of Cabal-3.6.0.0! This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself. For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548. If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat ( http://libera.chat/ ) to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org ( http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together! For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues. Happy hacking! Emily

5 10

[Haskell] [ANNOUNCE] GHC 8.10.6 released
by Zubin Duggal 14 Aug '21

14 Aug '21

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)) - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.…. As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

1 0

InstanceSigs -- rationale for the "must be more polymorphic than"
by Anthony Clayden 11 Aug '21

11 Aug '21

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

3 6

Constraints on type synonyms
by Anthony Clayden 21 Jun '21

21 Jun '21

Consider > pattern PPoint :: Floating a => a -> a -> (a, a) -- => () > pattern PPoint x y = (x, y) > originP = PPoint 0 0 > scaleP w (PPoint x y) = PPoint (w*x) (w*y) Inferred `scaleP :: Floating a => a -> (a, a) -> (a, a)` -- so more restrictive than the `Num a` that would be inferred usually for `scaleP`'s `(*)` operator. Ok what's the type-level analogue for `PPoint`, so that I can give signatures, instances, etc for methods using it? The type is not this: > type CPoint a = Floating a => (a, a) (Needs `RankNTypes` to put a constraint in RHS of a type synonym.) This seems to get accepted: > scaleP :: a -> CPoint a -> CPoint a Inferred `scaleP :: Floating a => a -> CPoint a -> (a, a)` -- that un-expanded `CPoint a` hints at a lurking danger. I couldn't for example write the equation for `scaleP` with a type annotation > scaleP w (PPoint x y) = PPoint (w*x) (w*y) :: CPoint a Despite the annotation giving the result type exactly per the signature, this gives 'rigid type variable' rejections. This works (needs `ScopedTypeVariables`) > scaleP (w :: a) (PPoint x y) = PPoint (w*x) (w*y) :: CPoint a What I especially want is instances and constraints: > instance C1 (CPoint a) -- * Illegal qualified type: Floating a => (a, a) > -- * In the expansion of type synonym `CPoint' > instance (C1 (CPoint a)) => C2 a -- * Illegal qualified type: Floating a => (a, a) > -- GHC doesn't yet support impredicative polymorphism (Needs `FlexibleInstances` to appear in the instance head, `FlexibleContexts` to appear in the constraint.) But I don't want to embed a qualified type in the instance head nor constraints, I want the expansion to be > instance (Floating a) => C1 (a, a) > instance (C1 (a, a), Floating a) => C2 a It's kinda the constraint is 'outside' the constructed type; as if the synonym were given by > type (Floating a) => CPoint a = (a, a) With the idea that when the compiler is expanding `CPoint a`, it floats the associated constraint out to the context the synonym call appears in. That is, I'm treating the expansion as very early in the compiler pipeline, just after syntax checking, before type inference/checking. If that constraint-outside syntax in the type synonym decl seems familiar, you might have seen it discussed briefly in [Jones, Morris, Eisenberg 2020 Partial Type Constructors], Section 7 Related Work 'Datatype contexts in Haskell'. Let me emphasise I'm talking here about type synonyms _not_ Datatypes. That constraint-outside syntax got rejected very early in the history of Haskell, apparently because nobody could give an adequate specification. Is my expand-it-as-syntax proposal not viable? AntC

1 0

A default setting for DynFlags.Settings?
by Kwanghoon Choi 20 Jun '21

20 Jun '21

Hi Glasgow-haskell-users, I am wondering if there is a declaration of a default setting value for DynFlags.Settings: Settings :: GhcNameVersion -> FileSettings -> Platform -> ToolSettings -> PlatformMisc -> PlatformConstants -> [(String, String)] -> Settings in DynFlags - https://www.stackage.org/haddock/nightly-2019-09-04/ghc-lib-parser-8.8.0.20… . I am attempting to use Lexer.lexer, which is provided by the ghc-parser-lib package. To make Lexer.lexer run, I seem to have such a setting value. I managed to fill it by myself as defaultSettings (Line 82) in the following source code: - https://github.com/kwanghoon/hslexer/blob/master/app/Main.hs with a sequence of meaningless 0, False, "", and [], which are not relevant to the usage of Lexer.lexer, I think. Are there any better ways to make a setting value just for the usage of Lexer.lexer? Anyway, it is great to see that it is quite easy to make use of the Haskell lexer by using GHC and the ghc-parser-lib package! Kinds regards Kwanghoon

1 0

[Haskell] [ANNOUNCE] GHC 8.10.5 released
by Zubin Duggal 10 Jun '21

10 Jun '21

The GHC team is very pleased to announce the availability of GHC 8.10.5. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.5/). This release adds native ARM/Darwin support, as well as bringing performance improvements and fixing numerous bugs of varying severity present in the 8.10 series: - First-class support for Apple M1 hardware using GHC's LLVM ARM backend - Fix a bug resulting in segmentation faults where code may be unloaded prematurely when using the parallel garbage collector (#19417) along with other bugs in the GC and linker (#19147, #19287) - Improve code layout fixing certain performance regressions (#18053) and other code generation bug fixes (#19645) - Bug fixes for signal handling when using the pthread itimer implementation. - Improvements to the specializer and simplifier reducing code size and and memory usage (#17151, #18923,#18140, #10421, #18282, #13253). - Fix a bug where typechecker plugins could be run with an inconsistent typechecker environment (#19191). - Fix a simplifier bug which lead to an exponential blow up and excessive memory usage in certain cases A complete list of bug fixes and improvements can be found in the release notes: [release notes](https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10… As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new).

2 2

[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

Guarantees about shape of Generic's Rep
by Alexey Khudyakov 20 Apr '21

20 Apr '21

Hi! I have a question about guarantees that GHC provides about shape of generic representation of data type. To be more concrete if we have two single-constructor data types with N fields will their binary trees built from (:*:) be balanced in same way? Same for (:+:) binary tree. I want to use generics to write conversions between data types with same shape: > λ> data Foo = Foo Int Char deriving (Show,Generic) > λ> to . coerce . from $ Foo 1 'c' :: (Int,Char) > (1,'c') > λ> to . coerce . from $ Foo 1 'c' :: (Sum Int,Char) > (Sum {getSum = 1},'c') > λ> to . coerce . from $ (Sum (1::Int), 'c') :: Foo > Foo 1 'c' Coercion between Reps for different types is only possible when they have same shape. Quick experiments shows that they're same. I think that they should be same but documentation is silent about this. Thanks in advance, Alexey

1 0

How to user-define a type equality constraint?
by Anthony Clayden 06 Apr '21

06 Apr '21

Type equality `(~)` is a fine constraint. It's mildly annoying I need either `-XGADTs` or `-XTypeFamilies` to use it -- because I don't otherwise need those extensions. OTOH it's not H2010 so it needs to be switched on somehow. I see the Committee is discussing what to do. It's to be enabled by `-XTypeOperators`. That would be just as annoying for me -- I don't otherwise use Type Operators. If TypeOperators is to be the default for GHC2021, that more or less convinces me against GHC2021. (I'm not a newbie/I want to fine-tune which extensions I'm using.) @int-index says https://mail.haskell.org/pipermail/ghc-steering-committee/2021-April/002373… > What convention do you have in mind? (~) is not that different from, say, (+), which is a valid type operator: I believe `(~)` is different in that I can't define it in user code(?) Indeed: > (~) is a special, magical constraint, like Coercible and Typeable. ..., the idea is to (eventually) require an explicit import of Data.Type.Equality to indicate the use of (~) in the code, I'd be happy to not import `(~)`/not use TypeOperators, and define an ordinary typeclass/constraint, say `TypeCast a b`. There's a `TypeCast` defined in HList 2004, but it needs FunDeps; more awkwardly it needs a method and for that method to appear in term-level code. Can I user-define a conventional type-class that behaves more like `(~)`? (The "convention I have in mind" is that already in H2010,`~` is a special symbol for irrefutable patterns. Then I'd prefer constraint `(~)` is also special syntax; and at term level I'd prefer it be available as a monadic prefix operator.) AntC

4 3

Re: How to user-define a type equality constraint?
by Anthony Clayden 06 Apr '21

06 Apr '21

> But why does this matter? Because I want the semantics of that equality constraint, without switching on any of these, which I don't otherwise use: GADTs TypeFamilies TypeOperators And if that means I can't use infix `~` in my constraints, I'll put up with that. (I'd user-define a conventional class, say `TypeCast`. Could be that has to be defined in terms of `~`, in which case I'd put that in a shim module as the only place with those extensions.)

2 1