From jmct at haskell.foundation Tue Jan 2 19:05:22 2024 From: jmct at haskell.foundation (Jose Calderon) Date: Tue, 2 Jan 2024 14:05:22 -0500 Subject: [Haskell-cafe] Technical Working Group: Call for Volunteers Message-ID: Hello, The Haskell Foundation Technical Working Group (TWG) serves as an advisory organization for both the HF management and the Haskell community as a whole, by evaluating specific proposals for projects that can have broad, ecosystem-wide effects. These proposals can be: - Community RFCs that seek the community’s input on a project - Community projects that will be executed primarily by the proposer, but seek administrative or financial support from the HF - HF projects that a community member would like us to execute - Other topics of relevance to the community Volunteers wanted! We presently have three openings on the working group, and we’re seeking volunteers. Members are expected to attend a monthly meeting, to participate in and moderate discussion threads regarding specific proposals, and to evaluate proposals for their technical merits. From time to time, committee members may also be asked to help a community member revise their proposal. The ability to communicate well and respectfully is important for any potential member. These discussions have a real impact on the Haskell ecosystem, so this is an opportunity to give back in a meaningful way. If you are interested, or if you know someone who might be, please get in touch with me at director at haskell.foundation! You don’t have to be a long-term Haskeller, or someone who is deeply embedded in Haskell development - we have members with this background already. If you are unsure as to whether you would fit in, please get in touch, and we can have a chat about it. We would like to have members with diverse backgrounds, professional experiences, and knowledge. All self-nominations must be submitted by the end of the day on Jan 12th 2024. Best wishes, Jose -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Tue Jan 9 09:55:19 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Tue, 9 Jan 2024 15:25:19 +0530 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.6.4 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.6.4. Binary distributions, source distributions, and documentation are available on the [release page](https://www.haskell.org/ghc/download_ghc_9_6_4.html). This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * A fix for a bug where certain warnings flags were not recognised (#24071) * Fixes for a number of simplifier bugs (#23952, #23862). * Fixes for compiler panics with certain package databases involving unusable units and module reexports (#21097, #16996, #11050). * A fix for a typechecker crash (#24083). * A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746). * Fixes for some memory leaks in GHCi (#24107, #24118) * And a few other fixes A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy hacking! -Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.6.4/docs/users_guide/9.6.4-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From zoran.bosnjak at via.si Wed Jan 10 10:25:23 2024 From: zoran.bosnjak at via.si (zoran.bosnjak at via.si) Date: Wed, 10 Jan 2024 11:25:23 +0100 Subject: [Haskell-cafe] restore type from existential Message-ID: <237b71ae77405c206277e3a74e4019ef@via.si> Dear haskellers, if for example I have the following (simplified) situation: import GHC.TypeLits type MyTypes = '[ () -- index 0 , Char -- index 1 , Int -- index 2 ] data SNat (n :: Nat) where SZ :: SNat 0 SS :: SNat n -> SNat (n+1) data Wrap where WrapUnsafe :: SNat n -> t -> Wrap t1 = WrapUnsafe SZ () :: Wrap t2 = WrapUnsafe (SS SZ) 'x' :: Wrap t3 = WrapUnsafe (SS (SS SZ)) (1::Int) :: Wrap Is it possible to have an 'unwrap' function? That is: to combine MyType types table and the type index... to get the exact type back. Something in the form: unwrapUnsafe :: Wrap -> t unwrapUnsafe (WrapUnsafe (ix::SNat n) (val::t)) = undefined x1 = unwrapUnsafe t1 x2 = unwrapUnsafe t2 x3 = unwrapUnsafe t3 GHC didn't like any of my attempt. Is it even possible? regards, Zoran From godzbanebane at gmail.com Wed Jan 10 11:57:52 2024 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Wed, 10 Jan 2024 13:57:52 +0200 Subject: [Haskell-cafe] restore type from existential In-Reply-To: <237b71ae77405c206277e3a74e4019ef@via.si> References: <237b71ae77405c206277e3a74e4019ef@via.si> Message-ID: Hi Zoran, No, with your given Wrap data type, it would not be possible. The moment you only constraint `t` to be `forall` bound in `WrapUnsafe` and have not other properties, there's really no way to get it out without using `unsafeCoerce`. There are many approaches to achieve being able to "recover" what `t` is. One idea would be to add a list type parameter `ts` to `Wrap` and a constraint to `WrapUnsafe` which says "t is the type at index n in the list ts", i.e. something like ``` type family Index n ts where   Index 0 (t ': _) = t   -- might need your own definition of Nat for the next case   Index (1 + n) (_ ': ts) = Index n ts data Wrap ts where   MkWrap :: SNat n -> Index n ts -> Wrap ts ``` Another (which I personally think is cleaner) would be to entirely skip the `SNat`s and use an "membership proof" instead, i.e. something like ``` data Elem (x :: t) (xs :: [t]) where   Here :: Elem x (x ': xs)   There :: Elem x xs -> Elem x (y ': xs) ``` You could then have ``` data Wrap ts where   MkWrap :: Elem t ts -> t -> Wrap ts t1, t2, t3 :: Wrap MyTypes t1 = MkWrap Here () t2 = MkWrap (There Here) 'x' t3 = MkWrap (There (There Here)) 1 ``` You could then also try to automate the membership proof generation via type classes. If you're going the unsafe approach and going to be `unsafeCoerce`ing, you could also just as well drop the `SNat` and use a raw `Int` instead, because you're the one who's going to be taking care not to `unsafeCoerce` the wrong thing anyways. Cheers, Georgi On 1/10/24 12:25, zoran.bosnjak at via.si wrote: > Dear haskellers, > if for example I have the following (simplified) situation: > > import GHC.TypeLits > > type MyTypes = >     '[ ()    -- index 0 >      , Char  -- index 1 >      , Int   -- index 2 >      ] > > data SNat (n :: Nat) where >     SZ :: SNat 0 >     SS :: SNat n -> SNat (n+1) > > data Wrap where >     WrapUnsafe :: SNat n -> t -> Wrap > > t1 = WrapUnsafe SZ () :: Wrap > t2 = WrapUnsafe (SS SZ) 'x' :: Wrap > t3 = WrapUnsafe (SS (SS SZ)) (1::Int) :: Wrap > > Is it possible to have an 'unwrap' function? That is: to combine > MyType types table and the type index... to get the exact type back. > Something in the form: > > unwrapUnsafe :: Wrap -> t > unwrapUnsafe (WrapUnsafe (ix::SNat n) (val::t)) = undefined > > x1 = unwrapUnsafe t1 > x2 = unwrapUnsafe t2 > x3 = unwrapUnsafe t3 > > GHC didn't like any of my attempt. Is it even possible? > > regards, > Zoran > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From godzbanebane at gmail.com Wed Jan 10 12:00:10 2024 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Wed, 10 Jan 2024 14:00:10 +0200 Subject: [Haskell-cafe] restore type from existential In-Reply-To: <237b71ae77405c206277e3a74e4019ef@via.si> References: <237b71ae77405c206277e3a74e4019ef@via.si> Message-ID: Another thing which I forgot to mention - if you absolutely need to have an existential, i.e. `MyTypes` should not be visible at the top level, you'll need to also include some existential wrapper for the versions of `Wrap` together with a singleton for the type level list, in order to be able to later at runtime recover what the original list of types was. On 1/10/24 12:25, zoran.bosnjak at via.si wrote: > Dear haskellers, > if for example I have the following (simplified) situation: > > import GHC.TypeLits > > type MyTypes = >     '[ ()    -- index 0 >      , Char  -- index 1 >      , Int   -- index 2 >      ] > > data SNat (n :: Nat) where >     SZ :: SNat 0 >     SS :: SNat n -> SNat (n+1) > > data Wrap where >     WrapUnsafe :: SNat n -> t -> Wrap > > t1 = WrapUnsafe SZ () :: Wrap > t2 = WrapUnsafe (SS SZ) 'x' :: Wrap > t3 = WrapUnsafe (SS (SS SZ)) (1::Int) :: Wrap > > Is it possible to have an 'unwrap' function? That is: to combine > MyType types table and the type index... to get the exact type back. > Something in the form: > > unwrapUnsafe :: Wrap -> t > unwrapUnsafe (WrapUnsafe (ix::SNat n) (val::t)) = undefined > > x1 = unwrapUnsafe t1 > x2 = unwrapUnsafe t2 > x3 = unwrapUnsafe t3 > > GHC didn't like any of my attempt. Is it even possible? > > regards, > Zoran > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From zoran.bosnjak at via.si Wed Jan 10 13:40:51 2024 From: zoran.bosnjak at via.si (zoran.bosnjak at via.si) Date: Wed, 10 Jan 2024 14:40:51 +0100 Subject: [Haskell-cafe] restore type from existential In-Reply-To: References: <237b71ae77405c206277e3a74e4019ef@via.si> Message-ID: <5499c46fc5dda72bc74237880db1bdee@via.si> Hi Georgi, thanks for your response. I am not sure I fully understand your suggestion with 'unsafe' approach. In particular: It is not clear to me how could I drop SNat and use Int instead. How do I suppose to get type information out of plain Int? Could you please show an example of the actual 'unwrap' function? This is my current attempt. The problem is that I need to provide type annotation to the unwrap result, which I would like to avoid if possible. {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} import Unsafe.Coerce type MyTypes = '[(), Char, Int] data N = Z | S N type family TypeOf n lst where TypeOf 'Z (t ': ts) = t TypeOf ('S n) (t ': ts) = TypeOf n ts data SNat (n :: N) where SZ :: SNat 'Z SS :: SNat n -> SNat ('S n) data Wrap where MkWrap :: TypeOf n MyTypes ~ t => SNat n -> t -> Wrap -- MkWrap :: SNat n -> TypeOf n MyTypes -> Wrap t1, t2, t3 :: Wrap t1 = MkWrap SZ () t2 = MkWrap (SS SZ) 'x' t3 = MkWrap (SS (SS SZ)) 1 unwrap :: Wrap -> t --unwrap (MkWrap (ix :: SNat n) (val :: t)) = unsafeCoerce val unwrap (MkWrap _ix val) = unsafeCoerce val main :: IO () main = do print $ (unwrap t1 :: ()) print $ (unwrap t2 :: Char) print $ (unwrap t3 :: Int) Zoran On 2024-01-10 12:57, Georgi Lyubenov wrote: > Hi Zoran, > > No, with your given Wrap data type, it would not be possible. > > The moment you only constraint `t` to be `forall` bound in `WrapUnsafe` > and have not other properties, there's really no way to get it out > without using `unsafeCoerce`. > > There are many approaches to achieve being able to "recover" what `t` > is. > > One idea would be to add a list type parameter `ts` to `Wrap` and a > constraint to `WrapUnsafe` which says "t is the type at index n in the > list ts", i.e. something like > ``` > type family Index n ts where >   Index 0 (t ': _) = t >   -- might need your own definition of Nat for the next case >   Index (1 + n) (_ ': ts) = Index n ts > > data Wrap ts where >   MkWrap :: SNat n -> Index n ts -> Wrap ts > ``` > > Another (which I personally think is cleaner) would be to entirely skip > the `SNat`s and use an "membership proof" instead, i.e. something like > ``` > data Elem (x :: t) (xs :: [t]) where >   Here :: Elem x (x ': xs) >   There :: Elem x xs -> Elem x (y ': xs) > ``` > You could then have > ``` > data Wrap ts where >   MkWrap :: Elem t ts -> t -> Wrap ts > t1, t2, t3 :: Wrap MyTypes > t1 = MkWrap Here () > t2 = MkWrap (There Here) 'x' > t3 = MkWrap (There (There Here)) 1 > ``` > You could then also try to automate the membership proof generation via > type classes. > > If you're going the unsafe approach and going to be `unsafeCoerce`ing, > you could also just as well drop the `SNat` and use a raw `Int` > instead, > because you're the one who's going to be taking care not to > `unsafeCoerce` the wrong thing anyways. > > Cheers, > Georgi > > On 1/10/24 12:25, zoran.bosnjak at via.si wrote: >> Dear haskellers, >> if for example I have the following (simplified) situation: >> >> import GHC.TypeLits >> >> type MyTypes = >>     '[ ()    -- index 0 >>      , Char  -- index 1 >>      , Int   -- index 2 >>      ] >> >> data SNat (n :: Nat) where >>     SZ :: SNat 0 >>     SS :: SNat n -> SNat (n+1) >> >> data Wrap where >>     WrapUnsafe :: SNat n -> t -> Wrap >> >> t1 = WrapUnsafe SZ () :: Wrap >> t2 = WrapUnsafe (SS SZ) 'x' :: Wrap >> t3 = WrapUnsafe (SS (SS SZ)) (1::Int) :: Wrap >> >> Is it possible to have an 'unwrap' function? That is: to combine >> MyType types table and the type index... to get the exact type back. >> Something in the form: >> >> unwrapUnsafe :: Wrap -> t >> unwrapUnsafe (WrapUnsafe (ix::SNat n) (val::t)) = undefined >> >> x1 = unwrapUnsafe t1 >> x2 = unwrapUnsafe t2 >> x3 = unwrapUnsafe t3 >> >> GHC didn't like any of my attempt. Is it even possible? >> >> regards, >> Zoran >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From godzbanebane at gmail.com Wed Jan 10 14:44:29 2024 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Wed, 10 Jan 2024 16:44:29 +0200 Subject: [Haskell-cafe] restore type from existential In-Reply-To: <5499c46fc5dda72bc74237880db1bdee@via.si> References: <237b71ae77405c206277e3a74e4019ef@via.si> <5499c46fc5dda72bc74237880db1bdee@via.si> Message-ID: Hi Zoran, If you've decided to use an "index" type family like `TypeOf`, you don't need unsafeCoerce: {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} type MyTypes = '[(), Char, Int] data N = Z | S N type family TypeOf n lst where   TypeOf 'Z (t ': ts) = t   TypeOf ('S n) (t ': ts) = TypeOf n ts data SNat (n :: N) where   SZ :: SNat 'Z   SS :: SNat n -> SNat ('S n) data Wrap where   MkWrap :: SNat n -> TypeOf n MyTypes -> Wrap t1, t2, t3 :: Wrap t1 = MkWrap SZ () t2 = MkWrap (SS SZ) 'x' t3 = MkWrap (SS (SS SZ)) 1 unwrap :: Wrap -> (forall n. (Show (TypeOf n MyTypes)) => TypeOf n MyTypes -> res) -> res unwrap (MkWrap ix val) f =   case ix of     SZ -> f @Z val     SS SZ -> f @(S Z) val     SS (SS SZ) -> f @(S (S Z)) val main :: IO () main = do   unwrap t1 print   unwrap t2 print   unwrap t3 print The "unsafe" approach I was referring to was much more involved than I recall, you can check Chapter 11. Extensible Data from the "Thinking with Types" (Sandy Maguire) book for more information. In general, it seems to me that what you're looking for is roughly the same thing as extensible sums/records, so it might also be beneficial for you to look into some libraries that provide those, and how they've achieved `Wrap`? Cheers, Georgi On 1/10/24 15:40, zoran.bosnjak at via.si wrote: > Hi Georgi, > thanks for your response. I am not sure I fully understand your > suggestion with 'unsafe' approach. In particular: > > It is not clear to me how could I drop SNat and use Int instead. How > do I suppose to get type information out of plain Int? > Could you please show an example of the actual 'unwrap' function? > > This is my current attempt. The problem is that I need to provide type > annotation to the unwrap result, which I would like to avoid if possible. > > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE TypeFamilies #-} > > import Unsafe.Coerce > > type MyTypes = '[(), Char, Int] > > data N = Z | S N > > type family TypeOf n lst where >     TypeOf 'Z (t ': ts) = t >     TypeOf ('S n) (t ': ts) = TypeOf n ts > > data SNat (n :: N) where >     SZ :: SNat 'Z >     SS :: SNat n -> SNat ('S n) > > data Wrap where >     MkWrap :: TypeOf n MyTypes ~ t => SNat n -> t -> Wrap >     -- MkWrap :: SNat n -> TypeOf n MyTypes -> Wrap > > t1, t2, t3 :: Wrap > t1 = MkWrap SZ () > t2 = MkWrap (SS SZ) 'x' > t3 = MkWrap (SS (SS SZ)) 1 > > unwrap :: Wrap -> t > --unwrap (MkWrap (ix :: SNat n) (val :: t)) = unsafeCoerce val > unwrap (MkWrap _ix val) = unsafeCoerce val > > main :: IO () > main = do >     print $ (unwrap t1 :: ()) >     print $ (unwrap t2 :: Char) >     print $ (unwrap t3 :: Int) > > Zoran > > On 2024-01-10 12:57, Georgi Lyubenov wrote: >> Hi Zoran, >> >> No, with your given Wrap data type, it would not be possible. >> >> The moment you only constraint `t` to be `forall` bound in >> `WrapUnsafe` and have not other properties, there's really no way to >> get it out without using `unsafeCoerce`. >> >> There are many approaches to achieve being able to "recover" what `t` >> is. >> >> One idea would be to add a list type parameter `ts` to `Wrap` and a >> constraint to `WrapUnsafe` which says "t is the type at index n in >> the list ts", i.e. something like >> ``` >> type family Index n ts where >>   Index 0 (t ': _) = t >>   -- might need your own definition of Nat for the next case >>   Index (1 + n) (_ ': ts) = Index n ts >> >> data Wrap ts where >>   MkWrap :: SNat n -> Index n ts -> Wrap ts >> ``` >> >> Another (which I personally think is cleaner) would be to entirely >> skip the `SNat`s and use an "membership proof" instead, i.e. >> something like >> ``` >> data Elem (x :: t) (xs :: [t]) where >>   Here :: Elem x (x ': xs) >>   There :: Elem x xs -> Elem x (y ': xs) >> ``` >> You could then have >> ``` >> data Wrap ts where >>   MkWrap :: Elem t ts -> t -> Wrap ts >> t1, t2, t3 :: Wrap MyTypes >> t1 = MkWrap Here () >> t2 = MkWrap (There Here) 'x' >> t3 = MkWrap (There (There Here)) 1 >> ``` >> You could then also try to automate the membership proof generation >> via type classes. >> >> If you're going the unsafe approach and going to be >> `unsafeCoerce`ing, you could also just as well drop the `SNat` and >> use a raw `Int` instead, >> because you're the one who's going to be taking care not to >> `unsafeCoerce` the wrong thing anyways. >> >> Cheers, >> Georgi >> >> On 1/10/24 12:25, zoran.bosnjak at via.si wrote: >>> Dear haskellers, >>> if for example I have the following (simplified) situation: >>> >>> import GHC.TypeLits >>> >>> type MyTypes = >>>     '[ ()    -- index 0 >>>      , Char  -- index 1 >>>      , Int   -- index 2 >>>      ] >>> >>> data SNat (n :: Nat) where >>>     SZ :: SNat 0 >>>     SS :: SNat n -> SNat (n+1) >>> >>> data Wrap where >>>     WrapUnsafe :: SNat n -> t -> Wrap >>> >>> t1 = WrapUnsafe SZ () :: Wrap >>> t2 = WrapUnsafe (SS SZ) 'x' :: Wrap >>> t3 = WrapUnsafe (SS (SS SZ)) (1::Int) :: Wrap >>> >>> Is it possible to have an 'unwrap' function? That is: to combine >>> MyType types table and the type index... to get the exact type back. >>> Something in the form: >>> >>> unwrapUnsafe :: Wrap -> t >>> unwrapUnsafe (WrapUnsafe (ix::SNat n) (val::t)) = undefined >>> >>> x1 = unwrapUnsafe t1 >>> x2 = unwrapUnsafe t2 >>> x3 = unwrapUnsafe t3 >>> >>> GHC didn't like any of my attempt. Is it even possible? >>> >>> regards, >>> Zoran >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. From mikolaj at well-typed.com Wed Jan 10 15:25:54 2024 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Wed, 10 Jan 2024 16:25:54 +0100 Subject: [Haskell-cafe] restore type from existential In-Reply-To: <237b71ae77405c206277e3a74e4019ef@via.si> References: <237b71ae77405c206277e3a74e4019ef@via.si> Message-ID: I'm not sure if anybody mentioned that, but if you have data Wrap where WrapUnsafe :: Typeable t => SNat n -> t -> Wrap Then you can write something like unwrapUnsafe :: Wrap -> t unwrapUnsafe (WrapUnsafe @t0 (ix::SNat n) (val::t)) = case testEquality (typeRep @t0) (typeRep @t) of Just Refl -> val Nothing -> error "" No unsafeCoerce, but the error case can occur easily. Cheers, Mikolaj On Wed, Jan 10, 2024 at 11:26 AM wrote: > > Dear haskellers, > if for example I have the following (simplified) situation: > > import GHC.TypeLits > > type MyTypes = > '[ () -- index 0 > , Char -- index 1 > , Int -- index 2 > ] > > data SNat (n :: Nat) where > SZ :: SNat 0 > SS :: SNat n -> SNat (n+1) > > data Wrap where > WrapUnsafe :: SNat n -> t -> Wrap > > t1 = WrapUnsafe SZ () :: Wrap > t2 = WrapUnsafe (SS SZ) 'x' :: Wrap > t3 = WrapUnsafe (SS (SS SZ)) (1::Int) :: Wrap > > Is it possible to have an 'unwrap' function? That is: to combine MyType > types table and the type index... to get the exact type back. Something > in the form: > > unwrapUnsafe :: Wrap -> t > unwrapUnsafe (WrapUnsafe (ix::SNat n) (val::t)) = undefined > > x1 = unwrapUnsafe t1 > x2 = unwrapUnsafe t2 > x3 = unwrapUnsafe t3 > > GHC didn't like any of my attempt. Is it even possible? > > regards, > Zoran > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From mitchellwrosen at gmail.com Sat Jan 13 21:01:31 2024 From: mitchellwrosen at gmail.com (Mitchell Rosen) Date: Sat, 13 Jan 2024 16:01:31 -0500 Subject: [Haskell-cafe] `queue` package take-over request Message-ID: Hi all, I'd like to take over the `queue` package, last updated 14 years ago, and marked "deprecated" on Hackage. I intend to replace it with a simple, clean implementation of Okasaki's "real time" (meaning O(1) worst-case operations) queue, which you can find implemented here: https://github.com/awkward-squad/queues I had originally named the package `queues` (with an s), but figured it would be better to repurpose the singular `queue` with something useful, if possible. Thanks! Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitchellwrosen at gmail.com Sat Jan 13 21:02:27 2024 From: mitchellwrosen at gmail.com (Mitchell Rosen) Date: Sat, 13 Jan 2024 16:02:27 -0500 Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: Sorry, forgot to mention: I emailed the author months ago, and got no response. On Sat, Jan 13, 2024 at 4:01 PM Mitchell Rosen wrote: > Hi all, > > I'd like to take over the `queue` package, last updated 14 years ago, and > marked "deprecated" on Hackage. I intend to replace it with a simple, clean > implementation of Okasaki's "real time" (meaning O(1) worst-case > operations) queue, which you can find implemented here: > https://github.com/awkward-squad/queues > > I had originally named the package `queues` (with an s), but figured it > would be better to repurpose the singular `queue` with something useful, if > possible. > > Thanks! > Mitchell > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Sat Jan 13 21:30:58 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 13 Jan 2024 22:30:58 +0100 (CET) Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: On Sat, 13 Jan 2024, Mitchell Rosen wrote: > I'd like to take over the `queue` package, last updated 14 years ago, > and marked "deprecated" on Hackage. I intend to replace it with a > simple, clean implementation of Okasaki's "real time" (meaning O(1) > worst-case operations) queue, which you can find implemented here: > https://github.com/awkward-squad/queues Yes, base also had a Data.Queue module. But then we got containers:Data.Sequence and it was claimed, that Data.Sequence would be better than Data.Queue in any aspect. From mitchellwrosen at gmail.com Sun Jan 14 00:30:17 2024 From: mitchellwrosen at gmail.com (Mitchell Rosen) Date: Sat, 13 Jan 2024 19:30:17 -0500 Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: I see, that's some interesting history. The claim that Data.Sequence is faster than Data.Queue is wrong, though, as far as I can tell (see benchmark in repo), so maybe it was a mistake to remove from base if that really was the rationale. Are there any records of that conversation/decision? Also, a minor point - Data.Sequence only has amortized O(1) enqueue and dequeue, whereas Data.Queue has O(1) worst-case enqueue and dequeue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at mailbox.org Sun Jan 14 20:27:04 2024 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Sun, 14 Jan 2024 13:27:04 -0700 Subject: [Haskell-cafe] Fastest saturating add? Message-ID: I have a function that's called many (many) times, which involves a saturating addition (addition without overflow). In other words, I'd like ((254 :: Word8) + 10) to equal 255 (which is maxBound::Word8), not 8 (which is what you get with overflow). My current code, without particular regard to performance, is simply: satAdd :: Word8 -> Word8 -> Word8 satAdd x y = let m = x + y in if m < x then 255 else m This seems like the type of code somebody's already worked on the performance for, though I can't find much Haskell-specific in searches online. Is there a faster way to do this? Thanks! Tom From lemming at henning-thielemann.de Sun Jan 14 21:38:01 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 14 Jan 2024 22:38:01 +0100 (CET) Subject: [Haskell-cafe] Fastest saturating add? In-Reply-To: References: Message-ID: <643d9f51-6c8c-fb8-5166-4688e05dcff8@henning-thielemann.de> On Sun, 14 Jan 2024, amindfv--- via Haskell-Cafe wrote: > I have a function that's called many (many) times, which involves a > saturating addition (addition without overflow). > > In other words, I'd like ((254 :: Word8) + 10) to equal 255 (which is > maxBound::Word8), not 8 (which is what you get with overflow). > > My current code, without particular regard to performance, is simply: > > satAdd :: Word8 -> Word8 -> Word8 > satAdd x y = > let m = x + y > in if m < x then 255 else m > > This seems like the type of code somebody's already worked on the > performance for, though I can't find much Haskell-specific in searches > online. LLVM is pretty good at optimizing such code snippets. You may first watch what code it generates. I guess you do not have to apply manual optimizations. But you might be curious how LLVM translates your code. The CPU sets a flag when it encounters a carry (aka unsigned overflow). Then it has an instruction for doing a conditional move. That is, even without special saturated arithmetic instructions, unsigned saturated addition can be done in two or three basic instructions. LLVM also has a saturating add intrinsic: https://llvm.org/docs/LangRef.html#saturation-arithmetic-intrinsics x86 provides saturating addition in its SSE and AVX subsystems. They even allow you to perform up to 64 byte additions in one instruction. I have looked up that x86 has PADDUSB instruction. Ok, lets watch LLVM: $ cat saturated-add.ll target triple = "x86_64-unknown-linux-gnu" define i8 @satAdd(i8 %x, i8 %y) { %m = add i8 %x, %y %carry = icmp ult i8 %m, %x %satSum = select i1 %carry, i8 255, i8 %m ret i8 %satSum } $ llc-17 ========================================================================= BOB 2024 Conference “What happens if we simply use what’s best?” March 15, 2024, Berlin https://bobkonf.de/2024/ Program: https://bobkonf.de/2024/program.html Registration: https://bobkonf.de/2024/registration.html ========================================================================= BOB conference is a place for developers, architects, and decision-makers to explore technologies beyond the mainstream in software development and to find the best tools available to software developers today. Our goal is for all participants of BOB to return home with new insights that enable them to improve their own software development experience. The program features 14 talks and 8 tutorials on current topics: https://bobkonf.de/2024/program.html Talk subjects includes functional programming, property-based testing, service API design, programming for spacecraft, accessibility, hypermedia, business processes, software analytics, event-based communication and zero-knowledge proofs. BOB will feature tutorials on F#, Haskell, Lean, SwiftUI, Copilot, the K Framework, functional domain modelling, and Liberating Structures. Andreas Rossberg will give the keynote talk. Registration is open - online tickets are all under 200€, and many discount options are available, as are grants for members of groups underrepresented in tech. Early-bird registration runs until Jan 30: https://bobkonf.de/2024/registration.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Mon Jan 15 08:32:47 2024 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 15 Jan 2024 08:32:47 +0000 Subject: [Haskell-cafe] Fully-funded PhD studentship in functional programming Message-ID: Dear all, I'm advertising a fully-funded PhD studentship in functional programming, starting 1st October 2024. Please pass the advert on to anyone who may be intersted in applying. Best wishes, Graham Hutton +-----------------------------------------------------------+ Fully-Funded PhD Studentship Functional Programming Lab School of Computer Science University of Nottingham, UK http://tinyurl.com/fplab-phd Applications are invited for a fully-funded PhD studentship under the supervision of Prof Graham Hutton, starting on 1st October 2024. The successful applicant will join the Functional Programming Lab, an internationally-leading centre for programming language research. The topic for the studentship is open, but should relate to the research interests of Prof Hutton on the mathematics of program construction. The studentship forms part of the recently-funded EPSRC project on Semantics-Directed Compiler Construction, which seeks to develop new techniques for constructing certified compilers from semantics. The studentship is open to home and international students, is fully-funded for three and a half years, and includes a stipend of £18,622 per year and tuition fees. Applicants are expected to have a first-class Masters or Bachelors degree (or equivalent) in Computer Science and/or Mathematics, and an excellent ability and interest in the mathematical foundations of programming, together with experience of programming in a functional language. Further information and advice for prospective applicants is available from http://tinyurl.com/369xwzc7. Funding for this studentship is already in place. To apply, please submit the following items by email to graham.hutton at nottingham.ac.uk: (1) a brief covering letter that describes your reasons for wishing to undertake a PhD and any ideas you have about potential topics; (2) a copy of your CV, including your actual or expected degree class(es) and results of all university examinations; (3) an example of your technical writing, such as a report or dissertation; (4) email addresses for two academic referees. Closing date for applications: Friday 9th February 2024. +-----------------------------------------------------------+ — Professor Graham Hutton School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~pszgmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law. From olf at aatal-apotheke.de Mon Jan 15 11:00:16 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 15 Jan 2024 12:00:16 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: Dear Cafe, I have a data type with a bidirectional pattern {-# LANGUAGE PatternSynonyms #-} newtype T f t = C (f Double) pattern T :: Double -> T Identity t pattern T x = C (Identity x) Note that pattern T is the only way to construct something of type (T Identity t) for any phantom parameter t. When using the pattern to match in a where clause, the Wincomplete-uni-pattern warns me about non-exhaustive pattern matches that are in fact matched: f a = x where T x = g a :: T Identity () warning: [-Wincomplete-uni-patterns] Pattern match(es) are non- exhaustive in a pattern binding: Patterns not matched: C (Identity _) Minimal complete example is attached. How can I teach GHC 9 that the pattern is indeed exhaustive? GHC seems to have only three issues involving incomplete-uni-patterns, only one of them open, none of which matches my observations. Thanks Olaf -------------- next part -------------- A non-text attachment was scrubbed... Name: pattern.hs Type: text/x-haskell Size: 361 bytes Desc: not available URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Jan 15 11:09:26 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Jan 2024 11:09:26 +0000 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: References: Message-ID: On Mon, Jan 15, 2024 at 12:00:16PM +0100, Olaf Klinke wrote: > How can I teach GHC 9 that the pattern is indeed exhaustive? Have you tried COMPLETE pragmas? https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#complete-pragmas Tom From jesse.rudel at gmail.com Mon Jan 15 14:28:51 2024 From: jesse.rudel at gmail.com (Jesse Rudel) Date: Mon, 15 Jan 2024 10:28:51 -0400 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: References: Message-ID: Richard Eisenberg has videos on pattern synonyms where he adds a COMPLETE pragma to teach GHC that he is performing exhaustive/complete pattern matches, https://www.youtube.com/watch?v=SPC_R5nwFqo&t=397s. On Mon, Jan 15, 2024 at 7:09 AM Tom Ellis < tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote: > On Mon, Jan 15, 2024 at 12:00:16PM +0100, Olaf Klinke wrote: > > How can I teach GHC 9 that the pattern is indeed exhaustive? > > Have you tried COMPLETE pragmas? > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#complete-pragmas > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Mon Jan 15 17:32:44 2024 From: zubin at well-typed.com (Zubin Duggal) Date: Mon, 15 Jan 2024 23:02:44 +0530 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] Haskell Language Server 2.6.0.0 released Message-ID: Binaries for this release are available at https://downloads.haskell.org/~hls/haskell-language-server-2.6.0.0/. These binaries can be installed using [GHCup](https://www.haskell.org/ghcup/), using the vanilla metadata channel. ```bash ghcup --url-source=https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-vanilla-0.0.8.yaml install hls 2.6.0.0 ``` All of these tarballs have associated GPG signatures. The signature should be from `Zubin Duggal ` (key ID [588764FBE22D19C4](https://keys.openpgp.org/search?q=588764FBE22D19C4)). The prebuilt binaries in this release support the following GHC versions: - 9.2.8 - 9.4.8 - 9.6.4 - 9.8.1 # Changelog - Bindists for GHC 9.6.4 - A new semantic tokens plugin (#3892, @soulomoon). - Improvements to multiple home unit support with GHC 9.4. Using cabal 3.11+ will load proper multiple home unit sessions by default, fixing a lot of issues with loading and reloading projects that have more than one component (#3462, @wz1000). - Removed implicit-hie, resulting in better behaviour for projects without cradles. - Don't produce diagnostics for disabled plugins (#3941, @fendor). - Many other bug fixes. Happy editing! - Zubin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From olf at aatal-apotheke.de Mon Jan 15 19:56:33 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 15 Jan 2024 20:56:33 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: <1c75848f7dcc301250508ffbccbc089baf568cab.camel@aatal-apotheke.de> > On Mon, Jan 15, 2024 at 12:00:16PM +0100, Olaf Klinke wrote: > > How can I teach GHC 9 that the pattern is indeed exhaustive? > > Have you tried COMPLETE pragmas? > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#complete-pragmas > > Tom Huh, of course that works. Thanks. It never occurred to me to even consider the existence of manual completeness annotation, since completeness checks work so reliably for ordinary constructors. But maybe my types weren't esoteric enough so far. Are there pattern-free cases where the GHC completeness checker is wrong? Of what computational class is the problem? Can I simulate a Turing machine by checking completeness in the presence of patterns? Olaf From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Mon Jan 15 20:55:09 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Jan 2024 20:55:09 +0000 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: <1c75848f7dcc301250508ffbccbc089baf568cab.camel@aatal-apotheke.de> References: <1c75848f7dcc301250508ffbccbc089baf568cab.camel@aatal-apotheke.de> Message-ID: On Mon, Jan 15, 2024 at 08:56:33PM +0100, Olaf Klinke wrote: > > On Mon, Jan 15, 2024 at 12:00:16PM +0100, Olaf Klinke wrote: > > > How can I teach GHC 9 that the pattern is indeed exhaustive? > > > > Have you tried COMPLETE pragmas? > > > > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#complete-pragmas > > Huh, of course that works. Thanks. You're welcome. > It never occurred to me to even consider the existence of manual > completeness annotation, since completeness checks work so reliably for > ordinary constructors. But maybe my types weren't esoteric enough so > far. Are there pattern-free cases where the GHC completeness checker is > wrong? Of what computational class is the problem? Can I simulate a > Turing machine by checking completeness in the presence of patterns? I think the completeness checker works fine in all pattern-synonym-free cases, i.e. when you're using only real constructors. I don't actually understand why completeness annotations are needed for pattern synonyms. Tom From aaronallen8455 at gmail.com Tue Jan 16 05:16:13 2024 From: aaronallen8455 at gmail.com (Aaron Allen) Date: Mon, 15 Jan 2024 23:16:13 -0600 Subject: [Haskell-cafe] GSoC 2024 Call for Ideas Message-ID: Dear Haskellers, Google Summer of Code is a long-running program by Google that supports Open Source projects. Haskell has been involved in the Google Summer of Code program almost since its inception and we are hoping to participate again in 2024! In order to do this we need a collection of ideas for participants to select from. In the past this has included significant improvements to Haskell projects such as GHC, Cabal, and HLS - and it can include your project as well! This is a great opportunity to find new contributors for your project and many past participants have become involved long-term. You can find more info and instructions on how to participate here: https://summer.haskell.org/ideas.html. -------------- next part -------------- An HTML attachment was scrubbed... URL: From x at tomsmeding.com Tue Jan 16 10:33:46 2024 From: x at tomsmeding.com (Tom Smeding) Date: Tue, 16 Jan 2024 10:33:46 +0000 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: References: <1c75848f7dcc301250508ffbccbc089baf568cab.camel@aatal-apotheke.de> Message-ID: > I think the completeness checker works fine in all > pattern-synonym-free cases, i.e. when you're using only real > constructors.  I don't actually understand why completeness > annotations are needed for pattern synonyms. I remember reading somewhere, but I can't find it now, that GHC's coverage checker does not look inside pattern synonym definitions at all, and this is by design: namely to ensure abstraction boundaries. Looking inside the definition would mean that type checking behaviour (in a way -- if you count coverage checks as "type checking") of user code is influenced by invisible implementation details of the "constructors" they're using. My own thoughts on this: if GHC would look inside pattern synonym definitions, then it would be hard to ensure that GHC thinks that certain things are _not_ complete even if technically they are. For example, if you have a data type with, say, 3 constructors, but you hide some of those (don't export them) and use pattern synonyms to make it look like 4 constructors, then you might want GHC's coverage checker to consider that a data type with 4 constructors, not one with 3. COMPLETE pragmas add "positive" information -- "this set is complete, in addition to whatever other complete sets GHC might already know" -- and there is no way to _subtract_ complete sets from GHC's knowledge base. This is mostly me theorising, but perhaps it helps. - other Tom From olf at aatal-apotheke.de Tue Jan 16 15:16:26 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 16 Jan 2024 16:16:26 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: <2ed2f685c9a9b71c67af917e83296ccc5dfd488b.camel@aatal-apotheke.de> > > I think the completeness checker works fine in all > > pattern-synonym-free cases, i.e. when you're using only real > > constructors.   One can envision a simple recursive divide-and-conquer algorithm, see below. > I don't actually understand why completeness > > annotations are needed for pattern synonyms. > > I remember reading somewhere, but I can't find it now, that GHC's > coverage checker does not look inside pattern synonym definitions at > all, and this is by design: namely to ensure abstraction boundaries. > Looking inside the definition would mean that type checking behaviour > (in a way -- if you count coverage checks as "type checking") of user > code is influenced by invisible implementation details of the > "constructors" they're using. Compare that to 'type' versus 'newtype' on the type level: A type is just an alias, a synonym. The type checker has access to all information on the right hand side of the equality. With extensions like TypeSynonymInstances, A type alias is interchangeable with the aliased type. If what you report is true, they should not have called pattern synonyms a "synonym". > > My own thoughts on this: if GHC would look inside pattern synonym > definitions, then it would be hard to ensure that GHC thinks that > certain things are _not_ complete even if technically they are. For > example, if you have a data type with, say, 3 constructors, but you > hide > some of those (don't export them) and use pattern synonyms to make it > look like 4 constructors, then you might want GHC's coverage checker > to > consider that a data type with 4 constructors, not one with 3. > COMPLETE > pragmas add "positive" information -- "this set is complete, in > addition > to whatever other complete sets GHC might already know" -- and there > is > no way to _subtract_ complete sets from GHC's knowledge base. > > This is mostly me theorising, but perhaps it helps. > > - other Tom > I don't think the number of constructors/patterns is the issue. Likely the problem lies in the fact that while ordinary constructors make up disjoint subsets of the type, with patterns you can define overlapping sets, which makes completeness checks much more complicated. Hence I believe that completeness checks in presence of patterns is equivalent to determine whether a disjunction of logic formulae, which are possibly self-referential, is a tautology. That may well be semi- decidable at best. Olaf From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Jan 16 15:21:19 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 16 Jan 2024 15:21:19 +0000 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: <2ed2f685c9a9b71c67af917e83296ccc5dfd488b.camel@aatal-apotheke.de> References: <2ed2f685c9a9b71c67af917e83296ccc5dfd488b.camel@aatal-apotheke.de> Message-ID: On Tue, Jan 16, 2024 at 04:16:26PM +0100, Olaf Klinke wrote: > > I remember reading somewhere, but I can't find it now, that GHC's > > coverage checker does not look inside pattern synonym definitions at > > all, and this is by design: namely to ensure abstraction boundaries. > > Looking inside the definition would mean that type checking behaviour > > (in a way -- if you count coverage checks as "type checking") of user > > code is influenced by invisible implementation details of the > > "constructors" they're using. > > Compare that to 'type' versus 'newtype' on the type level: A type is > just an alias, a synonym. The type checker has access to all > information on the right hand side of the equality. With extensions > like TypeSynonymInstances, A type alias is interchangeable with the > aliased type. > If what you report is true, they should not have called pattern > synonyms a "synonym". Ah, they should be newpatterns! From ietf-dane at dukhovni.org Tue Jan 16 15:34:46 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Jan 2024 10:34:46 -0500 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: <2ed2f685c9a9b71c67af917e83296ccc5dfd488b.camel@aatal-apotheke.de> References: <2ed2f685c9a9b71c67af917e83296ccc5dfd488b.camel@aatal-apotheke.de> Message-ID: On Tue, Jan 16, 2024 at 04:16:26PM +0100, Olaf Klinke wrote: > I don't think the number of constructors/patterns is the issue. > Likely the problem lies in the fact that while ordinary constructors > make up disjoint subsets of the type, with patterns you can define > overlapping sets, which makes completeness checks much more > complicated. > Hence I believe that completeness checks in presence of patterns is > equivalent to determine whether a disjunction of logic formulae, which > are possibly self-referential, is a tautology. That may well be semi- > decidable at best. That seems plausible, but I think that interface stability is a more serious concern. It isn't enough to know that *as-implemented* at a given time some particular set of patterns is complete. The implementation of a set of patterns (or the underlying type) can change in a manner that changes complete <-> incomplete in either direction. Such changes are non-breaking, provided there was no "contract" (COMPLETE pragma) that the patterns are *intended* to be complete. Initially: data Foo = A | B pattern Good :: Foo; pattern Good = Foo A pattern Bad :: Foo; pattern Bad = Foo B Later: data Foo = A | B | C pattern Good :: Foo; pattern Good = Foo A pattern Bad :: Foo; pattern Bad = Foo B Later still: pattern Ugly :: Foo; pattern Ugly = Foo C All fine, if there was no expectation that "Good, Bad" is a COMPLETE set. Such completeness is a matter of interface contract (design intent), and cannot be derived. -- Viktor. From olf at aatal-apotheke.de Thu Jan 18 08:03:25 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 18 Jan 2024 09:03:25 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: > > Hence I believe that completeness checks in presence of patterns is > > equivalent to determine whether a disjunction of logic formulae, > > which > > are possibly self-referential, is a tautology. That may well be > > semi- > > decidable at best. > > That seems plausible, but I think that interface stability is a more > serious concern. It isn't enough to know that *as-implemented* at a > given time some particular set of patterns is complete. > > The implementation of a set of patterns (or the underlying type) can > change in a manner that changes complete <-> incomplete in either > direction. Such changes are non-breaking, provided there was no > "contract" (COMPLETE pragma) that the patterns are *intended* to be > complete. > You are right: It is possible that the types of the bidirectional patterns do not change, but the completeness changes. In your example given I would argue the contract is broken, because the new patterns are for a different type Foo. Instead -- before: Good, Bad are complete data Foo = A | B pattern Good :: Foo pattern Good = A pattern Bad :: Foo pattern Bad = B -- after: Good, Bad are incomplete -- Foo, Good as before pattern Bad = A Here neither the definition of Foo nor the types of Good or Bad have changed, but completeness has. Here is why I think that completeness checks even with pattern synonyms should work and we would not need COMPLETE pragmas. The algorithm for a set of patterns of type T is: 1. Construct a Stone [1] space X from the given type T. (Often X = T) 2. Translate each pattern to a clopen of that Stone space 3. Use Stone duality to translate coverage into a Zeroth-order logic problem, which is decidable. Let us define an equivalence relation on the elements of a type. Say x~y whenever there is no pattern that can distinguish x and y by pattern match. Notice that any pattern partitions the set of equivalence classes into two disjoint subsets, think of isJust or isNothing. In general, given a pattern Pat for type T, write isPat :: T -> Bool isPat x = case x of Pat -> True _ -> False For functions types, there is only one equivalence class, because there is only one way to pattern-match a function. Observe that two elements can be distinguished by a set of patterns if and only if there is one element in the pattern set that already distinguishes them. Do pattern synonyms refine the equivalence relation induced by ordinary constructors? No. Consider type Clopen x = x -> Bool data C = L C | R C cl :: Clopen C cl = isL . shift where isL :: Clopen C -- a pattern isL (L c) = True isL (R c) = False shift :: C -> C shift (L c) = c shift (R c) = c Can one define a single pattern synonym pattern CL :: C -> C such that CL matches c if any only if cl c == True? Note that cl is the disjunction of two ordinary patterns, namely L (L _) R (L _) CL morally should be the pattern (_(L _)) but that is not valid pattern syntax. Indeed with synonyms we can define the CL pattern: {-# LANGUAGE PatternSynonyms, ViewPatterns #-} swap :: C -> C swap (L (R c)) = R (L c) swap (R (L c)) = L (R c) swap c = c pattern CL c <- (swap -> L c) isCL :: Clopen C isCL c = case c of CL _ -> True _ -> False Now, at least as long as a type X has only a finite number of constructors (integers with numeric literals being an exception), the type Clopen X defines a Stone space, a compact zero-dimensional Hausdorff space. By Stone duality these are dually equivalent to Boolean algebras. The duality translates the problem of coverage by clopens to the problem of proving that the disjunction of some elements in the algebra is the top element 'True'. Since Zeroth-order logic is decidable, completness checks even in the presence of pattern synonyms should be, too. For the countably infinite type C above, one can use the Select monad [2] to decide whether any number of clopens covers the space, pattern or not.  For numeric literal patterns we can safely say that any set of patterns is not covering unless a wildcard pattern is among them. Olaf [1] https://en.wikipedia.org/wiki/Stone_space [2] https://hackage.haskell.org/package/transformers-0.6.1.1/docs/Control-Monad-Trans-Select.html see also https://hackage.haskell.org/package/infinite-search From ietf-dane at dukhovni.org Thu Jan 18 17:20:35 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 18 Jan 2024 12:20:35 -0500 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: References: Message-ID: On Thu, Jan 18, 2024 at 09:03:25AM +0100, Olaf Klinke wrote: > > The implementation of a set of patterns (or the underlying type) can > > change in a manner that changes complete <-> incomplete in either > > direction. Such changes are non-breaking, provided there was no > > "contract" (COMPLETE pragma) that the patterns are *intended* to be > > complete. > > > > You are right: It is possible that the types of the bidirectional > patterns do not change, but the completeness changes. In your example > given I would argue the contract is broken, because the new patterns > are for a different type Foo. Instead A major (often primary) use case of pattern synonyms is with opaque types that hide their constructors, and expose only pattern synonyms as "smart constructors". The internal structure of such types can evolve without introducing API changes, with the pattern synonyms providing backwards-compatible behaviour. My point is that which patterns are expected to be complete is an API design choice, subject to API stability decisions, and not just a matter of deductive reasoning. One might, for example, have a pattern that in the initial API implementation always matches (it is some sort of property check, that can't yet fail), and later versions of the API may make it possible for the pattern to fail (justifying its initial introduction). -- Viktor. From kazu at iij.ad.jp Fri Jan 19 01:21:56 2024 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 19 Jan 2024 10:21:56 +0900 (JST) Subject: [Haskell-cafe] heads-up: tls v2.0.0 Message-ID: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> Hello guys, I'm planning to release the "tls" package v2.0.0 probably within one month. It removes TLS 1.0/1.1 and provides only TLS 1.2/1.3 with safe cipher suites according to recent RFCs and internet-drafts. This version does not change the default usage. But if you are using custom parameters, you might have to modify your code. This breaking change is *intentional* to notice users that they are using vulnerable versions and/or parameters. The attached is the current change log. --Kazu ## Version 2.0.0 * `tls` now only supports TLS 1.2 and TLS 1.3 with safe cipher suites. * Security: BREAKING CHANGE: TLS 1.0 and TLS 1.1 are removed. * Security: BREAKING CHANGE: all CBC cipher suite are removed. * Security: BREAKING CHANGE: RC4 and 3DES are removed. * Security: BREAKING CHANGE: DSS(digital signature standard) is removed. * Security: BREAKING CHANGE: TLS 1.2 servers require EMS(extended master secret) by default. * BREAKING CHANGE: the package is now complied with `Strict` and `StrictData`. * BREAKING CHANGE: Many data structures are re-defined with `PatternSynonyms` for extensibility. * BREAKING CHANGE: the structure of `SessionManager` is changed to support session tickets. * API: `handshake` can receive an alert of client authentication failure for TLS 1.3 [#463](https://github.com/haskell-tls/hs-tls/pull/463) * API: `bye` can receive NewSessionTicket for TLS 1.3 * Channel binding: `getFinished` and `getPeerFinished` are deprecated. Use `getTLSUnique` instead. * Channel binding: `getTLSExporter` and `getTLSServerEndPoint` are provided. [#462](https://github.com/haskell-tls/hs-tls/pull/462) * Refactoring: the monolithic `handshake` is divided to follow the diagram of TLS 1.2 and 1.3 for readability. * Refactoring: test cases are refactored for maintenability and readablity. `hspec` is used instead of `tasty`. * Code format: `fourmolu` is used as an official formatter. From ietf-dane at dukhovni.org Fri Jan 19 01:51:50 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 18 Jan 2024 20:51:50 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> Message-ID: On Fri, Jan 19, 2024 at 10:21:56AM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > I'm planning to release the "tls" package v2.0.0 probably within one > month. It removes TLS 1.0/1.1 and provides only TLS 1.2/1.3 with safe > cipher suites according to recent RFCs and internet-drafts. > > This version does not change the default usage. But if you are using > custom parameters, you might have to modify your code. This breaking > change is *intentional* to notice users that they are using vulnerable > versions and/or parameters. I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any chance you could find some way to explicitly keep these protocol versions enabled? -- Viktor. From dennis.raddle at gmail.com Fri Jan 19 06:21:55 2024 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Thu, 18 Jan 2024 22:21:55 -0800 Subject: [Haskell-cafe] Parallel Haskell on an M2 Mac Message-ID: I don't know a lot about parallel Haskell, so I'm wondering in general terms how that would work with my M2 Mac. I have a search task that's easily run in parallel. For example, I might map a function over a list, and each item's evaluation can run in parallel. On the M2 MacBook I have, there are 4 efficiency cores with 1 thread each, and 8 performance cores with 2 threads each. Is it fairly easy to use parallel Haskell to spread the task over these 20 possible threads? By any chance could I limit it to using the performance cores if that helps the speed? Thanks, Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Fri Jan 19 07:19:06 2024 From: jo at durchholz.org (Jo Durchholz) Date: Fri, 19 Jan 2024 08:19:06 +0100 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> Message-ID: <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> On 19.01.24 02:51, Viktor Dukhovni wrote: > I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any > chance you could find some way to explicitly keep these protocol > versions enabled? Could you switch to unencrypted connections? As far as my current knowledge goes, 1.x TLS isn't significantly safer than unencrypted anyway. Your other option would be to stick with the older tls library. If your code is again library code for consumption in other people's projects, you should consider retracting it, as it is (and in fact has been) undermining communication security for years. Regards, Jo From ietf-dane at dukhovni.org Fri Jan 19 08:17:16 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jan 2024 03:17:16 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> Message-ID: On Fri, Jan 19, 2024 at 08:19:06AM +0100, Jo Durchholz wrote: > On 19.01.24 02:51, Viktor Dukhovni wrote: > > I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any > > chance you could find some way to explicitly keep these protocol > > versions enabled? > > Could you switch to unencrypted connections? In fact, no. > As far as my current knowledge goes, 1.x TLS isn't significantly safer > than unencrypted anyway. That's far from accurate. TLS 1.0, though dated, is quite adequate for many non-browser applications. -- Viktor. From kazu at iij.ad.jp Fri Jan 19 09:21:13 2024 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 19 Jan 2024 18:21:13 +0900 (JST) Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> Message-ID: <20240119.182113.990978677007904879.kazu@iij.ad.jp> Hi Viktor, > I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any > chance you could find some way to explicitly keep these protocol > versions enabled? The answer is no. You might want to stick to tls v1.9.x. P.S. According tests with Qualys SSL Labs, the following browsers cannot communicate with tls v2.0.0: IE 11 / Win 7 IE 11 / Win 8.1 IE 11 / Win Phone 8.1 IE 11 / Win Phone 8.1 Update Safari 6 / iOS 6.0.1 Safari 7 / iOS 7.1 Safari 7 / OS X 10.9 Safari 8 / iOS 8.4 Safari 8 / OS X 10.10 They are quite outdated. --Kazu From ietf-dane at dukhovni.org Fri Jan 19 09:32:57 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jan 2024 04:32:57 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <20240119.182113.990978677007904879.kazu@iij.ad.jp> References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <20240119.182113.990978677007904879.kazu@iij.ad.jp> Message-ID: On Fri, Jan 19, 2024 at 06:21:13PM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > Hi Viktor, > > > I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any > > chance you could find some way to explicitly keep these protocol > > versions enabled? > > The answer is no. > > You might want to stick to tls v1.9.x. That's unfortunate. > > P.S. > > According tests with Qualys SSL Labs, the following browsers > cannot communicate with tls v2.0.0: > > IE 11 / Win 7 > IE 11 / Win 8.1 > IE 11 / Win Phone 8.1 > IE 11 / Win Phone 8.1 Update > Safari 6 / iOS 6.0.1 > Safari 7 / iOS 7.1 > Safari 7 / OS X 10.9 > Safari 8 / iOS 8.4 > Safari 8 / OS X 10.10 > > They are quite outdated. TLS is not just for the web. There are various application ecosystems that are noticeably less agile than web browsers, and substantially not at risk from the various browser-related attacks on TLS 1.0. Note that barring new handshake downgrade attacks, security is improved by raising the ceiling (making more secure options available and on by default) than by raising the floor (possibly leading to some communication using cleartext instead). The suggestion that I should consider cleartext instead of TLS 1.0 is a clear case of letting the perfect be the enemy of the good. In RFC 7435, I made a case for a more practical approach. -- Viktor. From kazu at iij.ad.jp Fri Jan 19 09:41:55 2024 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Fri, 19 Jan 2024 18:41:55 +0900 (JST) Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.182113.990978677007904879.kazu@iij.ad.jp> Message-ID: <20240119.184155.1070251071643932343.kazu@iij.ad.jp> Hi Viktor, > TLS is not just for the web. There are various application ecosystems > that are noticeably less agile than web browsers, and substantially not > at risk from the various browser-related attacks on TLS 1.0. Why cannot you switch to TLS 1.2? TLS 1.2 is 16 year old, very similar to TLS 1.0 and much more secure. --Kazu From jo at durchholz.org Fri Jan 19 09:55:15 2024 From: jo at durchholz.org (Jo Durchholz) Date: Fri, 19 Jan 2024 10:55:15 +0100 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> Message-ID: <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> On 19.01.24 09:17, Viktor Dukhovni wrote: > On Fri, Jan 19, 2024 at 08:19:06AM +0100, Jo Durchholz wrote: >> On 19.01.24 02:51, Viktor Dukhovni wrote: >>> I'd very much prefer that support for TLS 1.0/1.1 not be removed. Any >>> chance you could find some way to explicitly keep these protocol >>> versions enabled? >> >> Could you switch to unencrypted connections? > > In fact, no. What's holding you back? >> As far as my current knowledge goes, 1.x TLS isn't significantly safer >> than unencrypted anyway. > > That's far from accurate. TLS 1.0, though dated, is quite adequate for > many non-browser applications. Well... sort-of. It depends on SHA-1 for initial handshake and peer authentication (both relevant to prevent man-in-the-middle attacks), and the best known algorithms to break it still require ~100 GPU years of compute power. However, there's that risk that some improved algorithm takes this attack vector from "merely feasible" to "routine". This could happen any day, or may already have happened but is being kept secret. I don't know if this is a relevant concern for the data you're dealing with. You'll have to think about the consequences if that data is decrypted or manipulated. BTW validating that a concern does not apply is more work than simply upgrading, in the vast majority of cases. Regards, Jo From bryan at haskell.foundation Fri Jan 19 12:47:10 2024 From: bryan at haskell.foundation (Bryan Richter) Date: Fri, 19 Jan 2024 14:47:10 +0200 Subject: [Haskell-cafe] Parallel Haskell on an M2 Mac In-Reply-To: References: Message-ID: I'd also be curious to know if you can somehow distinguish the types of cores from each other, but otherwise all the usual parallel stuff should work on Arm-based Macs as it works on other platforms supported by GHC. The book described at https://simonmar.github.io/pages/pcph.html is still the best source for learning about parallel Haskell. On Fri, 19 Jan 2024 at 08:22, Dennis Raddle wrote: > I don't know a lot about parallel Haskell, so I'm wondering in general > terms how that would work with my M2 Mac. I have a search task that's > easily run in parallel. For example, I might map a function over a list, > and each item's evaluation can run in parallel. On the M2 MacBook I have, > there are 4 efficiency cores with 1 thread each, and 8 performance cores > with 2 threads each. Is it fairly easy to use parallel Haskell to spread > the task over these 20 possible threads? By any chance could I limit it to > using the performance cores if that helps the speed? > > Thanks, > Dennis > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Fri Jan 19 13:15:06 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 19 Jan 2024 14:15:06 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: <68e7b76f662d684cbec2149998141bcea5675b64.camel@aatal-apotheke.de> > My point is that which patterns are expected to be complete is an API > design choice, subject to API stability decisions, and not just a > matter > of deductive reasoning. Now I understand: Even though completeness is (provably) provable, the COMPLETE pragma can signal the library user which sets of patterns the library author intended to cover the (opaque) type, much like the MINIMAL pragma for type classes. Otherwise the library user could only know this by compiling a code snippet with -Wincomplete-uni-patterns. To further draw the parallel between MINIMAL and COMPLETE, is COMPLETE picked up by Haddock? Seems not: The Data.Sequence.Internal module contains {-# COMPLETE (:<|), Empty #-} {-# COMPLETE (:|>), Empty #-} yet the "bundled patterns" section in https://hackage.haskell.org/package/containers-0.7/docs/Data-Sequence.html#t:Seq does not show it. If COMPLETE is indeed never picked up by Haddock, I'd say this pragma is currently fairly useless for conveying contracts. Should we open a feature request at Haddock? Olaf From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Fri Jan 19 13:21:56 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 19 Jan 2024 13:21:56 +0000 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns In-Reply-To: <68e7b76f662d684cbec2149998141bcea5675b64.camel@aatal-apotheke.de> References: <68e7b76f662d684cbec2149998141bcea5675b64.camel@aatal-apotheke.de> Message-ID: On Fri, Jan 19, 2024 at 02:15:06PM +0100, Olaf Klinke wrote: > To further draw the parallel between MINIMAL and COMPLETE, is COMPLETE > picked up by Haddock? Seems not: [...] > Should we open a feature request at Haddock? I think that would be a good idea. A cursory search suggests there's no feature request already: https://github.com/haskell/haddock/issues?q=is%3Aissue+is%3Aopen+complete From m at jaspervdj.be Fri Jan 19 13:40:52 2024 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Fri, 19 Jan 2024 14:40:52 +0100 Subject: [Haskell-cafe] ZuriHac 2014 takes place 8-10 June, registration now open Message-ID: Hi Friends of Haskell, It is our pleasure to announce that ZuriHac 2024 will take place Saturday 8 June - Monday 10 June 2024 as a physical event at the Rapperswil-Jona campus of the OST Eastern Switzerland University of Applied Sciences. The focus of ZuriHac is being a community event and hackathon, but we will also have some exciting keynotes from Ningning Xie, Alex McLean, Ivan Perez and Mary Sheeran. In addition to that, there will be some more hands-on content: Well-Typed will host a workshop, Jesper Cockx will host an Agda track and Manuel Bärenz will host an FRP Track. We also welcome beginners or people unfamiliar to Haskell who are curious to learn more. Eliane Schmidli will teach a beginners workshop, and there will be many mentors from the Haskell Community happy to answer all your questions. Two days prior to ZuriHac, the Haskell Foundation and OST will organize a co-located 2-day Haskell Infrastructure Workshop. More details about that will be announced soon. You can find more information about the event and register at . The event is free for participants. This is only possible with the help of our generous supporters, who are currently: - The Haskell Foundation - Jane Street - OST Eastern Switzerland University of Applied Sciences - Tweag - Well-Typed In case you would like to support ZuriHac, please get in touch with us. We hope to see you there! The Zurich Friends of Haskell From olf at aatal-apotheke.de Fri Jan 19 16:49:57 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 19 Jan 2024 17:49:57 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: <43a7d96379b65c7af183bec4124843b6a293fd8b.camel@aatal-apotheke.de> > > Should we open a feature request at Haddock? > > I think that would be a good idea. A cursory search suggests there's > no feature request already Done: https://github.com/haskell/haddock/issues/1625 I would also like to humbly suggest that the GHC devs consider my proof that pattern synonym completeness checks are decidable, thus improving the situation that caused this thread. I have a proof-of-concept implementation with a type signature like covers :: PatternMatch t => [Pattern t] -> Bool where  type Pattern t = t -> Bool  and PatternMatch is a type class much like Generic which derives instances for all Generic Rep types (except V1) plus function spaces and fixed points. What is left to do is to convert the GHC-internal pattern representation into (t -> Bool). Is that feasible? As I elaborated, that task ist quite mechanistic and could likely be done in Template Haskell. Olaf From ietf-dane at dukhovni.org Fri Jan 19 20:01:51 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jan 2024 15:01:51 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> Message-ID: On Fri, Jan 19, 2024 at 10:55:15AM +0100, Jo Durchholz wrote: > > That's far from accurate. TLS 1.0, though dated, is quite adequate for > > many non-browser applications. > > Well... sort-of. It depends on SHA-1 for initial handshake and peer > authentication (both relevant to prevent man-in-the-middle attacks), Actually, the TLS 1.0 hash algorithm used in digital signatures is SHA1+MD5, and there are no known practical attacks on that construction. https://datatracker.ietf.org/doc/html/rfc2246#section-7.4.3 select (SignatureAlgorithm) { case anonymous: struct { }; case rsa: digitally-signed struct { opaque md5_hash[16]; opaque sha_hash[20]; }; case dsa: digitally-signed struct { opaque sha_hash[20]; }; } Signature; There are some theoretical attacks on concatenated hashes that suggest they're not quite as strong as one might naïvely hope, but this has little practical impact. The TLS 1.0 bulk ciphers use SHA1-HMAC (not raw SHA1): https://datatracker.ietf.org/doc/html/rfc2246#section-6.2.3.1 There are no known practical attacks on HMAC. In the browser context, there have been some practical attacks on CBC mac-then-acrypt ciphers used in TLS 1.0, but they're easily mitigated by negotiating EtM: https://datatracker.ietf.org/doc/html/rfc7366#section-2 In any case, communication with legacy systems via TLS 1.0 is substantially safer than in the clear. -- Viktor. From ietf-dane at dukhovni.org Fri Jan 19 20:04:17 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jan 2024 15:04:17 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <20240119.184155.1070251071643932343.kazu@iij.ad.jp> References: <20240119.182113.990978677007904879.kazu@iij.ad.jp> <20240119.184155.1070251071643932343.kazu@iij.ad.jp> Message-ID: On Fri, Jan 19, 2024 at 06:41:55PM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > > TLS is not just for the web. There are various application ecosystems > > that are noticeably less agile than web browsers, and substantially not > > at risk from the various browser-related attacks on TLS 1.0. > > Why cannot you switch to TLS 1.2? I don't control the software stacks used by others, with whom I still need to communicate. Or with legacy devices, ... > TLS 1.2 is 16 year old, very similar to TLS 1.0 and much more secure. But note that TLS 1.0 is much more secure than cleartext. It is fine to disable it by default, but I would prefer that it still be available. -- Viktor. From jo at durchholz.org Fri Jan 19 21:29:27 2024 From: jo at durchholz.org (Jo Durchholz) Date: Fri, 19 Jan 2024 22:29:27 +0100 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> Message-ID: <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> Thing is, you are doing analysis to argue that your usage is safe enough. Which is exactly the kind of overhead you'll have to do whenever the security landscape changes. Also, it would likely be a good idea to add some push towards 1.2. If entire ecosystems still stick with 1.x, they're rotten. I know that some ecosystems just are that way; the best we can do is to add some small push towards a better policy, and it's the least we *should* do. Regards, Jo From ietf-dane at dukhovni.org Fri Jan 19 22:27:44 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Jan 2024 17:27:44 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> Message-ID: On Fri, Jan 19, 2024 at 10:29:27PM +0100, Jo Durchholz wrote: > Thing is, you are doing analysis to argue that your usage is safe enough. > Which is exactly the kind of overhead you'll have to do whenever the > security landscape changes. My use case is basically opportunistic TLS in SMTP, which is typically unauthenticated, and best-effort (also DoT to auth in DNS). TLS 1.0 is better than cleartext. I am also operating a broad deployment survey, and the survey needs to be able to connect with whatever the other end supports. Security against active attacks is irrelevant. I am not suggesting that anyone should stick with TLS 1.0, though it is in practice "good enough" in some applications. Its deployment numbers are substantially lower and falling. I was just asking that TLS 1.0 continue to be available when explicitly requested, rather than removed. > Also, it would likely be a good idea to add some push towards 1.2. > If entire ecosystems still stick with 1.x, they're rotten. I know that some > ecosystems just are that way; the best we can do is to add some small push > towards a better policy, and it's the least we *should* do. The push has already happened, TLS 1.3 is widely available and is negotiated by default when supported by both ends. The negotation is downgrade-resistant. It is addition of TLS 1.3 support, not removal of TLS 1.0 support that has the biggest impact on improved security. There are however still some pockets of devices and systems, and it is a judgement call as to when it is appropriate to cut off interoperability with those systems. Yes, it could be now, but a case can be made that this does not improve security, though it does perhaps reduce support effort if there is still a real support burden in keeping the TLS 1.0 code working. -- Viktor. From jo at durchholz.org Fri Jan 19 22:43:22 2024 From: jo at durchholz.org (Jo Durchholz) Date: Fri, 19 Jan 2024 23:43:22 +0100 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> Message-ID: <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> Thanks for the explanations; I now have a better understanding of the issues at hand, and I hope this has helped others as well. My personal take would be to move TLS 1.0/1 out into a separate library, say, tls-deprecated. One, this clearly marks the mechanism as something not to be used unless you really need it. Second, people who just use TLS will stick with the standard tls library, and won't get old TLS activated by some funny accident (such as misconfiguration); after all, code that isn't there can't be involved in some security shenanigans. Just my 2 cents, trying to reconcile legacy needs and security-by-design aspects as far as possible. I hope it helps somebody. Regards, Jo From me at michaelpj.com Fri Jan 19 23:13:32 2024 From: me at michaelpj.com (Michael Peyton Jones) Date: Fri, 19 Jan 2024 23:13:32 +0000 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> Message-ID: This can be a good use for a cabal flag. You can have a manual, off-by-default flag that enables it. Then you don't need another package. M On Fri, 19 Jan 2024, 22:44 Jo Durchholz, wrote: > Thanks for the explanations; I now have a better understanding of the > issues at hand, and I hope this has helped others as well. > > My personal take would be to move TLS 1.0/1 out into a separate library, > say, tls-deprecated. > One, this clearly marks the mechanism as something not to be used unless > you really need it. > Second, people who just use TLS will stick with the standard tls > library, and won't get old TLS activated by some funny accident (such as > misconfiguration); after all, code that isn't there can't be involved in > some security shenanigans. > > Just my 2 cents, trying to reconcile legacy needs and security-by-design > aspects as far as possible. > I hope it helps somebody. > > Regards, > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dennis.raddle at gmail.com Fri Jan 19 23:16:04 2024 From: dennis.raddle at gmail.com (Dennis Raddle) Date: Fri, 19 Jan 2024 15:16:04 -0800 Subject: [Haskell-cafe] Parallel Haskell on an M2 Mac In-Reply-To: References: Message-ID: Thanks, I'll check out the book. On Fri, Jan 19, 2024 at 4:47 AM Bryan Richter wrote: > I'd also be curious to know if you can somehow distinguish the types of > cores from each other, but otherwise all the usual parallel stuff should > work on Arm-based Macs as it works on other platforms supported by GHC. The > book described at https://simonmar.github.io/pages/pcph.html is still the > best source for learning about parallel Haskell. > > On Fri, 19 Jan 2024 at 08:22, Dennis Raddle > wrote: > >> I don't know a lot about parallel Haskell, so I'm wondering in general >> terms how that would work with my M2 Mac. I have a search task that's >> easily run in parallel. For example, I might map a function over a list, >> and each item's evaluation can run in parallel. On the M2 MacBook I have, >> there are 4 efficiency cores with 1 thread each, and 8 performance cores >> with 2 threads each. Is it fairly easy to use parallel Haskell to spread >> the task over these 20 possible threads? By any chance could I limit it to >> using the performance cores if that helps the speed? >> >> Thanks, >> Dennis >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri Jan 19 23:18:57 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 20 Jan 2024 00:18:57 +0100 (CET) Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> Message-ID: On Fri, 19 Jan 2024, Michael Peyton Jones wrote: > This can be a good use for a cabal flag. You can have a manual, off-by-default flag that enables it. > Then you don't need another package. The API should never depend on a Cabal flag, because an importing package cannot specify a flag in Build-Depends. From lemming at henning-thielemann.de Fri Jan 19 23:21:27 2024 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 20 Jan 2024 00:21:27 +0100 (CET) Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <20240119.102156.1691993915644292247.kazu@iij.ad.jp> <0a8e7c23-2ad6-4c21-9360-9eb6360ca283@durchholz.org> <1cae22be-4553-4869-a65b-3f77c27e4342@durchholz.org> <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> Message-ID: On Sat, 20 Jan 2024, Henning Thielemann wrote: > On Fri, 19 Jan 2024, Michael Peyton Jones wrote: > >> This can be a good use for a cabal flag. You can have a manual, >> off-by-default flag that enables it. >> Then you don't need another package. > > The API should never depend on a Cabal flag, because an importing package > cannot specify a flag in Build-Depends. However, a solution might be, that both tls-1.x and tls-2.x branches are kept maintained and get regular updates. From harendra.kumar at gmail.com Sat Jan 20 19:10:28 2024 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sun, 21 Jan 2024 00:40:28 +0530 Subject: [Haskell-cafe] Parallel Haskell on an M2 Mac In-Reply-To: References: Message-ID: Hi Dennis, For easy concurrent/parallel processing you may find the Haskell library "streamly" to be helpful. Please see the quick tutorial here: https://streamly.composewell.com/streamly-0.9.0/User/Tutorials/quick-overview.html . There are some concurrency/parallelism examples provided in this tutorial. If you want to run some external programs concurrently and process the output in a Haskell program you may also want to take a look at the streamly-process package here: https://hackage.haskell.org/package/streamly-process . In case you need further help on using the library, I can help you out. I am a contributor to the library. -harendra On Fri, 19 Jan 2024 at 11:52, Dennis Raddle wrote: > > I don't know a lot about parallel Haskell, so I'm wondering in general terms how that would work with my M2 Mac. I have a search task that's easily run in parallel. For example, I might map a function over a list, and each item's evaluation can run in parallel. On the M2 MacBook I have, there are 4 efficiency cores with 1 thread each, and 8 performance cores with 2 threads each. Is it fairly easy to use parallel Haskell to spread the task over these 20 possible threads? By any chance could I limit it to using the performance cores if that helps the speed? > > Thanks, > Dennis > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From olf at aatal-apotheke.de Sat Jan 20 20:36:32 2024 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 20 Jan 2024 21:36:32 +0100 Subject: [Haskell-cafe] Wincomplete-uni-patterns and bidirectional patterns Message-ID: > For functions types, there is only one equivalence class, because > there > is only one way to pattern-match a function. Observe that two > elements > can be distinguished by a set of patterns if and only if there is one > element in the pattern set that already distinguishes them. Do > pattern > synonyms refine the equivalence relation induced by ordinary > constructors? No. What I said is only true in the absence of view patterns. With view patterns, a pattern match is no longer guaranteed to terminate, since the viewing function could diverge on the value being matched. Consider -- diverges on infinite lists end :: [a] -> [a] end xs = case tl xs of [] -> [] (_:xs') -> end xs' pattern Finite <- (end -> []) isFinite :: [a] -> Bool isFinite xs = case xs of Finite -> True _ -> False Notice that isFinite is no longer a clopen but an open: It either returns True or diverges. Moreover, view patterns introduce fine- grained clopens on function spaces, like pattern Q <- (($ 4) -> 3) We must conclude that in the presence of the ViewPatterns extension, the equivalenve relation induced by pattern matching is: "x~y whenever there is no function v and no pattern P such that (v x) and (v y) can be distinguished by P." It should not be hard to prove that deciding coverage by view patterns such as Finite would solve the halting problem.  Olaf From kazu at iij.ad.jp Sun Jan 21 00:09:45 2024 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Sun, 21 Jan 2024 09:09:45 +0900 (JST) Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> References: <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> Message-ID: <20240121.090945.446904820457511236.kazu@iij.ad.jp> Hi, I hit upon a solution for Viktor. TLS 1.0/1.1 code is kept and enabled via a special parameter. Old cipher suites including CBC are provided by "tls-insecure" or something. I'm surprised because Jo already proposed the same solution. :-) So, I would support his proposal. Viktor, could you volunteer to maintain the "tls-deprecated" package? --Kazu > Thanks for the explanations; I now have a better understanding of the > issues at hand, and I hope this has helped others as well. > > My personal take would be to move TLS 1.0/1 out into a separate > library, say, tls-deprecated. > One, this clearly marks the mechanism as something not to be used > unless you really need it. > Second, people who just use TLS will stick with the standard tls > library, and won't get old TLS activated by some funny accident (such > as misconfiguration); after all, code that isn't there can't be > involved in some security shenanigans. > > Just my 2 cents, trying to reconcile legacy needs and > security-by-design aspects as far as possible. > I hope it helps somebody. > > Regards, > Jo > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ietf-dane at dukhovni.org Sun Jan 21 00:24:49 2024 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 20 Jan 2024 19:24:49 -0500 Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: <20240121.090945.446904820457511236.kazu@iij.ad.jp> References: <4093518e-0f33-41ba-be19-80c04c1898ba@durchholz.org> <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> <20240121.090945.446904820457511236.kazu@iij.ad.jp> Message-ID: On Sun, Jan 21, 2024 at 09:09:45AM +0900, Kazu Yamamoto (山本和彦) via Haskell-Cafe wrote: > I hit upon a solution for Viktor. > TLS 1.0/1.1 code is kept and enabled via a special parameter. > Old cipher suites including CBC are provided by > "tls-insecure" or something. Thanks, can you be more specific? Is this a run-time or build-time flag? [ FWIW, properly used, e.g. with Encrypt-then-MAC (EtM) CBC ciphers are actually more robust in practice than GCM, because they're not subject to complete failure on nonce reuse. ] > I'm surprised because Jo already proposed the same solution. :-) > So, I would support his proposal. > > Viktor, could you volunteer to maintain the "tls-deprecated" package? Can you elaborate on what's involved? I may be able to make sure it builds with recent-enogh GHC, ... if that's the bulk of the effort and there are no new features to worry about. -- Viktor. From kazu at iij.ad.jp Sun Jan 21 00:59:26 2024 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Sun, 21 Jan 2024 09:59:26 +0900 (JST) Subject: [Haskell-cafe] heads-up: tls v2.0.0 In-Reply-To: References: <528c1387-9186-47e1-97ae-ad91e1c74901@durchholz.org> <20240121.090945.446904820457511236.kazu@iij.ad.jp> Message-ID: <20240121.095926.1733354465168011000.kazu@iij.ad.jp> > Thanks, can you be more specific? Is this a run-time or build-time > flag? Via "Supported" in ClientParams/ServerParams. > Can you elaborate on what's involved? I may be able to make sure it > builds with recent-enogh GHC, ... if that's the bulk of the effort > and there are no new features to worry about. Probably, testing and/or checking version boundaries when a new version of "tls" is released. And upload a new version or modify the metadata on Hackage. --Kazu From mitchellwrosen at gmail.com Tue Jan 23 16:56:14 2024 From: mitchellwrosen at gmail.com (Mitchell Rosen) Date: Tue, 23 Jan 2024 11:56:14 -0500 Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: Is this still the right place to make takeover requests? On Sat, Jan 13, 2024 at 7:30 PM Mitchell Rosen wrote: > I see, that's some interesting history. The claim that Data.Sequence is > faster than Data.Queue is wrong, though, as far as I can tell (see > benchmark in repo), so maybe it was a mistake to remove from base if that > really was the rationale. Are there any records of that > conversation/decision? Also, a minor point - Data.Sequence only has > amortized O(1) enqueue and dequeue, whereas Data.Queue has O(1) worst-case > enqueue and dequeue. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk Tue Jan 23 17:11:43 2024 From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Jan 2024 17:11:43 +0000 Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: It is the recommended public forum, according to: https://wiki.haskell.org/Taking_over_a_package On Tue, Jan 23, 2024 at 11:56:14AM -0500, Mitchell Rosen wrote: > Is this still the right place to make takeover requests? > > On Sat, Jan 13, 2024 at 7:30 PM Mitchell Rosen > wrote: > > > I see, that's some interesting history. The claim that Data.Sequence is > > faster than Data.Queue is wrong, though, as far as I can tell (see > > benchmark in repo), so maybe it was a mistake to remove from base if that > > really was the rationale. Are there any records of that > > conversation/decision? Also, a minor point - Data.Sequence only has > > amortized O(1) enqueue and dequeue, whereas Data.Queue has O(1) worst-case > > enqueue and dequeue. From fa-ml at ariis.it Tue Jan 23 17:12:52 2024 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 23 Jan 2024 18:12:52 +0100 Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: Il 23 gennaio 2024 alle 11:56 Mitchell Rosen ha scritto: > Is this still the right place to make takeover requests? It is, follow the recommended procedure https://wiki.haskell.org/Taking_over_a_package So put the current maintainer in CC, wait a while, then contact Hackage admins —F From mitchellwrosen at gmail.com Tue Jan 23 23:54:23 2024 From: mitchellwrosen at gmail.com (Mitchell Rosen) Date: Tue, 23 Jan 2024 18:54:23 -0500 Subject: [Haskell-cafe] `queue` package take-over request In-Reply-To: References: Message-ID: Great, thanks – I neglected to CC the original author though I did reach out via private correspondence. CC'ing now. On Tue, Jan 23, 2024 at 12:13 PM Francesco Ariis wrote: > Il 23 gennaio 2024 alle 11:56 Mitchell Rosen ha scritto: > > Is this still the right place to make takeover requests? > > It is, follow the recommended procedure > > https://wiki.haskell.org/Taking_over_a_package > > So put the current maintainer in CC, wait a while, then contact > Hackage admins > —F > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Sun Jan 28 09:58:45 2024 From: adam at well-typed.com (Adam Gundry) Date: Sun, 28 Jan 2024 09:58:45 +0000 Subject: [Haskell-cafe] GHC Steering Committee Call for Nominations Message-ID: Dear Haskellers, The GHC Steering Committee is seeking nominations for new members. The committee scrutinizes, debates and eventually decides to accept or reject proposals to change the language or major features supported by GHC. Our processes are described in the GitHub repository where proposals are submitted (https://github.com/ghc-proposals/ghc-proposals). In particular, please have a look at the committee bylaws (https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst). We are looking for members who have the ability to: - understand GHC proposals (e.g. for new language extensions), - find holes and missing corner cases in the specifications, - foresee the interaction with other language or compiler features, - comment constructively and improve proposals through engagement with others, - judge the cost/benefit ratio of changes, and - come to a justifiable conclusion. Ideally, committee members should: - have substantial experience of writing or teaching Haskell; - have a track record of active contributions to the Haskell community; or - have expertise in language design and implementation, in either Haskell or related languages. It is our aim that this committee be diverse; by representing different viewpoints, we will make decisions that benefit larger segments of our community. Even if you are uncertain whether your background qualifies you for the role, you are warmly encouraged to apply. The committee's work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. To nominate yourself, please send an email to me (as the committee secretary) at adam at well-typed.com by February 16th 2024, briefly summarising your background and relevant experience. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. Self-nominations are the norm. You can nominate someone else, but please obtain their explicit consent to do so. (We don't want to choose someone who turns out to be unable to serve.) On behalf of the committee, Adam Gundry -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From lc985 at cam.ac.uk Wed Jan 31 18:36:15 2024 From: lc985 at cam.ac.uk (L. Cicolini) Date: Wed, 31 Jan 2024 18:36:15 +0000 Subject: [Haskell-cafe] CGO24 - Early-bird Deadline Registration Message-ID: ACM/IEEE International Symposium on Code Generation and Optimization (CGO 2024) Call for Participation - Early Bird Registration The International Symposium on Code Generation and Optimization (CGO) is a premier venue to bring together researchers and practitioners working at the interface of hardware and software on a wide range of optimization and code generation techniques and related issues. The conference spans the spectrum from purely static to fully dynamic approaches, and from pure software-based methods to specific architectural features and support for code generation and optimization. Registration (early-bird deadline: February 2) https://conf.researchr.org/attending/cgo-2024/registration Registration to CGO will give you full access to all co-located events on the day(s) selected (CC, PPoPP, HPCA). Detailed program: https://conf.researchr.org/program/cgo-2024/program-cgo-2024/ List of accepted papers: https://conf.researchr.org/info/cgo-2024/accepted-papers List of workshops/tutorials: https://conf.researchr.org/info/cgo-2024/workshops For more information, please visit the CGO conference website at https://conf.researchr.org/home/cgo-2024 *Copyright © 2024 CGO Conference, All rights reserved.* You are receiving this email because you have submitted to or attended CGO. -------------- next part -------------- An HTML attachment was scrubbed... URL: