April 2021 - Glasgow-haskell-users

[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

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