From anthony_clayden at clear.net.nz Fri Apr 2 00:12:30 2021 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 2 Apr 2021 13:12:30 +1300 Subject: How to user-define a type equality constraint? Message-ID: 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.html > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Apr 6 02:49:40 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 6 Apr 2021 02:49:40 +0000 Subject: How to user-define a type equality constraint? In-Reply-To: References: Message-ID: <010f0178a515eb07-1f713804-df22-496f-91fc-b1f15e5baa1c-000000@us-east-2.amazonses.com> > On Apr 1, 2021, at 8:12 PM, Anthony Clayden wrote: > > Can I user-define a conventional type-class that behaves more like `(~)`? I don't think so. But why does this matter? I can't define `Char` in user code, but it's exported from the Prelude and requires no extensions. While I can define Eq in user code, I can't make `deriving` work with my version. I can't define `error` in user code. There are many others, I'm sure. So: why does this matter? Thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Apr 6 03:07:53 2021 From: david.feuer at gmail.com (David Feuer) Date: Mon, 5 Apr 2021 23:07:53 -0400 Subject: How to user-define a type equality constraint? In-Reply-To: <010f0178a515eb07-1f713804-df22-496f-91fc-b1f15e5baa1c-000000@us-east-2.amazonses.com> References: <010f0178a515eb07-1f713804-df22-496f-91fc-b1f15e5baa1c-000000@us-east-2.amazonses.com> Message-ID: `Char` is defined in user code. What you really can't define are Char# and TYPE, and you can't modify `RuntimeRep`. Speaking of `Char#`, I see that in 9.0, at least, it has kind TYPE 'WordRep. Why is that not Word32Rep? On Mon, Apr 5, 2021, 10:50 PM Richard Eisenberg wrote: > > > On Apr 1, 2021, at 8:12 PM, Anthony Clayden > wrote: > > Can I user-define a conventional type-class that behaves more like `(~)`? > > > I don't think so. > > But why does this matter? I can't define `Char` in user code, but it's > exported from the Prelude and requires no extensions. While I can define Eq > in user code, I can't make `deriving` work with my version. I can't define > `error` in user code. There are many others, I'm sure. > > So: why does this matter? > > Thanks, > Richard > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Apr 6 11:44:14 2021 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 6 Apr 2021 23:44:14 +1200 Subject: How to user-define a type equality constraint? Message-ID: > 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Tue Apr 6 13:24:01 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Tue, 6 Apr 2021 13:24:01 +0000 Subject: How to user-define a type equality constraint? In-Reply-To: References: Message-ID: <010f0178a75ab0dd-4c206cc7-830e-428e-95eb-3447a03cfc29-000000@us-east-2.amazonses.com> > On Apr 6, 2021, at 7:44 AM, Anthony Clayden wrote: > > > 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.) > A shim module would work for you here, indeed. Individuals' opinions of extensions will differ, but TypeOperators is much less powerful than either of the others: it affects only parsing, and in a fully backward-compatible way. Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Apr 6 14:05:48 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 6 Apr 2021 10:05:48 -0400 Subject: How to user-define a type equality constraint? In-Reply-To: References: <010f0178a515eb07-1f713804-df22-496f-91fc-b1f15e5baa1c-000000@us-east-2.amazonses.com> Message-ID: That sounds like a bug/oversight! Is that not fixed in 9.2? On Mon, Apr 5, 2021 at 11:08 PM David Feuer wrote: > `Char` is defined in user code. What you really can't define are Char# and > TYPE, and you can't modify `RuntimeRep`. Speaking of `Char#`, I see that in > 9.0, at least, it has kind TYPE 'WordRep. Why is that not Word32Rep? > > On Mon, Apr 5, 2021, 10:50 PM Richard Eisenberg wrote: > >> >> >> On Apr 1, 2021, at 8:12 PM, Anthony Clayden >> wrote: >> >> Can I user-define a conventional type-class that behaves more like `(~)`? >> >> >> I don't think so. >> >> But why does this matter? I can't define `Char` in user code, but it's >> exported from the Prelude and requires no extensions. While I can define Eq >> in user code, I can't make `deriving` work with my version. I can't define >> `error` in user code. There are many others, I'm sure. >> >> So: why does this matter? >> >> Thanks, >> Richard >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.skladnoy at gmail.com Tue Apr 20 17:39:33 2021 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Tue, 20 Apr 2021 20:39:33 +0300 Subject: Guarantees about shape of Generic's Rep Message-ID: 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 From ben at well-typed.com Fri Apr 23 03:58:44 2021 From: ben at well-typed.com (Ben Gamari) Date: Thu, 22 Apr 2021 23:58:44 -0400 Subject: [ANNOUNCE] GHC 9.2.1-alpha2 released Message-ID: <874kfxps7i.fsf@smart-cactus.org> 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-unlifted-datatypes.rst [-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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: