From johannes.waldmann at htwk-leipzig.de Mon Jul 1 19:09:13 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 1 Jul 2019 21:09:13 +0200 Subject: [Haskell-cafe] NB: DO NOT USE `pure = return` Message-ID: <8f7a51bf-ff22-99ec-3238-540e4fa5a900@htwk-leipzig.de> Dear Cafe, the migration guide (for AMP) https://gitlab.haskell.org/ghc/ghc/wikis/migration/7.10#ghc-says-no-instance-for-applicative- contains this advice: instance Applicative Foo where -- NB: DO NOT USE `pure = return` Why not? Because it would require another refactoring once "monad of no return" comes true? So defining `return` in the Monad instance should work fine until then? Which is when exactly? I can't quite make it out from https://gitlab.haskell.org/ghc/ghc/wikis/proposal/monad-of-no-return/discussion - J.W. From allbery.b at gmail.com Mon Jul 1 19:12:12 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 1 Jul 2019 15:12:12 -0400 Subject: [Haskell-cafe] NB: DO NOT USE `pure = return` In-Reply-To: <8f7a51bf-ff22-99ec-3238-540e4fa5a900@htwk-leipzig.de> References: <8f7a51bf-ff22-99ec-3238-540e4fa5a900@htwk-leipzig.de> Message-ID: Most likely because MonadOfNoReturn will transitionally define return = pure, and instead of a compile error error you would end up with runtime infinite loops. On Mon, Jul 1, 2019 at 3:09 PM Johannes Waldmann < johannes.waldmann at htwk-leipzig.de> wrote: > Dear Cafe, > > the migration guide (for AMP) > > > https://gitlab.haskell.org/ghc/ghc/wikis/migration/7.10#ghc-says-no-instance-for-applicative- > > contains this advice: > > instance Applicative Foo where > -- NB: DO NOT USE `pure = return` > > Why not? Because it would require another refactoring > once "monad of no return" comes true? > > So defining `return` in the Monad instance should work fine until then? > Which is when exactly? I can't quite make it out from > > https://gitlab.haskell.org/ghc/ghc/wikis/proposal/monad-of-no-return/discussion > > > - J.W. > > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Jul 1 19:16:51 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 01 Jul 2019 15:16:51 -0400 Subject: [Haskell-cafe] The future of the SPARC NCG backend In-Reply-To: <87d0izvt1n.fsf@smart-cactus.org> References: <87d0izvt1n.fsf@smart-cactus.org> Message-ID: <87h885va3j.fsf@smart-cactus.org> Hello everyone, If you use (or think you might use in the future) GHC's SPARC NCG backend please do leave a note on #16882 [1]. My impression is that it has no users and no plausible means of testing. Consequently I am suggesting that we remove it in GHC 8.12. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/issues/16882 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From nr at cs.tufts.edu Fri Jul 5 13:34:37 2019 From: nr at cs.tufts.edu (Norman Ramsey) Date: Fri, 05 Jul 2019 09:34:37 -0400 Subject: [Haskell-cafe] Help wanted getting old GADT code to compile Message-ID: <20190705133437.7398F7855BA@labrador.cs.tufts.edu> Here is a legacy file that does not compile with GHC 8.0.1: {-# LANGUAGE RankNTypes, GADTs, KindSignatures #-} module Bookgadt where data TExp :: * -> * where TLit :: (forall a . (a -> (TExp a))) TLit' :: (a -> (TExp a)) The compiler rejects value constructor TLit with this error message: • Data constructor ‘TLit’ returns type ‘forall a. a -> TExp a’ instead of an instance of its parent type ‘TExp a’ I really want to keep the explicit "forall," as I'm trying to make a point for readers not familiar with Haskell. Does anyone know if there is some option or other incantation that would enable this code to compile? Norman From rae at richarde.dev Fri Jul 5 13:44:47 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 5 Jul 2019 09:44:47 -0400 Subject: [Haskell-cafe] Help wanted getting old GADT code to compile In-Reply-To: <20190705133437.7398F7855BA@labrador.cs.tufts.edu> References: <20190705133437.7398F7855BA@labrador.cs.tufts.edu> Message-ID: Hi Norman, This is a bug in GHC 8.0.1, fixed in later versions. Dropping the parentheses around your forall-type will fix the problem: > TLit :: forall a . (a -> (TExp a) GHC uses something of a dumb algorithm for detecting the result of a constructor, and that algorithm got stymied by parentheses. Even today, it gets stymied by, e.g., type families, but at least it knows about parentheses. I hope this helps! Richard > On Jul 5, 2019, at 9:34 AM, Norman Ramsey wrote: > > Here is a legacy file that does not compile with GHC 8.0.1: > > > {-# LANGUAGE RankNTypes, GADTs, KindSignatures #-} > > module Bookgadt > where > > data TExp :: * -> * where > TLit :: (forall a . (a -> (TExp a))) > TLit' :: (a -> (TExp a)) > > > > The compiler rejects value constructor TLit with this error message: > > • Data constructor ‘TLit’ returns type ‘forall a. a -> TExp a’ > instead of an instance of its parent type ‘TExp a’ > > I really want to keep the explicit "forall," as I'm trying to make a > point for readers not familiar with Haskell. Does anyone know if > there is some option or other incantation that would enable this code > to compile? > > > Norman > _______________________________________________ > 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 lysxia at gmail.com Fri Jul 5 13:44:43 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Fri, 5 Jul 2019 09:44:43 -0400 Subject: [Haskell-cafe] Help wanted getting old GADT code to compile In-Reply-To: <20190705133437.7398F7855BA@labrador.cs.tufts.edu> References: <20190705133437.7398F7855BA@labrador.cs.tufts.edu> Message-ID: <6fc2df82-3c34-5035-bd59-d4afd22512ec@gmail.com> Hi Norman, Try removing the parentheses; they are all redundant but GHC might be a bit too strict about them. Li-yao On 7/5/19 9:34 AM, Norman Ramsey wrote: > Here is a legacy file that does not compile with GHC 8.0.1: > > > {-# LANGUAGE RankNTypes, GADTs, KindSignatures #-} > > module Bookgadt > where > > data TExp :: * -> * where > TLit :: (forall a . (a -> (TExp a))) > TLit' :: (a -> (TExp a)) > > > > The compiler rejects value constructor TLit with this error message: > > • Data constructor ‘TLit’ returns type ‘forall a. a -> TExp a’ > instead of an instance of its parent type ‘TExp a’ > > I really want to keep the explicit "forall," as I'm trying to make a > point for readers not familiar with Haskell. Does anyone know if > there is some option or other incantation that would enable this code > to compile? > > > Norman > _______________________________________________ > 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 stefan.wehr at gmail.com Mon Jul 8 05:45:24 2019 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Mon, 8 Jul 2019 07:45:24 +0200 Subject: [Haskell-cafe] Call for Participation: Summer BOB 2019 (August 21, Berlin) Message-ID: ======================================================================== Summer BOB 2019 Conference “What happens if we simply use what’s best?” August 21, 2019, Berlin co-located with ICFP 2019 http://bobkonf.de/2019-summer/ Program: http://bobkonf.de/2019-summer/program.html Registration: http://bobkonf.de/2019-summer/registration.html ======================================================================== Are you interested in technologies beyond the mainstream, that are a pleasure to use, and effective at getting the job done? BOB is the forum for developers, architects and builders to explore and discover the best tools available today for building software. Our goal is for all participants to leave the conference with new ideas to improve development back at the ranch. Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. BOB features two tracks of seven talk each: One research track with invited talks, and one track by practitioners, designed to cross-pollinate and inspire. http://bobkonf.de/2019-summer/program.html Topics include distributed programming, testing, linear algebra, functional design patterns, type systems, formal methods, and interactive development. We are committed to diversity: We aim at exploring a wide range of tools in a welcoming and friendly crowd of diverse people. To that end, a number of support options for participants from groups under-represented in tech are available. http://bobkonf.de/2019-summer/registration.html NOTE: The early-bird rates expire on July 18, 2019! -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannes.waldmann at htwk-leipzig.de Mon Jul 8 09:50:33 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 8 Jul 2019 11:50:33 +0200 Subject: [Haskell-cafe] {-# SPECIALIZE foo @Bar #-} ? Message-ID: <4026c7a0-bc14-954a-3f59-d9e176a3a849@htwk-leipzig.de> Dear Cafe, with pragma SPECIALIZE, I find it tedious to repeat the type declaration. (It's a burden for maintenance and readability.) Could we use type-application syntax instead? E.g., the example from here https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#specialize-pragma hammeredLookup :: Ord key => [(key, value)] -> key -> value {-# SPECIALIZE hammeredLookup :: [(Widget, value)] -> Widget -> value #-} would become hammeredLookup :: forall key value . Ord key => [(key, value)] -> key -> value {-# SPECIALIZE hammeredLookup @Widget #-} or {-# SPECIALIZE hammeredLookup @Widget @value #-} Cf. SPECIALIZE instance, where we already write the instantiation for the type variable(s). - J.W. From theflossinformation at yandex.com Mon Jul 8 12:54:42 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Mon, 08 Jul 2019 15:54:42 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?3?= In-Reply-To: References: Message-ID: <386081562590482@mxfront2q.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From ganesh at earth.li Mon Jul 8 13:49:49 2019 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon, 8 Jul 2019 14:49:49 +0100 Subject: [Haskell-cafe] {-# SPECIALIZE foo @Bar #-} ? In-Reply-To: <4026c7a0-bc14-954a-3f59-d9e176a3a849@htwk-leipzig.de> References: <4026c7a0-bc14-954a-3f59-d9e176a3a849@htwk-leipzig.de> Message-ID: <5aceeb3c-9c32-4523-303b-114c34e94b46@earth.li> On 08/07/2019 10:50, Johannes Waldmann wrote: > with pragma SPECIALIZE, > I find it tedious to repeat the type declaration. > (It's a burden for maintenance and readability.) > > > Could we use type-application syntax instead? There's an inactive GHC proposal for this: https://github.com/ghc-proposals/ghc-proposals/pull/15 Also a bit of discussion on this StackOverflow question: https://stackoverflow.com/questions/39379531/how-do-i-specialise-with-an-explicit-type-application Cheers, Ganesh From olf at aatal-apotheke.de Mon Jul 8 20:37:05 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 8 Jul 2019 22:37:05 +0200 Subject: [Haskell-cafe] mapM and Control.Arrow Message-ID: Dear cafe, consider the declaration mapM :: (SomeArrow a, Traversable t) => a b c -> a (t b) (t c) For the Arrow a = (->), the above mapM is just an over-constrained fmap, since Functor is a superclass of Traversable. For the arrow a = Kleisi m, the above mapM is the Control.Monad.mapM we know. Currently I fail to see how it could be defined with any of the existing sub-classes in Control.Arrow. One might say that fmap and mapM are on the same spectrum: If you specialize SomeArrow to (->) you can generalize Traversable to Functor, if you specialize Functor to Traversable you can generalize (->) to SomeArrow. Cheers, Olaf From zemyla at gmail.com Mon Jul 8 23:07:34 2019 From: zemyla at gmail.com (Zemyla) Date: Mon, 8 Jul 2019 18:07:34 -0500 Subject: [Haskell-cafe] mapM and Control.Arrow In-Reply-To: References: Message-ID: It needs to be an ArrowChoice, not just an Arrow, but it can be done. https://github.com/ekmett/profunctors/pull/40 On Mon, Jul 8, 2019, 15:37 Olaf Klinke wrote: > Dear cafe, > > consider the declaration > > mapM :: (SomeArrow a, Traversable t) => a b c -> a (t b) (t c) > > For the Arrow a = (->), the above mapM is just an over-constrained fmap, > since Functor is a superclass of Traversable. For the arrow a = Kleisi m, > the above mapM is the Control.Monad.mapM we know. Currently I fail to see > how it could be defined with any of the existing sub-classes in > Control.Arrow. > > One might say that fmap and mapM are on the same spectrum: If you > specialize SomeArrow to (->) you can generalize Traversable to Functor, if > you specialize Functor to Traversable you can generalize (->) to SomeArrow. > > Cheers, > Olaf > _______________________________________________ > 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 Tue Jul 9 08:17:33 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 9 Jul 2019 10:17:33 +0200 (CEST) Subject: [Haskell-cafe] parallel Haskell with limited sparks Message-ID: When I read about parallel programming in Haskell it is always about manual chunking of data. Why? Most of my applications with parallelization benefit from a different computation scheme: Start a fixed number of threads (at most the number of available computing cores) and whenever a thread finishes a task it gets assigned a new one. This is how make -j, cabal install -j, ghc -j, work. I wrote my own package pooled-io which does the same for IO in Haskell and there seem to be more packages that implemented the same idea. Can I have that computation scheme for non-IO computations, too? With Parallel Strategies, monad-par etc.? From lemming at henning-thielemann.de Tue Jul 9 09:02:46 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 9 Jul 2019 11:02:46 +0200 (CEST) Subject: [Haskell-cafe] parallel Haskell with limited sparks In-Reply-To: References: Message-ID: On Tue, 9 Jul 2019, Henning Thielemann wrote: > When I read about parallel programming in Haskell it is always about manual > chunking of data. Why? Most of my applications with parallelization benefit > from a different computation scheme: Start a fixed number of threads (at most > the number of available computing cores) and whenever a thread finishes a > task it gets assigned a new one. This is how make -j, cabal install -j, ghc > -j, work. I wrote my own package pooled-io which does the same for IO in > Haskell and there seem to be more packages that implemented the same idea. > Can I have that computation scheme for non-IO computations, too? With > Parallel Strategies, monad-par etc.? Maybe I misunderstood something and the stuff from the 'parallel' package already works the way I expected and starting 100 sparks does not mean that GHC tries to run 100 threads concurrently and chunking is only necessary when computing the single list elements in parallel is too much parallelization overhead. From b at chreekat.net Tue Jul 9 10:07:06 2019 From: b at chreekat.net (Bryan Richter) Date: Tue, 9 Jul 2019 13:07:06 +0300 Subject: [Haskell-cafe] parallel Haskell with limited sparks In-Reply-To: References: Message-ID: <419345d5-e965-ff06-9564-4cdacf3c0f6c@chreekat.net> On 7/9/19 12:02 PM, Henning Thielemann wrote: > > On Tue, 9 Jul 2019, Henning Thielemann wrote: > >> When I read about parallel programming in Haskell it is always >> about manual chunking of data. Why? Most of my applications with >> parallelization benefit from a different computation scheme: Start >> a fixed number of threads (at most the number of available >> computing cores) and whenever a thread finishes a task it gets >> assigned a new one. This is how make -j, cabal install -j, ghc -j, >> work. I wrote my own package pooled-io which does the same for IO >> in Haskell and there seem to be more packages that implemented >> the same idea. Can I have that computation scheme for non-IO >> computations, too? With Parallel Strategies, monad-par etc.? > > Maybe I misunderstood something and the stuff from the 'parallel' > package already works the way I expected and starting 100 sparks > does not mean that GHC tries to run 100 threads concurrently and > chunking is only necessary when computing the single list elements > in parallel is too much parallelization overhead. This is absolutely correct. :) GHC doesn’t force us to use a fixed number of rpar calls; we can call it as many times as we like, and the system will automatically distribute the parallel work among the available cores. If the work is divided into smaller chunks, then the system will be able to keep all the cores busy for longer. A fixed division of work is often called static partitioning, whereas distributing smaller units of work among processors at runtime is called dynamic partitioning. GHC already provides the mechanism for dynamic partitioning; we just have to supply it with enough tasks by calling rpar often enough so that it can do its job and balance the work evenly. The argument to rpar is called a spark. The runtime collects sparks in a pool and uses this as a source of work when there are spare processors available, using a technique called work stealing. Sparks may be evaluated at some point in the future, or they might not—it all depends on whether there is a spare core available. Sparks are very cheap to create: rpar essentially just writes a pointer to the expression into an array. - https://www.oreilly.com/library/view/parallel-and-concurrent/9781449335939/ch02.html Parallel and Concurrent Programming in Haskell goes into a lot of detail about chunking strategies, and why you would or wouldn't try to limit the number of sparks. -Bryan From lemming at henning-thielemann.de Tue Jul 9 10:15:47 2019 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Tue, 9 Jul 2019 12:15:47 +0200 (CEST) Subject: [Haskell-cafe] parallel Haskell with limited sparks In-Reply-To: References: Message-ID: Thank you for the quote! I even skimmed over the book of Simon Marlow before asking, but missed that paragraph. :-( From theflossinformation at yandex.com Tue Jul 9 12:54:45 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Tue, 09 Jul 2019 15:54:45 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?4?= In-Reply-To: References: Message-ID: <4741562676885@mxfront9g.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From olf at aatal-apotheke.de Tue Jul 9 20:03:58 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 9 Jul 2019 22:03:58 +0200 Subject: [Haskell-cafe] mapM and Control.Arrow In-Reply-To: References: Message-ID: <2F938031-2BB4-4004-9511-F831B94B1C0B@aatal-apotheke.de> Cool, thanks for the pointer. But why is it that whenever something mildly categorical pops into my head, Edward Kmett has already published a package containing it? Olaf Am 09.07.2019 um 01:07 schrieb Zemyla : > > It needs to be an ArrowChoice, not just an Arrow, but it can be done. https://github.com/ekmett/profunctors/pull/40 > > On Mon, Jul 8, 2019, 15:37 Olaf Klinke wrote: > Dear cafe, > > consider the declaration > > mapM :: (SomeArrow a, Traversable t) => a b c -> a (t b) (t c) > > For the Arrow a = (->), the above mapM is just an over-constrained fmap, since Functor is a superclass of Traversable. For the arrow a = Kleisi m, the above mapM is the Control.Monad.mapM we know. Currently I fail to see how it could be defined with any of the existing sub-classes in Control.Arrow. > > One might say that fmap and mapM are on the same spectrum: If you specialize SomeArrow to (->) you can generalize Traversable to Functor, if you specialize Functor to Traversable you can generalize (->) to SomeArrow. > > Cheers, > Olaf > _______________________________________________ > 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 zemyla at gmail.com Tue Jul 9 22:16:19 2019 From: zemyla at gmail.com (Zemyla) Date: Tue, 9 Jul 2019 17:16:19 -0500 Subject: [Haskell-cafe] mapM and Control.Arrow In-Reply-To: <2F938031-2BB4-4004-9511-F831B94B1C0B@aatal-apotheke.de> References: <2F938031-2BB4-4004-9511-F831B94B1C0B@aatal-apotheke.de> Message-ID: Because that's what Edward Kmett does. If he didn't exist, the Haskell community would have had to invent him. On Tue, Jul 9, 2019, 15:04 Olaf Klinke wrote: > Cool, thanks for the pointer. But why is it that whenever something mildly > categorical pops into my head, Edward Kmett has already published a package > containing it? > > Olaf > > Am 09.07.2019 um 01:07 schrieb Zemyla : > > > > It needs to be an ArrowChoice, not just an Arrow, but it can be done. > https://github.com/ekmett/profunctors/pull/40 > > > > On Mon, Jul 8, 2019, 15:37 Olaf Klinke wrote: > > Dear cafe, > > > > consider the declaration > > > > mapM :: (SomeArrow a, Traversable t) => a b c -> a (t b) (t c) > > > > For the Arrow a = (->), the above mapM is just an over-constrained fmap, > since Functor is a superclass of Traversable. For the arrow a = Kleisi m, > the above mapM is the Control.Monad.mapM we know. Currently I fail to see > how it could be defined with any of the existing sub-classes in > Control.Arrow. > > > > One might say that fmap and mapM are on the same spectrum: If you > specialize SomeArrow to (->) you can generalize Traversable to Functor, if > you specialize Functor to Traversable you can generalize (->) to SomeArrow. > > > > Cheers, > > Olaf > > _______________________________________________ > > 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 mail at joachim-breitner.de Wed Jul 10 07:11:29 2019 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 10 Jul 2019 09:11:29 +0200 Subject: [Haskell-cafe] The GHC Committee welcomes its new members Message-ID: <5449e89bc59a881d9189d38cd19a98eb1b7cdcaa.camel@joachim-breitner.de> Dear Haskell community, the GHC Steering committee welcomes its new two members, Sandy Maguire and Arnaud Spiwack. We are happy to see that there is continued interest in our work, and are looking forward to the insights and energy that are brought to the committee by Sandy and Arnaud. They take the seats of Ben Gamari and Manuel Chakravarty. A big thanks to Ben and Manuel for their contributions to GHC and the proposal committee. In particular Ben, who created the initials draft of the proposal process. We had four nominations in total, and I would like to preserve their privacy. Since we only had two seats to fill, we had to make a pick; nevertheless I am grateful for all nominations, and encourage everyone, including those who did not make it this time, to try again next time. Neither the committee nor its process is perfect, as the way two recent proposals went show, but we are constantly trying to refine and improve. Your feedback is always welcome, either at the committee mailing list, or in private communication with the Chairs (the two Simons), me, or any other member. On behalf of the committee, Joachim Breitner PS: Sandy and Arnaud, please subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From theflossinformation at yandex.com Wed Jul 10 12:54:47 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Wed, 10 Jul 2019 15:54:47 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?5?= In-Reply-To: References: Message-ID: <54561562763287@mxfront13g.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From lanablack at amok.cc Wed Jul 10 15:43:30 2019 From: lanablack at amok.cc (Lana Black) Date: Wed, 10 Jul 2019 15:43:30 +0000 Subject: [Haskell-cafe] Hidden types and scope Message-ID: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> Hello cafe, While writing some code, I stumbled upon quite an interesting behavior. See the code example below. ------------------------------------------------------------- {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE RankNTypes #-} data Wrapper = forall m. Monad m => Wrapper { runAction :: forall a. m a -> IO a , someAction :: String -> m () } newtype MyIO a = MyIO { runIO :: IO a } deriving (Monad) ex :: Wrapper ex = Wrapper runIO (\s -> MyIO (putStrLn s)) {- This doesn't work -} --main :: IO () --main = do let Wrapper r a = ex -- r (a "Hello") {- This works -} main :: IO () main = case ex of Wrapper r a -> r (a "Hello") ------------------------------------------------------------- The idea is to hide the exact type `m` used in the wrapper, making the wrapper somewhat opaque to the user, while exposing some functionality and making sure that using `runAction` with the rest of the members of Wrapper is type-safe and `m` is always the same type within one instance of Wrapper. The problem that I ran into is that the first version of `main` doesn't compile with the following error: • Couldn't match expected type ‘p’ with actual type ‘forall a. m a -> IO a’ because type variable ‘m’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Wrapper :: forall (m :: * -> *). Monad m => (forall a. m a -> IO a) -> (String -> m ()) -> Wrapper, in a pattern binding at wildcards.hs:18:15-25 • In the pattern: Wrapper r a In a pattern binding: Wrapper r a = ex In the expression: do let Wrapper r a = ex r (a "Hello") This is repeated for every member of Wrapper that is matched in a let expression. However, if let expression is replaced with case, everything builds and works just fine. Is there a way to make it work with let expressions? That way the code is a lot cleaner, especially with RecordWildCards involved. From lanablack at amok.cc Wed Jul 10 15:56:49 2019 From: lanablack at amok.cc (Lana Black) Date: Wed, 10 Jul 2019 15:56:49 +0000 Subject: [Haskell-cafe] Hidden types and scope In-Reply-To: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> References: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> Message-ID: <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> A followup question. What is the reason case and let expressions are treated differently in this case? I can see the error message saying about the type variable escaping its scope, but I don't understand how exactly this can happen with let. From sandeep at sras.me Wed Jul 10 16:03:33 2019 From: sandeep at sras.me (Sandeep.C.R) Date: Wed, 10 Jul 2019 21:33:33 +0530 Subject: [Haskell-cafe] Hidden types and scope In-Reply-To: <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> References: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> Message-ID: >What is the reason case and let expressions are treated differently in this case Please check the section "7.4.5.4. Restrictions section" in https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/data-type-extensions.html It says, >In general, you can only pattern-match on an existentially-quantified constructor in a case expression or in the patterns of a function definition. The reason for this restriction is really an implementation one. Type-checking binding groups is already a nightmare without existentials complicating the picture. Also an existential pattern binding at the top level of a module doesn't make sense, because it's not clear how to prevent the existentially-quantified type "escaping". So for now, there's a simple-to-state restriction. We'll see how annoying it is. On 10/07/19 9:26 PM, Lana Black wrote: > A followup question. What is the reason case and let expressions are > treated differently in this case? I can see the error message saying > about the type variable escaping its scope, but I don't understand how > exactly this can happen with let. > _______________________________________________ > 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 allbery.b at gmail.com Wed Jul 10 16:04:22 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 10 Jul 2019 12:04:22 -0400 Subject: [Haskell-cafe] Hidden types and scope In-Reply-To: <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> References: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> Message-ID: You may need to study skolems / rank-N types. The exact scope of the "IO" is inside the Wrapper, and nowhere else; so using it in let at all allows it to be visible outside its scope. With the case expression, it can be visible anywhere in the case alternative that pattern matches the Wrapper without it necessarily escaping the scope (you could explicitly leak it, but it will raise the same error about it escaping in that case). GADTs are a way to get this same case matchung behavior, but it still doesn't help you with this; you are asking that the compiler ignore the rank of the type variable and make it visible outside its scope so that you can use let instead of case, and ghc will not let you do this. On Wed, Jul 10, 2019 at 11:57 AM Lana Black wrote: > A followup question. What is the reason case and let expressions are > treated differently in this case? I can see the error message saying > about the type variable escaping its scope, but I don't understand how > exactly this can happen with let. > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanablack at amok.cc Wed Jul 10 16:10:35 2019 From: lanablack at amok.cc (Lana Black) Date: Wed, 10 Jul 2019 16:10:35 +0000 Subject: [Haskell-cafe] Hidden types and scope In-Reply-To: References: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> Message-ID: <61f410c4-8a95-7b98-72ce-0a6c0acf8bdd@amok.cc> On 10/07/2019 16:03, Sandeep.C.R via Haskell-Cafe wrote: > >What is the reason case and let expressions are treated differently in > this case > > Please check the section "7.4.5.4. Restrictions section" in > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/data-type-extensions.html > > > It says, > > >In general, you can only pattern-match on an existentially-quantified > constructor in a case expression or in the patterns of a function > definition. The reason for this restriction is really an implementation > one. Type-checking binding groups is already a nightmare without > existentials complicating the picture. Also an existential pattern > binding at the top level of a module doesn't make sense, because it's > not clear how to prevent the existentially-quantified type "escaping". > So for now, there's a simple-to-state restriction. We'll see how > annoying it is. Thank you! That explains it. From bcj at alasconnect.com Wed Jul 10 19:55:26 2019 From: bcj at alasconnect.com (Brian C. Jones) Date: Wed, 10 Jul 2019 19:55:26 +0000 Subject: [Haskell-cafe] [ldap-client] Project takeover initiation Message-ID: Hello, I have attempted to contact the author via PR and direct email with no response in 3 weeks. This is my final attempt before engaging the Hackage admins. https://github.com/supki/ldap-client/pull/16 Brian Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From theflossinformation at yandex.com Thu Jul 11 12:54:49 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Thu, 11 Jul 2019 15:54:49 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?6?= In-Reply-To: References: Message-ID: <102441562849689@mxfront6j.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From ben.franksen at online.de Thu Jul 11 15:11:09 2019 From: ben.franksen at online.de (Benjamin Franksen) Date: Thu, 11 Jul 2019 17:11:09 +0200 Subject: [Haskell-cafe] Hidden types and scope In-Reply-To: References: <297e3e19-fcaf-db7c-0615-371ee9df7162@amok.cc> <5864eb11-c587-2049-8252-91bdbd8f18fb@amok.cc> Message-ID: Am 10.07.19 um 18:03 schrieb Sandeep.C.R via Haskell-Cafe: >>What is the reason case and let expressions are treated differently in > this case > > Please check the section "7.4.5.4. Restrictions section" in > https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/data-type-extensions.html > > > It says, > >>In general, you can only pattern-match on an existentially-quantified > constructor in a case expression or in the patterns of a function > definition. The reason for this restriction is really an implementation > one. Type-checking binding groups is already a nightmare without > existentials complicating the picture. Also an existential pattern > binding at the top level of a module doesn't make sense, because it's > not clear how to prevent the existentially-quantified type "escaping". > So for now, there's a simple-to-state restriction. We'll see how > annoying it is. FWIW, I personally do find the restriction pretty annoying (even though by now I am quite used to it). In some cases one can work around it by using pattern guards instead of let/where, since these are also exempt. Cheers Ben From juan.casanova at ed.ac.uk Thu Jul 11 19:24:50 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Thu, 11 Jul 2019 20:24:50 +0100 Subject: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads Message-ID: <20190711202450.13904f7hon3o2f40@www.staffmail.ed.ac.uk> Dear all, I just subscribed to this list so I'm not familiar with the usual way to go about things here. I hope you'll excuse any cultural mistakes I might make. I'll also try to keep this message as short as possible, but this is hard for me and it is a complex topic, so I will presumably fail. Apologies for that in advance. Short introduction. I'm a PhD student at University of Edinburgh. My research is not on programming languages itself, but during the course of it I ended up programming in Haskell and more particularly faced a problem that I developed a strategy (and eventually a library) for. After some discussions with my supervisors and with some more Haskell experienced people around university, they suggested that I looked into some existing work and also that I posted on this list, and here I am. Let me introduce the problem that I'm trying to solve itself. I have a particular (yet somehow typical) case of non-determinism (search) in the program that I have been writing. It is characterized by: - No joining back of branches ever. - Potentially infinite depth (this is usual). - Potentially infinite width. Meaning that at a single point I may have an infinite amount of possible paths to follow. - It is critical that the search is complete. After reading a bit, I have realized this is usually referred to as being a fair search order. For me this means that there can be many (infinite) valid solutions in the search space, and I want to find all of them (i.e. for every valid solution, the program will eventually output it). As I said, I developed my own (particular) approach to this, then generalized it in a library, and then, after talking to some people, realized this might be something quite interesting to share, but first had to check that it's not something that has already been done. Long story short, the most relevant piece of research I was pointed to was "Backtracking, interleaving and terminating monad transformers", by O Kiselyov, C Shan, DP Friedman and A Sabry, published in 2005. (https://dl.acm.org/citation.cfm?id=1086390). I also know that this approach is embodied in Haskell through the Control.Monad.Logic library. I read the paper and skimmed through some related work, and gave a try to the library. Indeed, it seems to be doing mostly what I need. In particular, it can deal with infinite breadth/infinite width searches through a process of what I call "diagonalization". That is, a combination of breadth-first and depth-first that ensures fairness. Note that the library actually does a lot more things that I didn't consider because they were not relevant for my problem, for instance cuts. However, I find that there is something that this library does not take into account, and after trying with the Haskell library I have verified that indeed it does not work, whereas my library does work. I am wondering if I have overlooked some work in which this is also taken into account or if I may be onto some useful extension of Control.Monad.Logic that hasn't been done yet. I still have to find a stable name for the feature that I am talking about, but I usually refer to it as "step-wise termination" or "quantization of computations". To understand it consider an example (that I have actually implemented): 1. Whenever I have a non-deterministic enumeration, I should have a way to output a fair search among that non-deterministic search (a list), following the properties that I indicated above. 2. I can make an enumeration that non-deterministically produces all multiples of a certain number. 3. I can make an enumeration that non-deterministically produces all powers of a certain number. 4. I can make a function that, given an enumeration, filters it through a boolean function. 5. I can monadically combine computations, so that I can, for instance, produce a computation that is the result of producing all multiples of a number, and for each of those, producing all their powers. 6. So what happens if I combine the three of them. In particular, what if I output all *odd* powers of all multiples of 1 (all naturals)? (multiples 1) >>= (\x -> filter odd (powers x))? If I do this using the Control.Monad.Logic library (and using the >>- operator provided there, of course), this does not produce a fair search. Specifically, it outputs 1 and then hangs up. The reason? The order in which the search is produced picks one value from each sublist at a time, but because there are no odd powers of an even number (say 2), it never finds any element in the sublist of powers of 2, and therefore never gets to even try with the powers of 3. My library can deal with this by "quantizing" computation, making sure that each individual step of a computation always terminates (in Haskell terms, I wrap things up in a way that I can guarantee that a single look-ahead on the list will always produce a head normal form in finite time, even if that is still a continuation of the computation). Therefore, while it keeps trying to find powers of 2 that are odd, this does not stop the search over all the other sublists. This mail is already quite long, but let me make a few precisions. You may stop reading here if you don't wanna get your hands dirty, I've said the most important bits. I know a bit of what I say here will be confusing if you don't think about it yourself, so skip it if it gets confusing. It's mainly to answer some questions/comments I can foresee. Of course, this only works if the embedding into the monad is terminating itself. So, when you do "pure x" for my monad, you need to guarantee that "x" will produce a head normal form in finite time). But as long as you guarantee this atomic notion and you only use the monadic transformation functions that are not labelled as "unsafe" (which are only the unnatural ones for the semantics that I am considering, such as appending in a list sense), then I can guarantee the search will always be fair. Also, a thing I've been thinking quite a bit is whether you can consider this notion of "quantization" of computation separately from the notion of an enumeration of a non-deterministic search space. Of course you can, but the interesting bit is to do this diagonalization over non-deterministic search spaces in a quantized way so that rabbit holes like the odd powers of 2 are not a problem. I tried to implement this in a generic way that you can later on "combine" with Control.Monad.Logic in a non-specific way, but it won't work, due to the particular reason that you'd need to do pattern matching over the structure of the logic monad, and there's no way to type check that for an arbitrary data type (because the pattern matching could give literally any potential sub-types). Implementing the quantization separately and then the combination individually as a one-of thing could be done, of course, but it would essentially be the same that I have right now. A different story would be had if ghci actually had monadic functions to enable the evaluation of *any* thunk one-step-at-a-time (that is, one function evaluation or one pattern match). This is absolutely not what seq does, because seq evaluates until it is a weak head normal form, which is not what I want. Precisely, bottom seq a = bottom, and my quantized computation does not fulfill this equation (and it should not). My library is not perfect now, and after having read and understood the Control.Monad.Logic library, I think the best thing would be to extend it, which is something I don't do right now. But still so, unless I have missed an already existing implementation of something like this, or I am seeing something in a really convoluted way. Please feel free to drop any questions or comments at all. I'm attaching an example of why Control.Monad.Logic does not work in the case that I said. It also includes an example using my library, which I am not attaching. This example works. Just comment it. I'm not attaching my library now because it's not "polished" and because it is a lot for people to randomly look at, but feel free to ask for it and I'll happily send it over, so that you can run the example with it. Again, any questions or comments are welcome. Lead me the right direction with this. ... And sorry for the wall of text. Thank you very much for all of your time and attention, Juan Casanova. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: LogicVsEnumProc.hs Type: text/x-haskell Size: 2065 bytes Desc: not available URL: From lysxia at gmail.com Fri Jul 12 01:21:51 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Thu, 11 Jul 2019 21:21:51 -0400 Subject: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads In-Reply-To: <20190711202450.13904f7hon3o2f40@www.staffmail.ed.ac.uk> References: <20190711202450.13904f7hon3o2f40@www.staffmail.ed.ac.uk> Message-ID: Hello Juan, On 7/11/19 3:24 PM, Juan Casanova wrote: > I just subscribed to this list so I'm not familiar with the usual way to > go about things here. I hope you'll excuse any cultural mistakes I might > make. You're most definitely welcome here. I dare say that anyone who participates in the mailing list makes the rules (within the limits of moderation of course). > feel free to ask for it and I'll happily > send it over, so that you can run the example with it. I am curious to have a look at your library. > Let me introduce the problem that I'm trying to solve itself. I have a > particular (yet somehow typical) case of non-determinism (search) in the > program that I have been writing. It is characterized by: > > - No joining back of branches ever. > - Potentially infinite depth (this is usual). > - Potentially infinite width. Meaning that at a single point I may have > an infinite amount of possible paths to follow. > - It is critical that the search is complete. After reading a bit, I > have realized this is usually referred to as being a fair search order. > For me this means that there can be many (infinite) valid solutions in > the search space, and I want to find all of them (i.e. for every valid > solution, the program will eventually output it). > I think all of these points can be addressed by starting from an infinite binary tree. data Tree a = Empty | Leaf a | Branch (Leaf a) (Leaf a) instance Monad Tree where ... In particular: - infinite branching can be modeled by an infinite sequence of finite branches: Branch 1 (Branch 2 (Branch 3 (...))); - the problem of completeness is addressed by, uh, postponing it. Okay that's not really addressed, but the point is that the data is all there at least (not lost in a diverging computation), and the search problem is now a very concrete tree traversal problem, which does not require any fancy monadic abstraction a priori, but also does not prevent you from building one up as other requirements make themselves known. Regarding the issue of fairness you mention, a key point is that "filter" should only replace Leaf with Empty, and not try to do any merging like rewriting (Branch Empty t) to t. More precisely, as soon as a function satisfies the equation f (Branch Empty t) = f t, then it has to diverge on trees with no leaves (or it has to discard leaves, so it's useless if completeness is a concern). I'm guessing that's where the logic monad goes astray. One way to think of this problem is in terms of "productivity": "filter" for Logic may not be productive if its argument represents an infinite search space. In total programming languages, i.e., those which enforce productivity, Agda and Coq being chief examples, you would actually be stopped because the Logic monad cannot represent infinite search spaces (such as log_multiples in your sample). Coinductive types are a promising alternative here, with two main solutions off the top of my head being coinductive trees, as I sketched above, and coinductive lists/streams with an extra "delay" constructor. I am curious to see how your library relates to that. Cheers, Li-yao From juan.casanova at ed.ac.uk Fri Jul 12 02:56:46 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Fri, 12 Jul 2019 03:56:46 +0100 Subject: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads In-Reply-To: References: <20190711202450.13904f7hon3o2f40@www.staffmail.ed.ac.uk> Message-ID: <20190712035646.12311upwg7gvta00@www.staffmail.ed.ac.uk> Thank you for your very detailed and very relevant response. It made me think about some things. > I am curious to have a look at your library. I guess I'll just attach it here and end up sharing it with the whole list. Just hope noone feels overwhelmed by too much code to look at. > I think all of these points can be addressed by starting from an > infinite binary tree. > > > data Tree a = Empty | Leaf a | Branch (Leaf a) (Leaf a) > > instance Monad Tree where ... > > > In particular: > > - infinite branching can be modeled by an infinite sequence of > finite branches: Branch 1 (Branch 2 (Branch 3 (...))); This is correct, but not complete in general, although the logic monad library does deal with this. The problem is, if you have a conceptual infinite branching, in which each branch is infinite in depth, the process of expressing the infinite branching as an infinite sequence of finite branching will, if done naively, be unfair towards later branches. So, if I want to search all the multiples of all powers of 2, the "naive" transformation will "concatenate" all those lists / branches, but because the first one is infinite, any search performed in that way will not reach the latter ones. In other words, things that were at depth 2 before will now be at depth infinity because you have prepended them with an infinite amount of finite branches. This can be overcome by doing the transformation from infinite branching to binary/finite branching diagonally, as I described and as the logic monad library does. So, yeah, it can be modelled that way, but the process of translation is very relevant for fairness. > - the problem of completeness is addressed by, uh, postponing it. > Okay that's not really addressed, but the point is that the data is > all there at least (not lost in a diverging computation), and the > search problem is now a very concrete tree traversal problem, which > does not require any fancy monadic abstraction a priori, but also > does not prevent you from building one up as other requirements make > themselves known. > > > Regarding the issue of fairness you mention, a key point is that > "filter" should only replace Leaf with Empty, and not try to do any > merging like rewriting (Branch Empty t) to t. More precisely, as > soon as a function satisfies the equation > > f (Branch Empty t) = f t, > > then it has to diverge on trees with no leaves (or it has to discard > leaves, so it's useless if completeness is a concern). I'm guessing > that's where the logic monad goes astray. This is a very good point, one that I had not thought of. In some sense, the problem is precisely that, that the logic monad library does not represent the computation itself (neither as a tree or as a list), but instead only the results, and therefore a filter must satisfy that equation, and therefore it will diverge. > > One way to think of this problem is in terms of "productivity": > "filter" for Logic may not be productive if its argument represents > an infinite search space. In total programming languages, i.e., > those which enforce productivity, Agda and Coq being chief examples, > you would actually be stopped because the Logic monad cannot > represent infinite search spaces (such as log_multiples in your > sample). > > Coinductive types are a promising alternative here, with two main > solutions off the top of my head being coinductive trees, as I > sketched above, and coinductive lists/streams with an extra "delay" > constructor. I am curious to see how your library relates to that. Indeed, my library relies essentially on lists/streams with an extra "delay" constructor. I must say the word "coinductive" got me a bit puzzled there, but after looking it up a bit, I think I understand what you mean. I definitely know what inductive means, I just did not know there was such a concept as coinduction. You can see the library in the attachment, but the definition of my data structure is (I differentiate Empty from Halt but that is pretty inconsequential, it just alters how I deal with joining several infinites. In a sense it's a type of cut. I also wrap errors within it, which may be bad practice.): data EnumProc t = Empty | Halt | Error String | Produce t (EnumProc t) | Continue (EnumProc t) where the Continue constructor is the extra "delay" one. Whenever a function that works on this structure needs to do a recursive call (or mutually recursive call, etc.), instead of just doing the recursive call, I prepend it with "Continue", so that I can ensure that it will be in head normal form, and therefore I can perform the computation one step at a time. Now, I see how you feel that Trees are a more natural way to describe the computation than infinite lists with delay, but I'm not sure if there are any actual advantages to using that approach instead of mine. In other words, I think what you are suggesting is essentially what I did, and what you are saying are perhaps better argumented reasons as to why you need to do it. What I wonder is if there is indeed a way to do these kind of things with the logic monad library (and perhaps other standard libraries) without having to implement my own? Thanks again, Juan -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -------------- next part -------------- A non-text attachment was scrubbed... Name: EnumProc.hs Type: text/x-java Size: 40671 bytes Desc: not available URL: From lysxia at gmail.com Fri Jul 12 04:59:41 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Fri, 12 Jul 2019 00:59:41 -0400 Subject: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads In-Reply-To: <20190712035646.12311upwg7gvta00@www.staffmail.ed.ac.uk> References: <20190711202450.13904f7hon3o2f40@www.staffmail.ed.ac.uk> <20190712035646.12311upwg7gvta00@www.staffmail.ed.ac.uk> Message-ID: <67ae110f-7259-0236-d68f-0ff747348707@gmail.com> On 7/11/19 10:56 PM, Juan Casanova wrote: > Thank you for your very detailed and very relevant response. It made me > think about some things. I'm glad you appreciated my answer! >> I am curious to have a look at your library. > > I guess I'll just attach it here and end up sharing it with the whole > list. Just hope noone feels overwhelmed by too much code to look at. That looks quite reasonable. At a high level, one can imagine this basically as a list library, so most functions look quite familiar at a glance. >> - infinite branching can be modeled by an infinite sequence of finite >> branches: Branch 1 (Branch 2 (Branch 3 (...))); > > This is correct, but not complete in general, although the logic monad > library does deal with this. The problem is, if you have a conceptual > infinite branching, in which each branch is infinite in depth, the > process of expressing the infinite branching as an infinite sequence of > finite branching will, if done naively, be unfair towards later > branches. So, if I want to search all the multiples of all powers of 2, > the "naive" transformation will "concatenate" all those lists / > branches, but because the first one is infinite, any search performed in > that way will not reach the latter ones. In other words, things that > were at depth 2 before will now be at depth infinity because you have > prepended them with an infinite amount of finite branches. This can be > overcome by doing the transformation from infinite branching to > binary/finite branching diagonally, as I described and as the logic > monad library does. For "all the multiples of all powers of 2", the tree obtained naively by monadic composition will look like this: mulPow2 = liftA2 (*) nats pow2s -- Branch (... multiples of 2^0) (Branch (... multiples of 2^1) (Branch (... multiples of 2^2) (...))) -- where nats contains all natural numbers and pow2s all powers of 2. No elements are lost precisely thanks to the tree structure allowing you to nest subtrees without pushing others back. That said, your approach is certainly still worth pursuing. > What I wonder is if there is indeed a way to do > these kind of things with the logic monad library (and perhaps other > standard libraries) without having to implement my own? The problem you described appears to be deeply embedded in the definition of LogicT. A handwavy argument is that Logic is exactly the Church encoding of lists with Nil and Cons (Empty and Produce), but you really need the Continue constructor in there. One idea to try is "Logic (Maybe a)", since it is isomorphic to [Maybe a] which is isomorphic to the Empty+Produce+Continue variant of lists (using the names from your code). But although the representation is equivalent, I'm not sure the abstractions are reusable enough to save much work. Cheers, Li-yao From theflossinformation at yandex.com Fri Jul 12 12:54:52 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Fri, 12 Jul 2019 15:54:52 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?7?= In-Reply-To: References: Message-ID: <152381562936092@mxfront6g.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From a.pelenitsyn at gmail.com Fri Jul 12 15:51:20 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Fri, 12 Jul 2019 18:51:20 +0300 Subject: [Haskell-cafe] =?utf-8?q?Fwd=3A_CFP=3A_4th_Workshop_on_Meta-Progr?= =?utf-8?q?amming_Techniques_and_Reflection_=28Meta=E2=80=9919=29?= =?utf-8?q?=2C_Co-located_with_SPLASH_2019?= In-Reply-To: References: Message-ID: ---------- Forwarded message --------- De: Guido Chari Date: vie., 12 jul. 2019 a las 12:22 Subject: CFP: 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19), Co-located with SPLASH 2019 To: ======================================================================== Call for Papers 4th Workshop on Meta-Programming Techniques and Reflection (Meta’19) Co-located with SPLASH 2019 October 20, 2019, Athens, Greece https://2019.splashcon.org/track/meta-2019 Follow us on twitter @MetaAtSPLASH ======================================================================== The Meta’19 workshop aims to bring together researchers working on metaprogramming and reflection, as well as users building applications, language extensions and/or software tools using them. The challenges which metaprogramming faces are manifold. They start with formal reasoning about reflective programs, continue with performance and tooling, and reach into the empirical field to understand how metaprogramming is used and how it affects software maintainability. While industry accepted metaprogramming on a wide scale with Ruby, Scala, JavaScript, R and others, there is still a long road ahead to bring the same level of convenience, tooling, and understanding as for direct programming styles. Contributions to the workshop are welcome on a wide range of topics related to the design, implementation, and application of metaprogramming techniques, as well as empirical studies and formal methods for such systems and languages. ### Topics of Interest The workshop is a venue for all approaches that embrace metaprogramming, from static to dynamic techniques: - reflection, meta-level architectures, staging, open language runtimes applications to middleware, frameworks, and DSLs - optimization techniques - contract systems, or typing of reflective programs - reflection and metaobject protocols to enable tooling - case studies and evaluation of such techniques, e.g., to build applications, language extensions, or tools - empirical evaluation of metaprogramming solutions - security in reflective systems and capability-based designs - meta-level architectures and reflective middleware for modern runtime platforms (e.g. IoT, cyber-physical systems, mobile/cloud/grid computing, etc) - surveys, conceptualization, taxonomization, and formalization of existing approaches ### Workshop Format and Submissions This workshop welcomes the presentation of new ideas and emerging problems as well as mature work as part of a mini-conference format. Furthermore, we plan interactive brainstorming and demonstration sessions between the formal presentations to enable an active exchange of ideas. Papers submitted by the first deadline will be considered for publication in the ACM DL, if not requested otherwise by the authors. Thus, they will be part of SPLASH workshop proceedings. For all papers, use of the SIGPLAN acmart style is mandatory: http://www.sigplan.org/Resources/Author/. Please use the provided double-column templates for Latex or Word. technical paper: max. 8 pages, excluding references position and work-in-progress paper: 1-4 pages, excluding references technology demos or a posters: 1-page abstract Demos, posters, position and work-in-progress papers can be submitted on a second, later deadline to discuss the latest results and current work, but will not be considered for publication in the ACM DL. For the submission, please use the submission system at: https://meta19.hotcrp.com/ ### Important Dates (TODO) 26 Jul 2019 - Abstract Submission 2 Aug 2019 - Paper Submission (considered for ACM DL) 23 Aug 2019 - Notification 28 Aug 2019 - Demo, position or work-in-progress paper submission 20 Sep 2019 - Demo, position or work-in-progress paper notification ### Steering Committee Elisa Gonzalez Boix, Vrije Universiteit Brussel Stefan Marr, University of Kent ### Organizing Committee Guido Chari, Czech Technical University Christophe Scholliers, Ghent University ### Program Committee Nada Amin, University of Cambridge, UK Edwin Brady, University of St Andrews, UK Andrei Chis, Feenk, Switzerland David Thrane Christiansen, Galois, Portland, Oregon, USA Tom Van Cutsem, Bell Labs, Belgium Ryan Culpepper, Czech Technical University, Prague, Czechia Jennifer Hacket, University of Nottingham, UK Robert Hirschfield, Hasso Plattner Institute, Germany James Noble, Victoria University Wellington, New Zealand Bruno C. d. S. Oliveira, The University of Hong Kong Cyrus Omar, University of Chicago, USA Guillermo Polito, Inria Lille, France Eric Tanter, Universidad de Chile, Chile ### Contact Information For further inquiries, do not hesitate to contact the organizers via meta-at-splash19 AT googlegroups.com http://2019.splashcon.org/track/meta-2019 -- You received this message because you are subscribed to the Google Groups "PRL-jv" group. To unsubscribe from this group and stop receiving emails from it, send an email to PRL-jv+unsubscribe at googlegroups.com. To post to this group, send email to PRL-jv at googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/PRL-jv/CAO4Coc-WQ21XZQNPLCiXCE2ZTXoPYT4i7SnjRmtpBjgiSkyjiQ%40mail.gmail.com . For more options, visit https://groups.google.com/d/optout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Fri Jul 12 15:52:07 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Fri, 12 Jul 2019 11:52:07 -0400 Subject: [Haskell-cafe] Haskell Symposium: early reg deadline is next week In-Reply-To: <60E88B25-BB24-4731-9417-A611CBEF75AE@cs.brynmawr.edu> References: <60E88B25-BB24-4731-9417-A611CBEF75AE@cs.brynmawr.edu> Message-ID: The early registration deadline is **18 July**. That's next week! Accepted papers are at https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview We will have two keynotes: • Mary Sheeran, of Chalmers University, will present Gender Equality in Academia: Meeting the Challenge on Thursday, 22 August. • Lennart Augustsson and Satnam Singh, both of Google Research, will co-present Haskell Use and Abuse at Scale on Friday, 23 August. Come join! Symposium details are below. I hope to see you there! Richard ================================================================================ ACM SIGPLAN CALL FOR PARTICIPATION Haskell Symposium 2019 Berlin, Germany 22--23 August, 2019 https://icfp19.sigplan.org/home/haskellsymp-2019 ================================================================================ The ACM SIGPLAN Haskell Symposium 2019 will be co-located with the 2019 International Conference on Functional Programming (ICFP). The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * System Demonstrations, based on running software rather than novel research results. From callan.mcgill at gmail.com Fri Jul 12 18:44:57 2019 From: callan.mcgill at gmail.com (Callan McGill) Date: Fri, 12 Jul 2019 14:44:57 -0400 Subject: [Haskell-cafe] Huffman Library Maintainership Message-ID: The huffman library (http://hackage.haskell.org/package/huffman) is very useful, but unfortunately hasn't been maintained in several years and does not compile with new versions of the containers library. We are incorporating huffman encoding as part of the American Museum of Natural History's PCG project (https://github.com/amnh/pcg). We have a locally "repaired" version of the huffman library that we have used in a prototype and would like to share the updates with the Haskell community. Nine months ago I contacted Maxime Henrion, the listed maintainer of the huffman library, about a pull request to incorporate the changes or taking up maintainership responsibility, whatever they would prefer to update the library and share the huffman encoding library updates with the rest of the community. Unfortunately I didn't receive any response from them. Per the listed protocol for requesting maintainership of a hackage package if the current maintainer cannot be reached ( https://wiki.haskell.org/Taking_over_a_package#If_you_cannot_contact_the_author.2Fmaintainer), I'm letting the Haskell community know that I am quite interested in taking over maintainership of the huffman library. I intend to update the library to compile with new versions of GHC and updated versions of the containers package. ~Alex Washburn, (recursion-ninja) -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Fri Jul 12 19:47:01 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 12 Jul 2019 21:47:01 +0200 Subject: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads Message-ID: Dear Juan, Is the following problem of the class you are considering? Given a predicate p :: (Integer -> Integer) -> Bool enumerate all functions f :: Integer -> Integer for which p f == True. The search space (Integer -> Integer) can be rendered into a tree of infinite width and depth: On the first level, branch on the value of f(0), on the next level branch on the value of f(1) and so forth. If the above problem were tractable, then you'd have an enumeration of the real numbers. If the target is to find whether there is at least one such f, then you have proven compactness of Baire space. So there must be something about your problem that remained unclear to me. Care to explain? Regards, Olaf P.S.: Infinite branching trees could be modeled as data Tree a = Tree (Integer -> Maybe (a,Tree a)) Maybe this can help bringing your algorithms closer to the literature on computable functions and recursion theory. From juan.casanova at ed.ac.uk Fri Jul 12 21:32:12 2019 From: juan.casanova at ed.ac.uk (Juan Casanova) Date: Fri, 12 Jul 2019 22:32:12 +0100 Subject: [Haskell-cafe] "Quantization" of computations, or step-wise termination, as an extension of Logic Monads In-Reply-To: References: Message-ID: <20190712223212.28123bpysgp3282s@www.staffmail.ed.ac.uk> Thanks Olaf for a very good question. You made me scared for a minute. I think the subtlety is that in order for us to evaluate the predicate p on the function, we'd have to reach the "end" of the enumeration (to have a fully defined function). In other words, the search space of the functions (Integer -> Integer) is not the search space of the intermediate nodes of the tree, but of the leaves, which are unreachable by any algorithm of course. The intermediate nodes of the tree would be the space of functions defined on a finite (yet unbounded) subset of the integers, which is countable. My search can of course only possibly stop at nodes it reaches, be it either intermediate nodes or leaves because they are actually reachable (not in this case). So I don't think I am claiming to break any cardinality constraint. Maybe to put it more in context, and going back to my original example of finding odd powers of natural numbers, I am looking for odd powers of natural numbers, *not* for natural numbers such that all their powers are odd (which would be the computational equivalent of finding functions that satisfies p). Of course you can solve this problem easily because of the semantics, but not through sheer search as we are considering here. I hope that explanation is clear and also it makes sense to you? Thanks again for the observation, though. Juan Casanova. PS: I'll take the representation style you mentioned into account. In general, the way I consider infinite branching is relatively similar, except I don't commit to particular types like Integer. Maybe it is worth mentioning that, of course, the way in which the infinite branching takes place is always computable as a function of the current node, so the way I represent the branching is simply as a function: a -> EnumProc b, where a is the type of the current node and b the type of the subsequent nodes. For my application, these are usually proof states in a resolution proof, but I have not explained anything about my particular application at all so far. Quoting Olaf Klinke on Fri, 12 Jul 2019 21:47:01 +0200: > Dear Juan, > > Is the following problem of the class you are considering? > Given a predicate > p :: (Integer -> Integer) -> Bool > enumerate all functions f :: Integer -> Integer for which p f == True. > > The search space (Integer -> Integer) can be rendered into a tree of > infinite width and depth: On the first level, branch on the value of > f(0), on the next level branch on the value of f(1) and so forth. > > If the above problem were tractable, then you'd have an enumeration > of the real numbers. If the target is to find whether there is at > least one such f, then you have proven compactness of Baire space. > So there must be something about your problem that remained unclear > to me. Care to explain? > > Regards, > Olaf > > P.S.: Infinite branching trees could be modeled as > data Tree a = Tree (Integer -> Maybe (a,Tree a)) > Maybe this can help bringing your algorithms closer to the > literature on computable functions and recursion theory. > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. From brucker at spamfence.net Sun Jul 14 10:08:14 2019 From: brucker at spamfence.net (Achim D. Brucker) Date: Sun, 14 Jul 2019 11:08:14 +0100 Subject: [Haskell-cafe] Workshop in OCL and Textual Modeling (OCL 2019) - Deadline Extension Message-ID: <20190714100814.edlxkoe3slusfaxz@ananogawa.home.brucker.ch> CALL FOR PAPERS 19th International Workshop on OCL and Textual Modeling Co-located with MODELS 2019 ACM/IEEE 22nd International Conference on Model Driven Engineering Languages and System, September 15-20, 2019, Munich, Germany http://oclworkshop.github.io ******************************************************************* **** Deadline Extension: One week (21st of July, 2019 - AoE) **** **** left to submit your papers! **** ******************************************************************* The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages (e.g., OCL, textual MOF, Epsilon, or Alloy) can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Submissions Four types of submissions will be considered: * Presentation only submission (not included in the workshop proceedings), e.g., for already published work. Authors should submit a short (1 page) abstract of their presentation. * Short papers (between 5 and 7 pages) describing new ideas or position papers. * Tool papers (between 5 and 7 pages) describing tools supporting textual modeling tools * Full papers (between 10 and 14 pages). All submissions should follow the LNCS format guidelines and should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2019). Accepted papers will be published online in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: 21 Jul 2019, AoE (extended) - Notification: 25 Aug 2019, AoE - Pre-Workshop CRC: 9 Sep 2019, AoE - Post-Workshop CRC: 5 Oct 2019, AoE -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking From manny at fpcomplete.com Sun Jul 14 16:56:33 2019 From: manny at fpcomplete.com (Emanuel Borsboom) Date: Sun, 14 Jul 2019 09:56:33 -0700 Subject: [Haskell-cafe] ANN: stack-2.1.3 Message-ID: See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.1.1** Behavior changes: * Disable WAL mode for SQLite3 databases, to improve compatibility with some platforms and filesystems. See [#4876](https://github.com/commercialhaskell/stack/issues/4876). * By default, do not perform expiry checks in Hackage Security. See [#4928](https://github.com/commercialhaskell/stack/issues/4928). Other enhancements: * Do not rerun expected test failures. This is mostly a change that will only affect the Stackage Curator use case, but there is now an additional message letting the user know when a previously-failed test case is being rerun. * Move configure information for local packages back to .stack-work to improve caching. See [#4893](https://github.com/commercialhaskell/stack/issues/4893). Bug fixes: * Fix to allow dependencies on specific versions of local git repositories. See [#4862](https://github.com/commercialhaskell/stack/pull/4862) * Allow Stack commands to be run in Nix mode without having a project file available. See [#4854](https://github.com/commercialhaskell/stack/issues/4864). * Removes dependency on gnu-tar for OSX and Linux environment. The `--force-local` option was required only for windows environment. * Properly wait for the `tar` subprocess to complete before returning, thereby avoiding a SIGTERM screwing up GHC installation. See [#4888](https://github.com/commercialhaskell/stack/issues/4888). * Use package complete locations from lock files when resolving dependencies in `extra-deps`. See [#4887](https://github.com/commercialhaskell/stack/issues/4887). * Set the `HASKELL_DIST_DIR` environment to a proper package dist directory so `doctest` is able to load modules autogenerated by Cabal. * Expose package library when running tests. * Fix support for non-ASCII module names. See [4938](https://github.com/commercialhaskell/stack/issues/4938) Other changes: * Rename `pantry-tmp` package back to `pantry`, now that we have gained maintainership (which had been used by someone else for a candidate-only test that made it look like the name was free but prevented uploading a real package). **Thanks to all our contributors for this release:** * Alan Malloy * Alexander * Emanuel Borsboom * Kirill Zaborsky * Matt Audesse * Michael Snoyman * Mihai Maruseac * Sibi Prabakaran From johannes.waldmann at htwk-leipzig.de Mon Jul 15 17:12:21 2019 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Mon, 15 Jul 2019 19:12:21 +0200 Subject: [Haskell-cafe] Haskell Symposium: early reg deadline is next week Message-ID: <2403f89f-1cad-6c03-f5fc-255358eba012@htwk-leipzig.de> https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview list of accepted papers is invisible, navigation not usable, unless you allow third-party trackers (ajax.googleapis.com) - J.W. From cdsmith at gmail.com Mon Jul 15 17:50:34 2019 From: cdsmith at gmail.com (Chris Smith) Date: Mon, 15 Jul 2019 13:50:34 -0400 Subject: [Haskell-cafe] ANN: New York Haskell CoHack, August 3 Message-ID: If you're not in New York, feel free to stop reading. Any Haskellers in the New York area, you're invited to the monthly CoHack on August 3rd, at the Microsoft Reactor space near Times Square. This is an informal collaboration between Haskellers working on a variety of projects. There's usually a good mix of everything from new Haskell programmers to seasoned veterans We'll have food and internet and hopefully collaborators, whether it's a long-standing project or a one-off weekend hack. Details at https://www.meetup.com/NY-Haskell/events/261277328/ I hope to see you there. There will also be lightning talks at the event, if you have anything you'd like to share. Signups will be same-day, and lightning talks are 10 minutes long, including setup and questions. Thanks, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From monnier at iro.umontreal.ca Mon Jul 15 18:53:42 2019 From: monnier at iro.umontreal.ca (Stefan Monnier) Date: Mon, 15 Jul 2019 14:53:42 -0400 Subject: [Haskell-cafe] Haskell Symposium: early reg deadline is next week References: <2403f89f-1cad-6c03-f5fc-255358eba012@htwk-leipzig.de> Message-ID: > https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview > list of accepted papers is invisible, navigation not usable, > unless you allow third-party trackers (ajax.googleapis.com) Oh, so that's what's going on! And here I was, thinking the list of accepted papers was still not available. Yes this reliance on google kinda sucks. Stefan From a.pelenitsyn at gmail.com Mon Jul 15 19:05:23 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Mon, 15 Jul 2019 15:05:23 -0400 Subject: [Haskell-cafe] Haskell Symposium: early reg deadline is next week In-Reply-To: References: <2403f89f-1cad-6c03-f5fc-255358eba012@htwk-leipzig.de> Message-ID: Dear all, I reported the issue with googleapis to the general admin. They say it'll be fixed soon. And thank for bringing this up. -- Best, Artem On Mon, 15 Jul 2019, 2:54 pm Stefan Monnier, wrote: > > https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview > > list of accepted papers is invisible, navigation not usable, > > unless you allow third-party trackers (ajax.googleapis.com) > > Oh, so that's what's going on! > And here I was, thinking the list of accepted papers was still not > available. Yes this reliance on google kinda sucks. > > > Stefan > > _______________________________________________ > 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 rae at richarde.dev Tue Jul 16 02:24:13 2019 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 15 Jul 2019 22:24:13 -0400 Subject: [Haskell-cafe] Haskell Symposium: early reg deadline is next week In-Reply-To: References: <2403f89f-1cad-6c03-f5fc-255358eba012@htwk-leipzig.de> Message-ID: <2B22C5ED-C1FB-4340-87C3-9FD6E5AD8B5C@richarde.dev> Thanks for reporting this, Artem, and for figuring out what was going on Johannes. It shouldn't be. I will follow up, as well. Thanks, Richard > On Jul 15, 2019, at 3:05 PM, Artem Pelenitsyn wrote: > > Dear all, > > I reported the issue with googleapis to the general admin. They say it'll be fixed soon. And thank for bringing this up. > > -- > Best, Artem > > On Mon, 15 Jul 2019, 2:54 pm Stefan Monnier, > wrote: > > https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview > > list of accepted papers is invisible, navigation not usable, > > unless you allow third-party trackers (ajax.googleapis.com ) > > Oh, so that's what's going on! > And here I was, thinking the list of accepted papers was still not > available. Yes this reliance on google kinda sucks. > > > Stefan > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From theflossinformation at yandex.com Tue Jul 16 12:55:01 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Tue, 16 Jul 2019 15:55:01 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?11?= In-Reply-To: References: Message-ID: <854261563281701@mxfront1q.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From a.pelenitsyn at gmail.com Wed Jul 17 10:33:05 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Wed, 17 Jul 2019 06:33:05 -0400 Subject: [Haskell-cafe] Haskell Symposium: early reg deadline is next week In-Reply-To: References: <2403f89f-1cad-6c03-f5fc-255358eba012@htwk-leipzig.de> Message-ID: Hello cafe, Those who had troubles accessing website of HS with googleapis blocked should have no problem now. -- Kind regards, Artem On Mon, Jul 15, 2019, 2:54 PM Stefan Monnier wrote: > > https://icfp19.sigplan.org/home/haskellsymp-2019#event-overview > > list of accepted papers is invisible, navigation not usable, > > unless you allow third-party trackers (ajax.googleapis.com) > > Oh, so that's what's going on! > And here I was, thinking the list of accepted papers was still not > available. Yes this reliance on google kinda sucks. > > > Stefan > > _______________________________________________ > 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 theflossinformation at yandex.com Wed Jul 17 12:55:04 2019 From: theflossinformation at yandex.com (=?utf-8?B?SW5mb3JtYXRpb24gVGhlIEZMT1NT?=) Date: Wed, 17 Jul 2019 15:55:04 +0300 Subject: [Haskell-cafe] =?utf-8?q?Haskell-Cafe_Digest=2C_Vol_191=2C_Issue_?= =?utf-8?q?12?= In-Reply-To: References: Message-ID: <361151563368104@mxfront1j.mail.yandex.net> Bu ileti The FLOSS Information'a gönderdiğiniz ileti sonucunda otomatik olarak oluşturuldu. Bu iletiye yanıt vermenize gerek yoktur. Bu iletiyi gönderdiğiniz için teşekkür ederiz. 4 gün içerisinde yanıtlamaya çalışacağız. Eğer 4 gün içinde yanıt gelmezse tekrar ileti gönderebilirsiniz. Sık Sorulabilecek Sorular: https://theflossinformation.gitlab.io/sik-sorulabilecek-sorular.html Hakkımızda: https://theflossinformation.gitlab.io/hakkimizda.html Bize Ulaşın: https://theflossinformation.gitlab.io/bize-ulasin.html Saygılarımızla, The FLOSS Information https://theflossinformation.gitlab.io/ From schernichkin at gmail.com Wed Jul 17 14:02:45 2019 From: schernichkin at gmail.com (=?UTF-8?B?0KHRgtCw0L3QuNGB0LvQsNCyINCn0LXRgNC90LjRh9C60LjQvQ==?=) Date: Wed, 17 Jul 2019 16:02:45 +0200 Subject: [Haskell-cafe] Benefits and use cases for strong mobility in presence of closure serialization Message-ID: Benefits and use cases for strong mobility in presence of closure serialization I read a paper about strong mobility in Haskell http://www.dcs.gla.ac.uk/~trinder/papers/strongm.pdf and I wondering what benefits it gives in presence of closure serialization? I guess for some languages strong mobility could be only way to transfer execution state of program, e.g. [Mobile Pascal;)] program Test; var a: Integer; begin readln(a); // acquiring on current host moveTo("anotherHost"); // transfering state and terminating writeln(a); // printing on another host end. but in Haskell same program can be written just using rfork :: Host -> IO () -> IO (): main = do a <- readLn rfork AnotherHost $ do print a The difference comparing to moveTo :: Host -> IO () version is purely syntactic: main = do a <- readLn moveTo AnotherHost print a -- Sincerely, Stanislav Chernichkin. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Jul 17 14:13:36 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 17 Jul 2019 10:13:36 -0400 Subject: [Haskell-cafe] Benefits and use cases for strong mobility in presence of closure serialization In-Reply-To: References: Message-ID: You might want to consider the difference between threads and processes — and that the latter are more or less impossible to get correct in the presence of multiple threads. On Wed, Jul 17, 2019 at 10:03 AM Станислав Черничкин wrote: > Benefits and use cases for strong mobility in presence of closure > serialization > > I read a paper about strong mobility in Haskell > http://www.dcs.gla.ac.uk/~trinder/papers/strongm.pdf and I wondering what > benefits it gives in presence of closure serialization? I guess for some > languages strong mobility could be only way to transfer execution state of > program, e.g. > > [Mobile Pascal;)] > program Test; > var > a: Integer; > begin > readln(a); // acquiring on current host > moveTo("anotherHost"); // transfering state and terminating > writeln(a); // printing on another host > end. > > but in Haskell same program can be written just using rfork :: Host -> IO > () -> IO (): > > main = do > a <- readLn > rfork AnotherHost $ do > print a > > The difference comparing to moveTo :: Host -> IO () version is purely > syntactic: > > main = do > a <- readLn > moveTo AnotherHost > print a > > -- > Sincerely, Stanislav Chernichkin. > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Wed Jul 17 18:53:15 2019 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Wed, 17 Jul 2019 14:53:15 -0400 Subject: [Haskell-cafe] Second Call for Participation: ICFP 2019 Message-ID: <5d2f6e9b8bc92_68f92ae6da55e5c445853@homer.mail> ** The Early Registration deadline is tomorrow! ** ===================================================================== Call for Participation ICFP 2019 24th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 18 - August 23, 2019 Berlin, Germany http://icfp19.sigplan.org/ Early Registration until July 18! ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. This year, ICFP is co-located with BOBKonf! * Overview and affiliated events: http://icfp19.sigplan.org/home * Program: http://icfp19.sigplan.org/program/program-icfp-2019 * Accepted papers: http://icfp19.sigplan.org/track/icfp-2019-papers * Registration is available via: https://regmaster4.com/2019conf/ICFP19/register.php Early registration ends 18 July, 2019. * Programming contest: https://icfpcontest2019.github.io/ * Student Research Competition: https://icfp19.sigplan.org/track/icfp-2019-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference In addition to BOBKonf (8/21), there are several events co-located with ICFP: * Erlang Workshop (8/18) * Functional Art, Music, Modeling and Design (8/23) * Functional High-Performance and Numerical Computing (8/18) * Haskell Implementors' Workshop (8/23) * Haskell Symposium (8/22-8/23) * miniKanren Workshop (8/22) * ML Family Workshop (8/22) * OCaml Workshop (8/23) * Programming Languages Mentoring Workshop (8/18) * Scheme Workshop (8/18) * Type-Driven Development (8/18) ### ICFP Organizers General Chair: Derek Dreyer (MPI-SWS, Germany) Artifact Evaluation Co-Chairs: Simon Marlow (Facebook, UK) Industrial Relations Chair: Alan Jeffrey (Mozilla Research, USA) Programming Contest Organiser: Ilya Sergey (Yale-NUS College, Singapore) Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: William J. Bowman (University of British Columbia, Canada) Workshops Co-Chair: Christophe Scholliers (Universiteit Gent, Belgium) Jennifer Hackett (University of Nottingham, UK) Conference Manager: Annabel Satin (P.C.K.) ### PACMPL Volume 3, Issue ICFP 2019 Principal Editor: François Pottier (Inria, France) Review Committee: Lennart Beringer (Princeton University, United States) Joachim Breitner (DFINITY Foundation, Germany) Laura M. Castro (University of A Coruña, Spain) Ezgi Çiçek (Facebook London, United Kingdom) Pierre-Evariste Dagand (LIP6/CNRS, France) Christos Dimoulas (Northwestern University, United States) Jacques-Henri Jourdan (CNRS, LRI, Université Paris-Sud, France) Andrew Kennedy (Facebook London, United Kingdom) Daan Leijen (Microsoft Research, United States) Kazutaka Matsuda (Tohoku University, Japan) Bruno C. d. S. Oliveira (University of Hong Kong, China) Klaus Ostermann (University of Tübingen, Germany) Jennifer Paykin (Galois, United States) Frank Pfenning (Carnegie Mellon University, USA) Mike Rainey (Indiana University, USA) Chung-chieh Shan (Indiana University, USA) Sam Staton (University of Oxford, UK) Pierre-Yves Strub (Ecole Polytechnique, France) German Vidal (Universitat Politecnica de Valencia, Spain) External Review Committee: Michael D. Adams (University of Utah, USA) Robert Atkey (University of Strathclyde, IK) Sheng Chen (University of Louisiana at Lafayette, USA) James Cheney (University of Edinburgh, UK) Adam Chlipala (Massachusetts Institute of Technology, USA) Evelyne Contejean (LRI, Université Paris-Sud, France) Germán Andrés Delbianco (IRIF, Université Paris Diderot, France) Dominique Devriese (Vrije Universiteit Brussel, Belgium) Richard A. Eisenberg (Bryn Mawr College, USA) Conal Elliott (Target, USA) Sebastian Erdweg (Delft University of Technology, Netherlands) Michael Greenberg (Pomona College, USA) Adrien Guatto (IRIF, Université Paris Diderot, France) Jennifer Hackett (University of Nottingham, UK) Troels Henriksen (University of Copenhagen, Denmark) Chung-Kil Hur (Seoul National University, Republic of Korea) Roberto Ierusalimschy (PUC-Rio, Brazil) Ranjit Jhala (University of California, San Diego, USA) Ralf Jung (MPI-SWS, Germany) Ohad Kammar (University of Oxford, UK) Oleg Kiselyov (Tohoku University, Japan) Hsiang-Shang ‘Josh’ Ko (National Institute of Informatics, Japan) Ondřej Lhoták (University of Waterloo, Canada) Dan Licata (Wesleyan University, USA) Geoffrey Mainland (Drexel University, USA) Simon Marlow (Facebook, UK) Akimasa Morihata (University of Tokyo, Japan) Shin-Cheng Mu (Academia Sinica, Taiwan) Guillaume Munch-Maccagnoni (Inria, France) Kim Nguyễn (University of Paris-Sud, France) Ulf Norell (Gothenburg University, Sweden) Atsushi Ohori (Tohoku University, Japan) Rex Page (University of Oklahoma, USA) Zoe Paraskevopoulou (Princeton University, USA) Nadia Polikarpova (University of California, San Diego, USA) Jonathan Protzenko (Microsoft Research, USA) Tiark Rompf (Purdue University, USA) Andreas Rossberg (Dfinity, Germany) KC Sivaramakrishnan (University of Cambridge, UI) Nicholas Smallbone (Chalmers University of Technology, Sweden) Matthieu Sozeau (Inria, France) Sandro Stucki (Chalmers | University of Gothenburg, Sweden) Don Syme (Microsoft, UK) Zachary Tatlock (University of Washington, USA) Sam Tobin-Hochstadt (Indiana University, USA) Takeshi Tsukada (University of Tokyo, Japan) Tarmo Uustalu (Reykjavik University, Iceland) Benoit Valiron (LRI, CentraleSupelec, Univ. Paris Saclay, France) Daniel Winograd-Cort (University of Pennsylvania, USA) Nicolas Wu (University of Bristol, UK) From Graham.Hutton at nottingham.ac.uk Thu Jul 18 07:46:23 2019 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Thu, 18 Jul 2019 07:46:23 +0000 Subject: [Haskell-cafe] MPC 2019 - Call for Participation Message-ID: Dear all, Registration is now open for the Mathematics of Program Construction (MPC) conference in Portugal. MPC 2019 will feature 15 research papers and 4 keynotes, and is co-located with Formal Methods 2019 and many other events. See you in Porto! https://tinyurl.com/MPC-Porto Best wishes, Graham Hutton ====================================================================== *** CALL FOR PARTICIPATION -- MPC 2019 *** 13th International Conference on Mathematics of Program Construction 7-9 October 2019, Porto, Portugal Co-located with Formal Methods 2019 https://tinyurl.com/MPC-Porto ====================================================================== PROGRAM: https://tinyurl.com/yxvvc5vb ACCEPTED PAPERS: https://tinyurl.com/yyuhy8ze REGISTRATION AND TRAVEL: https://tinyurl.com/y4uetlsr KEYNOTE SPEAKERS: Assia Mahboubi (MPC) INRIA, France Annabelle McIver (MPC) Macquarie University, Australia Tony Hoare (UTP) Oxford University, UK Shriram Krishnamurthi (FM) Brown University, USA BACKGROUND: The International Conference on Mathematics of Program Construction (MPC) aims to promote the development of mathematical principles and techniques that are demonstrably practical and effective in the process of constructing computer programs. MPC 2019 will be held in Porto, Portugal from 7-9 October 2019, and is co-located with the International Symposium on Formal Methods, FM 2019. Previous conferences were held in Königswinter, Germany (2015); Madrid, Spain (2012); Québec City, Canada (2010); Marseille, France (2008); Kuressaare, Estonia (2006); Stirling, UK (2004); Dagstuhl, Germany (2002); Ponte de Lima, Portugal (2000); Marstrand, Sweden (1998); Kloster Irsee, Germany (1995); Oxford, UK (1992); Twente, The Netherlands (1989). PROGRAM COMMITTEE: Patrick Bahr IT University of Copenhagen, Denmark Richard Bird University of Oxford, UK Corina Cîrstea University of Southampton, UK Brijesh Dongol University of Surrey, UK João F. Ferreira University of Lisbon, Portugal Jennifer Hackett University of Nottingham, UK William Harrison University of Missouri, USA Ralf Hinze University of Kaiserslautern, Germany Zhenjiang Hu National Institute of Informatics, Japan Graham Hutton (chair) University of Nottingham, UK Cezar Ionescu University of Oxford, UK Mauro Jaskelioff National University of Rosario, Argentina Ranjit Jhala University of California, USA Gabriele Keller Utrecht University, The Netherlands Ekaterina Komendantskaya Heriot-Watt University, UK Chris Martens North Carolina State University, USA Bernhard Möller University of Augsburg, Germany Shin-Cheng Mu Academia Sinica, Taiwan Mary Sheeran Chalmers University of Technology, Sweden Alexandra Silva University College London, UK Georg Struth University of Sheffield, UK For any queries about the program please contact the program chair, Graham Hutton . CONFERENCE VENUE: The conference will be held at the Alfândega Porto Congress Centre, a 150 year old former custom's house located in the historic centre of Porto on the bank of the river Douro. The venue was renovated by a Pritzer prize winning architect and has received many awards. LOCAL ORGANISER: José Nuno Oliveira University of Minho, Portugal For any queries about local issues please contact the local organiser, José Nuno Oliveira . ====================================================================== 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 gabriel.rodriguez at udc.es Thu Jul 18 09:08:58 2019 From: gabriel.rodriguez at udc.es (=?Windows-1252?Q?Gabriel_Rodr=EDguez_=C1lvarez?=) Date: Thu, 18 Jul 2019 09:08:58 +0000 Subject: [Haskell-cafe] [CC2020] Call for Papers for the ACM SIGPLAN 2020 International Conference on Compiler Construction In-Reply-To: References: , , , , , , Message-ID: ACM SIGPLAN 2020 International Conference on Compiler Construction (CC'20) co-located with CGO, PPoPP and HPCA San Diego, CA, USA February 22 - 23, 2020 https://cc-conference.github.io The ACM SIGPLAN 2020 International Conference on Compiler Construction (CC 2020) is interested in work on processing programs in the most general sense: analyzing, transforming or executing input programs that describe how a system operates, including traditional compiler construction as a special case. Original contributions are solicited on the topics of interest which include, but are not limited to: - Compilation and interpretation techniques, including program representation, analysis, and transformation; code generation, optimization, and synthesis; the verification thereof - Run-time techniques, including memory management, virtual machines, and dynamic and just-in-time compilation - Programming tools, including refactoring editors, checkers, verifiers, compilers, debuggers, and profilers - Techniques for specific domains, such as secure, parallel, distributed, embedded or mobile environments - Design and implementation of novel language constructs, programming models, and domain-specific languages CC 2020 is the 29th edition of the conference. From this year onwards, CC is an ACM SIGPLAN conference and will implement guidelines and procedures recommended by SIGPLAN https://www.sigplan.org. ================================================================================================= To subscribe to the CC announce mailing list, see cc_conference_announce at googlegroups.com To subscribe to the CC announce Twitter account, see @cc2020conf (https://twitter.com/cc2020conf) ======================================================================================= IMPORTANT DATES Abstract Submission: 23 October 2019 Paper Submission : 30 October 2019 Rebuttal : 4-6 December 2019 Artifact Submission: 13 December 2019 Author Notification: 24 December 2019 Final papers due : 15 January 2020 Conference : 22–23 February 2020 Authors are encouraged to submit their artifacts for the Artifact Evaluation (AE). The Artifact Evaluation process is run by a separate committee whose task is to assess how the artifacts support the work described in the papers. To ease the organization of the AE committee, we kindly ask authors to submit their artifact at the latest 10 days after the rebuttal. Papers that go through the Artifact Evaluation process successfully will receive a seal of approval printed on the papers themselves. Additional information will be made available on the CC AE web page. ORGANIZERS General Chair Louis-Noel Pouchet Colorado State University Program Chair Alexandra Jimborean Uppsala University Artifact Evaluation Chairs Michel Steuwer University of Glasgow Martin Kong University of Oklahoma Publicity Chair Gabriel Rodriguez University of A Coruna Web Chair Mihail Popov Uppsala University Steering Committee Bjorn Franke University of Edinburgh Sebastian Hack Saarland University Manuel Hermenegildo IMDEA SW Institute and Technical U. of Madrid Peng Wu Huawei America Research Lab Ayal Zaks Intel and Technion, Israel Jingling Xue University of New South Wales, Australia Christophe Dubach University of Edinburgh Nelson J. Amaral University of Alberta Milind Kulkarni Purdue University Program Committee Apan Qasem AMD/Texas State University Bernhard Scholz University of Sydney Bettina Heim Microsoft Bilha Mendelson Optitura Brian Demsky UC Irvine Changhee Jung Virginia Tech Christian Schulte KTH EJ Park Los Alamos National Laboratory Delphine Demange Inria Dongyoon Lee Virginia Tech Fernando Magno Quintao Pereira UFMG Brazil Haowei Wu Google Manuel Hermenegildo IMDEA and T.U. Madrid Matin Hashemi Sharif University of Technology Michel Steuwer University of Glasgow Mila Dalla Preda University of Verona Nelson J. Amaral University of Alberta Philippe Clauss University of Strasbourg Pavlos Petoumenos University of Edinburgh Rumyana Neykova Brunel London Santosh Nagarakatte Rutgers University Sebastian Hack University of Saarland Tomofumi Yuki Inria Xu Liu College of William and Mary -------------- next part -------------- An HTML attachment was scrubbed... URL: From roconnor at theorem.ca Fri Jul 19 14:52:58 2019 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Fri, 19 Jul 2019 07:52:58 -0700 (PDT) Subject: [Haskell-cafe] ANNOUNCE: lens-family 2.0.0 anniversary edition! Message-ID: In celebration of the 10th anniversary of Twan van Laarhoven's seminal blog post ``CPS based functional references''[1], I am releasing version 2.0 of lens-family[2] and lens-family-core[3] packages. This new release continues to explore the design of Van Laarhoven style optics with new support for adapters, grates, grids[4], and prisms. To bring support to these new optics necessarily means moving a little further away from syntactic compatibility with Kmett's lens library. In particular, lens-family's 'under' is unrelated to Kmett's lens library's 'under' combinator. Nonetheless the 'under' combinator plays a crucial role in lens-family as a dual to the 'over' combinator and this naming is hard to resist despite the conflict. This new version comes with some minor incompatibilities with the version 1.2 library that may require user updates. See . [1] [2] [3] [4]A grid is an optic that is both a grate and a traversal. -- Russell O'Connor From ollie at ocharles.org.uk Fri Jul 19 14:57:48 2019 From: ollie at ocharles.org.uk (Oliver Charles) Date: Fri, 19 Jul 2019 15:57:48 +0100 Subject: [Haskell-cafe] ANNOUNCE: lens-family 2.0.0 anniversary edition! In-Reply-To: References: Message-ID: * '_Left' and '_Right' have been renamed as 'lft_' and 'rgt_'. Why? I fail to see the benefit of such a breaking change. On Fri, Jul 19, 2019 at 3:53 PM wrote: > > In celebration of the 10th anniversary of Twan van Laarhoven's seminal > blog post ``CPS based functional references''[1], I am releasing version > 2.0 of lens-family[2] and lens-family-core[3] packages. This new release > continues to explore the design of Van Laarhoven style optics with new > support for adapters, grates, grids[4], and prisms. > > To bring support to these new optics necessarily means moving a little > further away from syntactic compatibility with Kmett's lens library. > In particular, lens-family's 'under' is unrelated to Kmett's lens > library's 'under' combinator. Nonetheless the 'under' combinator plays > a crucial role in lens-family as a dual to the 'over' combinator and > this naming is hard to resist despite the conflict. > > This new version comes with some minor incompatibilities with the version > 1.2 library that may require user updates. > See . > > [1] > [2] > [3] > [4]A grid is an optic that is both a grate and a traversal. > > -- > Russell O'Connor > _______________________________________________ > 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 roconnor at theorem.ca Fri Jul 19 15:03:55 2019 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Fri, 19 Jul 2019 08:03:55 -0700 (PDT) Subject: [Haskell-cafe] ANNOUNCE: lens-family 2.0.0 anniversary edition! In-Reply-To: References: Message-ID: On Fri, 19 Jul 2019, Oliver Charles wrote: > * '_Left' and '_Right' have been renamed as 'lft_' and 'rgt_'. > > Why? I fail to see the benefit of such a breaking change. I have a new convention that 'foo_' is defined as 'under foo' (or something similar). Naturally, users can stick with the 1.2 release of lens-family if it suits their needs. -- Russell O'Connor ``My friends, love is better than anger. Hope is better than fear. Optimism is better than dispair. So let us be loving, hopeful and optimistic. And we'll change the world.'' -- Jack Layton From carter.schonwald at gmail.com Fri Jul 19 23:12:45 2019 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 19 Jul 2019 19:12:45 -0400 Subject: [Haskell-cafe] ANNOUNCE: lens-family 2.0.0 anniversary edition! In-Reply-To: References: Message-ID: Hey Russell, is there any expository or tech reporty exposition of the differences in formulation and the why's wherefores of the new major release? (i'm genuinely curious since i'm quite wimpy in the lens foo) On Fri, Jul 19, 2019 at 10:53 AM wrote: > In celebration of the 10th anniversary of Twan van Laarhoven's seminal > blog post ``CPS based functional references''[1], I am releasing version > 2.0 of lens-family[2] and lens-family-core[3] packages. This new release > continues to explore the design of Van Laarhoven style optics with new > support for adapters, grates, grids[4], and prisms. > > To bring support to these new optics necessarily means moving a little > further away from syntactic compatibility with Kmett's lens library. > In particular, lens-family's 'under' is unrelated to Kmett's lens > library's 'under' combinator. Nonetheless the 'under' combinator plays > a crucial role in lens-family as a dual to the 'over' combinator and > this naming is hard to resist despite the conflict. > > This new version comes with some minor incompatibilities with the version > 1.2 library that may require user updates. > See . > > [1] > [2] > [3] > [4]A grid is an optic that is both a grate and a traversal. > > -- > Russell O'Connor > _______________________________________________ > 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 roconnor at theorem.ca Sat Jul 20 19:23:42 2019 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Sat, 20 Jul 2019 12:23:42 -0700 (PDT) Subject: [Haskell-cafe] ANNOUNCE: lens-family 2.0.0 anniversary edition! In-Reply-To: <0c37e3e3-e5e8-423c-b0d6-b12b7ce69eb8@Spark> References: <0c37e3e3-e5e8-423c-b0d6-b12b7ce69eb8@Spark> Message-ID: On Fri, 19 Jul 2019, Artyom Kazak wrote: > > Naturally, users can stick with the 1.2 release of lens-family if it > > suits their needs. > You can not easily have two versions of the same library in your dependency tree. So, only application developers will be able to stick to the 1.2 release without creating obstacles for > the rest of the ecosystem. I see. I hadn't given that much consideration. In that case, I apologize for the inconvience this upgrade may cause. I'll try to be more mindful of this in the future. -- Russell O'Connor ``My friends, love is better than anger. Hope is better than fear. Optimism is better than dispair. So let us be loving, hopeful and optimistic. And we'll change the world.'' -- Jack Layton From roconnor at theorem.ca Sat Jul 20 19:48:26 2019 From: roconnor at theorem.ca (roconnor at theorem.ca) Date: Sat, 20 Jul 2019 12:48:26 -0700 (PDT) Subject: [Haskell-cafe] ANNOUNCE: lens-family 2.0.0 anniversary edition! In-Reply-To: References: Message-ID: On Fri, 19 Jul 2019, Carter Schonwald wrote: > Hey Russell, is there any expository or tech reporty exposition of the differences in formulation and the why's wherefores of the new major release? (i'm genuinely curious since i'm quite > wimpy in the lens foo) There hasn't been a change in formulation of used in lens-family, rather the grate-like and adapter-like new formulations have been added along side. Perhaps you are asking about the different formulations between different lens libraries? I'm not sure what the best expositions are. "Profunctor Optics: Modular Data Accessors" by Pickering, Gibbons, and Wu at seems like a reasonably good presentation of the implementations. A library user is somewhat insualted from the details of the different implementations through the library combinators, but some differences remain. For example, in lens-family's van Laarhoven implementation, I require explicit casting between Grate-like, Adatper-like, and Lens-like optics, whereas a profunctor based implementation would treat all three class of optics uniformly. That said, you could have a van Laarhoven implementaion that uses Adapter-like for all optics and keep Identity functor wrappers around. This isn't done in lens-family in order to keep backwards compatibility with the original Lens-like optics. I've put out a new relase because I've started using grid optics in my own work. For example, I use 'bend' to create bit-wise parsing of 256-bit hash values @ , and I use an 'fe' grid @ , etc. to create instances of Arbitrary @ As far as I know, Kmett's lens library doesn't yet have much support for grates and grids, but I'm sure that will change. That said, a good tutorial on how to program with these new grates and grid optics would be useful. Unfortunately, I think these will take time to be developed. -- Russell O'Connor ``My friends, love is better than anger. Hope is better than fear. Optimism is better than dispair. So let us be loving, hopeful and optimistic. And we'll change the world.'' -- Jack Layton From ruben.astud at gmail.com Mon Jul 22 05:20:33 2019 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Mon, 22 Jul 2019 01:20:33 -0400 Subject: [Haskell-cafe] Translating a pre-image witness from agda to haskell Message-ID: Dear list I've been playing with agda lately, I've been following the tutorials on their homepage to get a grasp of dependent types. The exposition has been good and clear. Some techniques can be passed over to haskell by using GADTs and DataKinds. Some examples require singletons to have the same kind of quantification as in agda. Currently I am trying to write in haskell the following data type and function data Image {A B : Set} (f : A -> B) : B -> Set where im : (x : A) -> Image f (f x) inv : {A B : Set} (f : A -> B) (y : B) -> Image f y -> A inv f .(f x) (im x) = x The `Image` datatype correspond to the proposition that the function `f : A -> B` has a pre-image for certain element on `B`. This is witnessed only if the `im` data constructor exists. The `inv` function is there only to show how agda can know by the presence of the `im x` data constructor that the value of `y` cannot be other than `f x`, mind bending stuff. I've been trying to write this ADT on haskell. I haven't got luck in so far. The problem is that referring to a `type family` constructed from a term level function is not clear to me, even with singletons, as I cannot guarantee such type family is defined. Currently I got this data Image (f :: Type -> Type) Type where Im :: Proxy (Sing t1 -> Sing (f t1)) -> f t1 -> Image (Sing t1 -> Sing (f t1)) (f t1) Which isn't exactly what the agda version is. Does anyone has an idea on how to continue or has done this example before? I am perfectly OK with being told it's not possible yet or what should I read. -- -- Ruben -- PGP: 4EE9 28F7 932E F4AD From komendantskaya at gmail.com Mon Jul 22 10:50:56 2019 From: komendantskaya at gmail.com (Ekaterina Komendantskaya) Date: Mon, 22 Jul 2019 11:50:56 +0100 Subject: [Haskell-cafe] Journeys in Computational Logic: Tributes to Roy Dyckhoff : CFP Message-ID: CALL FOR PARTICIPATION Journeys in Computational Logic: Tributes to Roy Dyckhoff at TABLEAUX 2019, the 28th International Conference on Automated Reasoning with Analytic Tableaux and Related Methods, Middlesex University, London https://tableaux2019.org/ Main conference: 3 September to 5 September 2019 Journeys in Computational Logic: 3 September 2019 Roy Dyckhoff (1948 - 2018) worked in logic and proof theory, having begun his career as a topologist and category theorist (for which one of his thesis advisors was Dana Scott). Much of his work concerned various aspects of intuitionistic logic, but he also contributed to work in programming languages, type theory, natural language processing, and model checking. The event will commemorate and celebrate Roy’s work, by speakers who have crossed paths with Roy, and/or whose work or scientific views have been influenced by him. The workshop will follow the Tableaux invited talks by Sara Negri and Stéphane Graham-Lengrand, also dedicated to Roy’s work and contribution to the field. The list of contributors is as follows: Marta Bilkova Alessio Guglielmi Jacob Howe Jael Kriener James McKinna Mehrnoosh Sadrzadeh Peter Schroeder-Heister Christian Urban SOCIAL EVENT The workshop will be followed by the Tableaux welcome reception. ORGANISERS If you have any questions, or wish to contribute a talk, please contact the organisers: Ekaterina Komendantskaya: http://www.macs.hw.ac.uk/~ek19/ Stephane Graham-Lengrand: http://www.csl.sri.com/users/sgl/ Mehrnoosh Sadrzadeh: https://msadrzadeh.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lysxia at gmail.com Mon Jul 22 11:06:32 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Mon, 22 Jul 2019 07:06:32 -0400 Subject: [Haskell-cafe] Translating a pre-image witness from agda to haskell In-Reply-To: References: Message-ID: <32f9fe51-ad61-4a30-4f1e-9d88cbf5e97a@gmail.com> Hi Ruben, A general way to represent functions in types in Haskell is via defunctionalization. - https://typesandkinds.wordpress.com/2013/04/01/defunctionalization-for-the-win/ - http://h2.jaguarpaw.co.uk/posts/hkd-pattern-type-level-ski/ - https://blog.poisson.chat/posts/2018-08-06-one-type-family.html "Defunctionalization" essentially gives you -- A kind for function symbols type a :-> b = ... -- A way to apply function symbols type family (f :: a :-> b) @@ (x :: a) :: b Equipped with that here's how you could define Image data Image (f :: a :-> b) :: b -> Type where Im :: Sing x -> Image f (f @@ x) There's a few variants depending on where you want to put singletons, but I think a good rule of thumb if you come from Agda is to not include type parameters and indices (f and y), only terms actually introduced by the constructor (x). Defunctionalization in general has a great many applications. There's this great Compose 2019 talk about it: - http://www.pathsensitive.com/2019/07/the-best-refactoring-youve-never-heard.html Li-yao On 7/22/19 1:20 AM, Ruben Astudillo wrote: > Dear list > > I've been playing with agda lately, I've been following the > tutorials on their homepage to get a grasp of dependent types. The > exposition has been good and clear. Some techniques can be passed over > to haskell by using GADTs and DataKinds. Some examples require > singletons to have the same kind of quantification as in agda. Currently > I am trying to write in haskell the following data type and function > > data Image {A B : Set} (f : A -> B) : B -> Set where > im : (x : A) -> Image f (f x) > > inv : {A B : Set} (f : A -> B) (y : B) -> Image f y -> A > inv f .(f x) (im x) = x > > The `Image` datatype correspond to the proposition that the function `f > : A -> B` has a pre-image for certain element on `B`. This is witnessed > only if the `im` data constructor exists. The `inv` function is there > only to show how agda can know by the presence of the `im x` data > constructor that the value of `y` cannot be other than `f x`, mind > bending stuff. > > I've been trying to write this ADT on haskell. I haven't got luck > in so far. The problem is that referring to a `type family` constructed > from a term level function is not clear to me, even with singletons, as > I cannot guarantee such type family is defined. Currently I got this > > data Image (f :: Type -> Type) Type where > Im :: Proxy (Sing t1 -> Sing (f t1)) -> f t1 > -> Image (Sing t1 -> Sing (f t1)) (f t1) > > Which isn't exactly what the agda version is. Does anyone has an idea on > how to continue or has done this example before? I am perfectly OK with > being told it's not possible yet or what should I read. > From ben at well-typed.com Mon Jul 22 23:34:17 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 22 Jul 2019 19:34:17 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 8.8.1 release candidate 1 is now available Message-ID: <878sspod8v.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the release candidate for GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/ghc/8.8.1-rc1 This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * A comprehensive audit of GHC's memory ordering barriers has been performed, resulting in a number of fixes that should significantly improve the reliability of programs on architectures with weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 implementations). * A long-standing linker limitation rendering GHCi unusable with projects with cyclic symbol dependencies has been fixed (#13786) * Further work on the Hadrian build system * Numerous bug-fixes As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-rc1/docs/html/users_guide/8.8.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From sergueyz at gmail.com Tue Jul 23 09:45:05 2019 From: sergueyz at gmail.com (Serguey Zefirov) Date: Tue, 23 Jul 2019 12:45:05 +0300 Subject: [Haskell-cafe] What is the most modern associative list in types? Message-ID: Hello cafe. I am trying to express some environment in types to constrain program behavour. For this I need associative list of types, something along the lines of [(Symbol, *)] so that I can lookup on "variable" name and get type associated with it. I looked into HList library but it does not provide one most generally useful way (albeit there are dozen or so of ways in there). So where can I get most modern HList-like library? Or what should I read to get most modern HList myself? -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.pelenitsyn at gmail.com Tue Jul 23 16:51:40 2019 From: a.pelenitsyn at gmail.com (Artem Pelenitsyn) Date: Tue, 23 Jul 2019 12:51:40 -0400 Subject: [Haskell-cafe] What is the most modern associative list in types? In-Reply-To: References: Message-ID: Hello Serguey, I think a very similar task was tackled by Richard Eisenberg in his Stitch manuscript (from 2018) by simple vectors (i.e length-indexed lists): checkout Section 6 of https://cs.brynmawr.edu/~rae/papers/2018/stitch/stitch.pdf, and the Ctx type in particular. They use De Bruijn, so your assoc lists end up just vectors. Otherwise, it would be the same HList, essentially. So maybe this answer is not enlightening, but maybe you find the paper useful, at least. -- Kind regards, Artem Pelenitsyn On Tue, 23 Jul 2019 at 05:45, Serguey Zefirov wrote: > Hello cafe. > > I am trying to express some environment in types to constrain program > behavour. For this I need associative list of types, something along the > lines of [(Symbol, *)] so that I can lookup on "variable" name and get type > associated with it. > > I looked into HList library but it does not provide one most generally > useful way (albeit there are dozen or so of ways in there). > > So where can I get most modern HList-like library? Or what should I read > to get most modern HList myself? > _______________________________________________ > 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 sergueyz at gmail.com Wed Jul 24 14:04:53 2019 From: sergueyz at gmail.com (Serguey Zefirov) Date: Wed, 24 Jul 2019 17:04:53 +0300 Subject: [Haskell-cafe] What is the most modern associative list in types? In-Reply-To: References: Message-ID: Yes, it is extremely useful, thank you very much! вт, 23 июл. 2019 г. в 19:51, Artem Pelenitsyn : > Hello Serguey, > > I think a very similar task was tackled by Richard Eisenberg in his Stitch > manuscript (from 2018) by simple vectors (i.e length-indexed lists): > checkout Section 6 of > https://cs.brynmawr.edu/~rae/papers/2018/stitch/stitch.pdf, and the Ctx > type in particular. > They use De Bruijn, so your assoc lists end up just vectors. Otherwise, it > would be the same HList, essentially. So maybe this answer is not > enlightening, but maybe you find the paper useful, at least. > > -- > Kind regards, > Artem Pelenitsyn > > > On Tue, 23 Jul 2019 at 05:45, Serguey Zefirov wrote: > >> Hello cafe. >> >> I am trying to express some environment in types to constrain program >> behavour. For this I need associative list of types, something along the >> lines of [(Symbol, *)] so that I can lookup on "variable" name and get type >> associated with it. >> >> I looked into HList library but it does not provide one most generally >> useful way (albeit there are dozen or so of ways in there). >> >> So where can I get most modern HList-like library? Or what should I read >> to get most modern HList myself? >> _______________________________________________ >> 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 diaz.carrete at gmail.com Wed Jul 24 14:05:00 2019 From: diaz.carrete at gmail.com (=?UTF-8?B?RGFuaWVsIETDrWF6?=) Date: Wed, 24 Jul 2019 16:05:00 +0200 Subject: [Haskell-cafe] What is the most modern associative list in types? Message-ID: Hi Serguey, I don’t know what extra functionality you require but, for what is worth, my library red-black-record features a Symbol-to-Type map . It’s implemented as a type-level red-black-tree. https://hackage.haskell.org/package/red-black-record-2.0.2.2/docs/Data-RBR.html#t:Map The map can be manipulated with the Insert, Delete and Value associated type families. Regards, Daniel Díaz > Hello cafe. > > I am trying to express some environment in types to constrain program > behavour. For this I need associative list of types, something along the > lines of [(Symbol, *)] so that I can lookup on "variable" name and get type > associated with it. > > I looked into HList library but it does not provide one most generally > useful way (albeit there are dozen or so of ways in there). > > So where can I get most modern HList-like library? Or what should I read > to get most modern HList myself? -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Fri Jul 26 10:58:58 2019 From: publicityifl at gmail.com (Jurriaan Hage) Date: Fri, 26 Jul 2019 03:58:58 -0700 Subject: [Haskell-cafe] Final call for draft papers for IFL 2019 (Implementation and Application of Functional Languages) Message-ID: Hello, Please, find below the final call for draft papers for IFL 2019. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2019 31st Symposium on Implementation and Application of Functional Languages National University of Singapore September 25th-27th, 2019 http://2019.iflconference.org ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2019 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Keynote Speaker * Olivier Danvy, Yale-NUS College ### Submissions and peer-review Differently from previous editions of IFL, IFL 2019 solicits two kinds of submissions: * Regular papers (12 pages including references) * Draft papers for presentations ('weak' limit between 8 and 15 pages) Regular papers will undergo a rigorous review by the program committee, and will be evaluated according to their correctness, novelty, originality, relevance, significance, and clarity. A set of regular papers will be conditionally accepted for publication. Authors of conditionally accepted papers will be provided with committee reviews along with a set of mandatory revisions. Regular papers not accepted for publication will be considered as draft papers, at the request of the author. Draft papers will be screened to make sure that they are within the scope of IFL, and will be accepted for presentation or rejected accordingly. Prior to the symposium: Authors of conditionally accepted papers and accepted presentations will submit a pre-proceedings version of their work that will appear in the draft proceedings distributed at the symposium. The draft proceedings does not constitute a formal publication. We require that at least one of the authors present the work at IFL 2019. After the symposium: Authors of conditionally accepted papers will submit a revised versions of their paper for the formal post-proceedings. The program committee will assess whether the mandatory revisions have been adequately addressed by the authors and thereby determines the final accept/reject status of the paper. Our interest is to ultimately accept all conditionally accepted papers. If you are an author of a conditionally accepted paper, please make sure that you address all the concerns of the reviewers. Authors of accepted presentations will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal post-proceedings. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected. ### Publication The formal proceedings will appear in the International Conference Proceedings Series of the ACM Digital Library. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication ### Important dates Submission of regular papers: June 15, 2019 Submission of draft papers: August 1, 2019 Regular papers notification: August 1, 2019 Regular draft papers notification: August 7, 2019 Deadline for early registration: August 15, 2019 Submission of pre-proceedings version: September 15, 2019 IFL Symposium: September 25-27, 2019 Submission of papers for post-proceedings: November 30, 2019 Notification of acceptance: January 31, 2020 Camera-ready version: February 29, 2020 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2019 ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organization and Program committee Chairs: Jurrien Stutterheim (Standard Chartered Bank Singapore), Wei Ngan Chin (National University of Singapore) Program Committee: - Olaf Chitil, University of Kent - Clemens Grelck, University of Amsterdam - Daisuke Kimura, Toho University - Pieter Koopman, Radboud University - Tamás Kozsik, Eötvös Loránd University - Roman Leschinskiy, Facebook - Ben Lippmeier, The University of New South Wales - Marco T. Morazan, Seton Hall University - Sven-Bodo Scholz, Heriot-Watt University - Tom Schrijvers, Katholieke Universiteit Leuven - Alejandro Serrano, Utrecht University - Tony Sloane, Macquarie University - Simon Thompson, University of Kent - Marcos Viera, Universidad de la República - Wei Ngan Chin, NUS - Jurriën Stutterheim, Standard Chartered Bank ### Venue The 31st IFL is organized by the National University of Singapore. Singapore is located in the heart of South-East Asia, and the city itself is extremely well connected by trains and taxis. See the website for more information on the venue. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organizers for their work, which is reused here. A part of IFL 2019 format and CFP language that describes conditionally accepted papers has been adapted from call-for-papers of OOPSLA conferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcj at alasconnect.com Fri Jul 26 16:56:17 2019 From: bcj at alasconnect.com (Brian C. Jones) Date: Fri, 26 Jul 2019 16:56:17 +0000 Subject: [Haskell-cafe] [twilio] Project takeover initiation Message-ID: Hello, I have attempted to contact the author via PR and direct email with no response in 3 weeks. This is my final attempt before engaging the Hackage admins. https://github.com/markandrus/twilio-haskell/pull/67 Brian Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosmiafu at gmail.com Sun Jul 28 09:37:39 2019 From: cosmiafu at gmail.com (Cosmia Fu) Date: Sun, 28 Jul 2019 18:37:39 +0900 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion Message-ID: Hi everyone, Though some of you might already knows, I'm pleased to announce a new Haskell book, *To Kata Haskellen Evangelion*. Link: https://cosmius.bitbucket.io/tkhe/ I believe that it does not have to be hard to learn Haskell. I begun to write the book in 2017 December, and... to be honest, I don't know what to write now, though I still think it incomplete. It will probably not be updated for quite a while. So I decide to announce it earlier. I am not a native English speaker, so it might be not fluent or even with a lot of grammar mistakes. It would be very nice of you if you can tell me the mistakes in it, factual, technical or grammar. And also feel free to tell me if you want to read some topic in it. Thank you ---- Cosmia Fu -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadine.and.henry at pobox.com Sun Jul 28 11:56:40 2019 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Sun, 28 Jul 2019 06:56:40 -0500 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family Message-ID: <23869.36216.153082.357635@gargle.gargle.HOWL> Dear Cafe, I really don't understand what is going on here. I've searched, but I don't really understand the links that I found. The closest I've come is: https://sulzmann.blogspot.com/2013/01/non-injective-type-functions-and.html but I don't understand it enough to see my way to a solution. Here is a minimal example of what I'm trying to do: -------------------------------------------------------------------------------- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} module Ambiguous where class Ambi a where type SubAmbi a :: * toSubAmbi :: a -> SubAmbi a toBool :: SubAmbi a -> Bool whatsWrong :: Ambi a => a -> IO () whatsWrong a = do let s = toSubAmbi a b = toBool s if b then print "True" else print "False" {- src/Games/Ambiguous.hs:15:16: error: … • Couldn't match expected type ‘SubAmbi a0’ with actual type ‘SubAmbi a’ NB: ‘SubAmbi’ is a non-injective type family The type variable ‘a0’ is ambiguous • In the first argument of ‘toBool’, namely ‘s’ In the expression: toBool s In an equation for ‘b’: b = toBool s • Relevant bindings include s :: SubAmbi a (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:14:5) a :: a (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:12:12) whatsWrong :: a -> IO () (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:12:1) | Compilation failed. -} -------------------------------------------------------------------------------- Could any of you Haskell sages please explain how to do this? Best wishes, Henry Laxen -- Nadine and Henry Laxen The rest is silence Villa Alta #6 Calle Gaviota #10 Never try to teach a pig to sing Chapala It wastes your time +52 (376) 765-3181 And it annoys the pig From lysxia at gmail.com Sun Jul 28 12:09:42 2019 From: lysxia at gmail.com (Li-yao Xia) Date: Sun, 28 Jul 2019 08:09:42 -0400 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family In-Reply-To: <23869.36216.153082.357635@gargle.gargle.HOWL> References: <23869.36216.153082.357635@gargle.gargle.HOWL> Message-ID: <39ddf74c-b60c-384c-7d4a-78c0b81ce4c0@gmail.com> Hi Henry, In this context you have: s :: SubAmbi a toBool :: Ambi b => SubAmbi b -> Bool where b is a fresh type variable stemming from the instantiation of toBool. When you apply toBool to s, you need to unify (SubAmbi a) and (SubAmbi b), however that doesn't unify a and b because SubAmbi is not known to be injective. So you don't know that `a` and `b` are equal, and so you don't know that `SubAmbi a` and `SubAmbi b` are equal. This problem happens whenever, in a function's signature, a type variable appears only under type families. You can resolve the ambiguity by applying toBool explicitly to the type a. {-# LANGUAGE ..., ScopedTypeVariables, TypeApplications #-} -- Allow "a" to be referred to in the definition whatsWrong :: forall a. Ambi a => a -> IO () whatsWrong = dp let s = toSubAmbi a b = toBool @a s -- Instantiate toBool at type "a" {- ... -} Cheers, Li-yao On 7/28/19 7:56 AM, Henry Laxen wrote: > Dear Cafe, > > I really don't understand what is going on here. I've searched, but I don't > really understand the links that I found. The closest I've come is: > > https://sulzmann.blogspot.com/2013/01/non-injective-type-functions-and.html > > but I don't understand it enough to see my way to a solution. Here is a > minimal example of what I'm trying to do: > > -------------------------------------------------------------------------------- > > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE AllowAmbiguousTypes #-} > > module Ambiguous where > > class Ambi a where > type SubAmbi a :: * > toSubAmbi :: a -> SubAmbi a > toBool :: SubAmbi a -> Bool > > whatsWrong :: Ambi a => a -> IO () > whatsWrong a = do > let > s = toSubAmbi a > b = toBool s > if b then print "True" else print "False" > > > {- > > src/Games/Ambiguous.hs:15:16: error: … > • Couldn't match expected type ‘SubAmbi a0’ > with actual type ‘SubAmbi a’ > NB: ‘SubAmbi’ is a non-injective type family > The type variable ‘a0’ is ambiguous > • In the first argument of ‘toBool’, namely ‘s’ > In the expression: toBool s > In an equation for ‘b’: b = toBool s > • Relevant bindings include > s :: SubAmbi a > (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:14:5) > a :: a > (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:12:12) > whatsWrong :: a -> IO () > (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:12:1) > | > Compilation failed. > > -} > -------------------------------------------------------------------------------- > > Could any of you Haskell sages please explain how to do this? > > Best wishes, > Henry Laxen > From cosmiafu at gmail.com Sun Jul 28 13:40:04 2019 From: cosmiafu at gmail.com (Cosmia Fu) Date: Sun, 28 Jul 2019 22:40:04 +0900 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family In-Reply-To: <23869.36216.153082.357635@gargle.gargle.HOWL> References: <23869.36216.153082.357635@gargle.gargle.HOWL> Message-ID: In short, given the following definition instance Ambi WhatEver1 where type SubAmbi a = () instance Ambi WhatEver2 where type SubAmbi a = () When you try to call `toBool ()`, GHC cannot decide which instance to use, they are both valid candidates. ---- Cosmia Fu On Sun, Jul 28, 2019 at 8:56 PM Henry Laxen wrote: > > Dear Cafe, > > I really don't understand what is going on here. I've searched, but I don't > really understand the links that I found. The closest I've come is: > > https://sulzmann.blogspot.com/2013/01/non-injective-type-functions-and.html > > but I don't understand it enough to see my way to a solution. Here is a > minimal example of what I'm trying to do: > > -------------------------------------------------------------------------------- > > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE AllowAmbiguousTypes #-} > > module Ambiguous where > > class Ambi a where > type SubAmbi a :: * > toSubAmbi :: a -> SubAmbi a > toBool :: SubAmbi a -> Bool > > whatsWrong :: Ambi a => a -> IO () > whatsWrong a = do > let > s = toSubAmbi a > b = toBool s > if b then print "True" else print "False" > > > {- > > src/Games/Ambiguous.hs:15:16: error: … > • Couldn't match expected type ‘SubAmbi a0’ > with actual type ‘SubAmbi a’ > NB: ‘SubAmbi’ is a non-injective type family > The type variable ‘a0’ is ambiguous > • In the first argument of ‘toBool’, namely ‘s’ > In the expression: toBool s > In an equation for ‘b’: b = toBool s > • Relevant bindings include > s :: SubAmbi a > (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:14:5) > a :: a > (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:12:12) > whatsWrong :: a -> IO () > (bound at /home/henry/nadineloveshenry/bin/nlh/src/Games/Ambiguous.hs:12:1) > | > Compilation failed. > > -} > -------------------------------------------------------------------------------- > > Could any of you Haskell sages please explain how to do this? > > Best wishes, > Henry Laxen > > -- > Nadine and Henry Laxen The rest is silence > Villa Alta #6 > Calle Gaviota #10 Never try to teach a pig to sing > Chapala It wastes your time > +52 (376) 765-3181 And it annoys the pig > _______________________________________________ > 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 dsf at seereason.com Sun Jul 28 15:51:18 2019 From: dsf at seereason.com (David Fox) Date: Sun, 28 Jul 2019 08:51:18 -0700 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: Message-ID: On page 39 you say A type can have Ord instance only when it has Eq instance, since if you > want to compare items, you need a way to test if they are equal. So from my reading of this you are saying that an Eq instance for a type needs to be supplied before we are allowed to implement compare. However it is easy to write a compare function that makes no use of the underlying (==) function. Indeed, once you have done this you can turn around and write a == b = compare a b == EQ. So I was wondering if you could clarify the role of constraints in the class declaration. On Sun, Jul 28, 2019 at 2:38 AM Cosmia Fu wrote: > Hi everyone, > > Though some of you might already knows, I'm pleased to announce a new > Haskell book, > *To Kata Haskellen Evangelion*. > Link: https://cosmius.bitbucket.io/tkhe/ > I believe that it does not have to be hard to learn Haskell. > > I begun to write the book in 2017 December, and... to be honest, > I don't know what to write now, though I still think it incomplete. > It will probably not be updated for quite a while. > So I decide to announce it earlier. > > I am not a native English speaker, so it might be not fluent or even with > a lot of grammar mistakes. > It would be very nice of you if you can tell me the mistakes in it, > factual, technical or grammar. > And also feel free to tell me if you want to read some topic in it. > > Thank you > > ---- > > Cosmia Fu > _______________________________________________ > 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 leah at vuxu.org Sun Jul 28 15:58:31 2019 From: leah at vuxu.org (Leah Neukirchen) Date: Sun, 28 Jul 2019 17:58:31 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2019-07-31 @ 19:30 Message-ID: <878ssii21k.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 31 at Augustiner-Gaststätte Rumpler at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-jul-2019/ Everybody is welcome! cu, -- Leah Neukirchen https://leahneukirchen.org/ From sergey.bushnyak at sigrlami.eu Sun Jul 28 16:26:23 2019 From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak) Date: Sun, 28 Jul 2019 19:26:23 +0300 Subject: [Haskell-cafe] [language-dart] Package takeover initiation Message-ID: <6838a3d3-056e-1037-1a2d-c82965cf7cda@sigrlami.eu> Hi all, I tried to contact the author via github issues and direct email with no response in couple weeks. This is my statement on desire to takeover package maintainership forhttps://hackage.haskell.org/package/language-dart -- Sergey Bushnyak -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.kjeldaas at gmail.com Sun Jul 28 19:28:24 2019 From: alexander.kjeldaas at gmail.com (Alexander Kjeldaas) Date: Sun, 28 Jul 2019 21:28:24 +0200 Subject: [Haskell-cafe] [twilio] Project takeover initiation In-Reply-To: References: Message-ID: Remember that it's vacation in large parts of the world now and since your PR was made. Alexander On Fri, Jul 26, 2019, 18:56 Brian C. Jones wrote: > Hello, > > I have attempted to contact the author via PR and direct email with no > response in 3 weeks. This is my final attempt before engaging the Hackage > admins. > > https://github.com/markandrus/twilio-haskell/pull/67 > > > Brian Jones > _______________________________________________ > 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 markandrusroberts at gmail.com Sun Jul 28 19:49:16 2019 From: markandrusroberts at gmail.com (Mark Roberts) Date: Sun, 28 Jul 2019 12:49:16 -0700 Subject: [Haskell-cafe] [twilio] Project takeover initiation In-Reply-To: References: Message-ID: Hey, I’m the maintainer. I’ll follow up with you in another email. - Mark On Sun, Jul 28, 2019 at 12:29 PM Alexander Kjeldaas < alexander.kjeldaas at gmail.com> wrote: > Remember that it's vacation in large parts of the world now and since your > PR was made. > > Alexander > > On Fri, Jul 26, 2019, 18:56 Brian C. Jones wrote: > >> Hello, >> >> I have attempted to contact the author via PR and direct email with no >> response in 3 weeks. This is my final attempt before engaging the Hackage >> admins. >> >> https://github.com/markandrus/twilio-haskell/pull/67 >> >> >> Brian Jones >> > _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Jul 29 06:07:14 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 29 Jul 2019 14:07:14 +0800 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family Message-ID: > I really don't understand what is going on here. ... -------------------------------------------------------------------------------- > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE AllowAmbiguousTypes #-} > {- > > src/Games/Ambiguous.hs:15:16: error: … > • Couldn't match expected type ‘SubAmbi a0’ > with actual type ‘SubAmbi a’ > NB: ‘SubAmbi’ is a non-injective type family > The type variable ‘a0’ is ambiguous > > -} Hi Henry, both replies you've received are excellent, I won't expand on them. I am interested in how you got into such a pickle in the first place: Why set `AllowAmbiguousTypes`? Did you understand what that means? Did you think it odd that despite having that set, you get error `type variable ... is ambiguous`? There are ways to achieve what you want without `AllowAmbiguousTypes` nor `TypeApplications`, but that would need a rather different design. So what lead you into this design? AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadine.and.henry at pobox.com Mon Jul 29 11:31:36 2019 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Mon, 29 Jul 2019 06:31:36 -0500 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family Message-ID: <23870.55576.197357.620376@gargle.gargle.HOWL> First, thank you Li-yao Xia for your clear and helpful response. I was able to continue thanks to you. Thanks for the question Anthony, I look forward to learning something. I hope I'll be explain this clearly. I am writing some games, which can share some code, such as logging in, and broadcasting messages to players. I started by writing just one game, with no consideration for how and what to share. This let to a gamestate which contained things like: newtype GameId = GameId Int data Game1 { _game1TimeStarted :: UTCTime, _game1PlayerId :: GameId, ... _game1RandomGen :: StdGen, _game1Commands :: [Game1Command] } the actual state is a more complicated than this, because I split it into a Static part and a Mutable part that is in a TVar (Map GameId Game1MutableState) Next I start writing Game2, which I discover will do the same kind of broadcasting of messages (Commands) as Game1. So I would like to use the same code in Game2 as in Game1 that handles the broadcasting. I came up with: (this is part of the actual class I am using) class Game a where type Command a :: * type Mutable a :: * type Static a :: * toGameId :: a -> GameId toMutable :: a -> IO (Maybe (Mutable a)) everyone :: Mutable a -> [Sink] instance Game Game1State where type Command Game1State = Game1Command type Mutable Game1State = Game1Mutable type Static Game1State = Game1Static toGameId ss = ss ^. game1Static . game1GameId toMutable ss = do let tVar = ss ^. game1Mutable gId = toGameId ss gm <- liftIO (readTVarIO tVar) return $ M.lookup gId (unGameMap gm) everyone = mapMaybe _game1Sink . M.elems . _game1SPMap similarly, I make Game2State an instance of Game. Now in the code that broadcasts commands I have: sendBroadCasts :: (Show (Command a) , Game a) => [BroadCast a] -> a -> IO () ... sendOneCommand :: (Show (Command a) , Game a) => a -> BroadCastReceiver -> Command a -> IO () sendOneCommand ss BroadCastToEveryone command = do mbMut <- toMutable ss case mbMut of Nothing -> return () Just mut -> do let sinks = everyone mut mapM_ (`sendCommand` command) sinks but GHC scolds me with: src/Games/BroadCasts.hs:53:12-23: error: … • Couldn't match type ‘Mutable a’ with ‘Mutable a0’ Expected type: IO (Maybe (Mutable a0)) Actual type: IO (Maybe (Mutable a)) NB: ‘Mutable’ is a non-injective type family The type variable ‘a0’ is ambiguous • In a stmt of a 'do' block: mbMut <- toMutable ss In the expression: ... After incorporating Li-yao Xia's suggestion, the code becomes: sendOneCommand :: forall a. (Show (Command a) , Game a) => ----------------- ^^^^^^^^^ this is added a -> BroadCastReceiver -> Command a -> IO () sendOneCommand _ (BroadCastToSome sinks) command = mapM_ (`sendCommand` command) sinks sendOneCommand ss BroadCastToEveryone command = do mbMut <- toMutable ss case mbMut of Nothing -> return () Just mut -> do let sinks = everyone @a mut -------------------------- ^^ this is added mapM_ (`sendCommand` command) sinks and GHC is happy. I hope I have explained this sufficiently clearly. I look forward to your insights. Best wishes, Henry Laxen >>>>> "Anthony" == Anthony Clayden writes: Anthony> Hi Henry, both replies you've received are excellent, I won't expand on them. Anthony> I am interested in how you got into such a pickle in the first place: Anthony> Why set `AllowAmbiguousTypes`? Did you understand what that means? ----------------------^^^^^^^^^^^^^^^^^^^^ I read https://stackoverflow.com/questions/49684655/how-dangerous-is-allowambiguoustypes-when-used-with-typeapplications which seems to indicate that using it is "a perfectly reasonable thing" Anthony> Did you think it odd that despite having that set, you get error Anthony> `type variable ... is ambiguous`? Anthony> There are ways to achieve what you want without Anthony> `AllowAmbiguousTypes` nor `TypeApplications`, but that would need Anthony> a rather different design. So what lead you into this design? Anthony> AntC -- Nadine and Henry Laxen The rest is silence Villa Alta #6 Calle Gaviota #10 Never try to teach a pig to sing Chapala It wastes your time +52 (376) 765-3181 And it annoys the pig From monkleyon at gmail.com Mon Jul 29 12:47:40 2019 From: monkleyon at gmail.com (MarLinn) Date: Mon, 29 Jul 2019 14:47:40 +0200 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family In-Reply-To: <23870.55576.197357.620376@gargle.gargle.HOWL> References: <23870.55576.197357.620376@gargle.gargle.HOWL> Message-ID: <0b502228-becf-79f6-d033-2217900e17ac@gmail.com> Hi Henry, I'm not sure if this is suitable for your use case, but maybe simple multi parameter type classes would be an alternative? Especially because then you could use FunDeps if more dependencies turn up. Like this:     class Game gameState command mutable static | gameState -> mutable,static where         toGameId  :: static    -> GameId         toMutable :: gameState -> IO (Maybe mutable)         everyone  :: mutable   -> [Sink] instance Game Chess ChessCommand ChessMutable ChessStatic where … Admittedly, the type looks a bit long. But maybe more unification is possible to reduce that. Yet another idea is that instead of sprinkling TypeApplications, you could also try a bit of refactoring:     class Game g where       data Command g         :: *        data Mutable g         :: *       data Static  g         :: *       toGameId               :: g -> GameId        toMutable              :: g -> IO (Maybe (Mutable a))       everyone               :: Mutable g -> [Sink]     instance Game Chess where       data Command Chess = MovePiece { movedPiece    :: ChessField, moveTarget :: ChessField }                           | Castling  { withLeftRook  :: Bool }                          | Promote   { promotedPiece :: ChessField, promotedTo :: ChessPiece }                           | EnPassant { enPassantFrom :: ChessField }                           | GiveUp      … -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Tue Jul 30 11:07:34 2019 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Tue, 30 Jul 2019 19:07:34 +0800 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family Message-ID: Anthony> I am interested in how you got into such a pickle in the first place: Anthony> Why set `AllowAmbiguousTypes`? Did you understand what that means? ----------------------^^^^^^^^^^^^^^^^^^^^ >I read > > https://stackoverflow.com/questions/49684655/how-dangerous-is-allowambiguoustypes-when-used-with-typeapplications > > > which seems to indicate that using it is "a perfectly reasonable thing" Hmm, I don't think that's how you got into the pickle. That SO answer (and there are plenty on the subject) says the "combination" of `AllowAmbiguousTypes` + `TypeApplications` is reasonable. But your first post had `AllowAmbiguousTypes` without `TypeApplications`. That is not "a perfectly reasonable thing"; no SO answer says it is. If you had already looked at that SO answer, how did you not use `TypeApplications`? Let me suggest how you got into the pickle, because there is a repeated experience here which is poor for learners: You wrote the method signature for `toBool`. That's ambiguous. GHC gave you an error message suggesting `AllowAmbiguousTypes` might get the method signature to compile -- which it did. `AllowAmbiguousTypes` works at the declaration site, not the usage site. Which is why: * It doesn't make sense to switch it on everywhere -- as one of the SO comments suggests. * It does need you to take action at the usage site, but GHC's message doesn't tell you that. * So your first post showed more `ambiguous` rejections at the usage site. * What's more there was a red herring about non-injective type families. * And to fix it per Li-yao's suggestion needs a whole bunch more extensions, * including the deeply flawed `ScopedTypeVariables`, * when the simpler `PatternSignatures` would be more appropriate -- except that's now deprecated. * `AllowAMbiguousTypes` is module-wide: that means you get no validation of any of your method sigs; although probably you mean only a few of the to be ambiguous. * Then any/every usage site for any method might turn out to be ambiguous. IMO GHC has got itself into a total mess in this bit of the language, and the error messages lead learners rapidly into deep water. I think `AllowAmbiguousTypes` might as well be spelled `AllhopeAbandonTypes`. Those other extensions might be the best approach for your full requirements, but might not. So as to other possible designs: * I didn't want to get into the FunDeps vs TypeFamilies war. * If method `toBool` is only going to be called on the result of `toSubAmbi`, I would go > toBool :: a -> Bool -- not ambiguous > > instance Ambi blah where > type SubAmbi blah = ... > toSubAmbi x = ... > toBool x = case toSubAmbi x of { ... -> True; _ -> False } Then in your `whatsWrong` function, call only `toBool`. So the instances are a little more verbose but the usage sites are more succinct and don't need all those extensions. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadine.and.henry at pobox.com Tue Jul 30 12:19:57 2019 From: nadine.and.henry at pobox.com (Henry Laxen) Date: Tue, 30 Jul 2019 07:19:57 -0500 Subject: [Haskell-cafe] type variable is ambiguous in a non-injective type family In-Reply-To: References: Message-ID: <23872.13805.693450.118585@gargle.gargle.HOWL> Dear Anthony, Yes, you are 100% correct as to how I arrived at my "pickle." I changed my code to reflect your suggestion, and removed a bunch of GHC extensions, and everything is working now. Thanks so much for taking the time to explain everything so clearly. Best wishes, Henry Laxen From raoknz at gmail.com Tue Jul 30 12:22:54 2019 From: raoknz at gmail.com (Richard O'Keefe) Date: Wed, 31 Jul 2019 00:22:54 +1200 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: Message-ID: This is a classic ambiguity in "since". Here it's sort of epistemic: If you know how to do a three way comparison on T then you must know how to test equality on T therefore it is reasonable for anything that implements Ord to implement Eq as well and it would confuse people a lot if <= and >= were allowed but not == so Haskell requires instances of Ord to also be instances of Eq. You are right: data T = A | B instance Ord T where compare A A = EQ compare A B = LT compare B A = GT compare B B = EQ instance Eq T where x == y = compare x y == EQ appears to be legal Haskell. GHC is happy with it and it seems to work. On Mon, 29 Jul 2019 at 03:52, David Fox wrote: > On page 39 you say > > A type can have Ord instance only when it has Eq instance, since if >> you want to compare items, you need a way to test if they are equal. > > > So from my reading of this you are saying that an Eq instance for a type > needs to be supplied before we are allowed to implement compare. However > it is easy to write a compare function that makes no use of the underlying > (==) function. Indeed, once you have done this you can turn around and > write a == b = compare a b == EQ. So I was wondering if you could clarify > the role of constraints in the class declaration. > > On Sun, Jul 28, 2019 at 2:38 AM Cosmia Fu wrote: > >> Hi everyone, >> >> Though some of you might already knows, I'm pleased to announce a new >> Haskell book, >> *To Kata Haskellen Evangelion*. >> Link: https://cosmius.bitbucket.io/tkhe/ >> I believe that it does not have to be hard to learn Haskell. >> >> I begun to write the book in 2017 December, and... to be honest, >> I don't know what to write now, though I still think it incomplete. >> It will probably not be updated for quite a while. >> So I decide to announce it earlier. >> >> I am not a native English speaker, so it might be not fluent or even with >> a lot of grammar mistakes. >> It would be very nice of you if you can tell me the mistakes in it, >> factual, technical or grammar. >> And also feel free to tell me if you want to read some topic in it. >> >> Thank you >> >> ---- >> >> Cosmia Fu >> _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Tue Jul 30 12:28:58 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 30 Jul 2019 08:28:58 -0400 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: Message-ID: But it's hard to specify the "constraint" / completeness condition (see the MINIMAL pragma) of "can be fully expressed via constructors". Note also that this doesn't work for numbers: you can use constructor syntax, but it's desugared to (==). So it's inviting confusion in a number of ways, including some that don't matter directly (you're unlikely to write your own Ord instance for numbers like that) but matter for understanding how the language fits together, which is already confused by e.g. above "sugar". On Tue, Jul 30, 2019 at 8:23 AM Richard O'Keefe wrote: > This is a classic ambiguity in "since". > Here it's sort of epistemic: > If you know how to do a three way comparison on T > then you must know how to test equality on T > therefore it is reasonable for anything that implements Ord to > implement Eq as well > and it would confuse people a lot if <= and >= were allowed but not == > so Haskell requires instances of Ord to also be instances of Eq. > > You are right: > > data T = A | B > > instance Ord T > where compare A A = EQ > compare A B = LT > compare B A = GT > compare B B = EQ > > instance Eq T > where x == y = compare x y == EQ > > appears to be legal Haskell. GHC is happy with it and it seems to work. > > > > On Mon, 29 Jul 2019 at 03:52, David Fox wrote: > >> On page 39 you say >> >> A type can have Ord instance only when it has Eq instance, since if >>> you want to compare items, you need a way to test if they are equal. >> >> >> So from my reading of this you are saying that an Eq instance for a type >> needs to be supplied before we are allowed to implement compare. However >> it is easy to write a compare function that makes no use of the underlying >> (==) function. Indeed, once you have done this you can turn around and >> write a == b = compare a b == EQ. So I was wondering if you could clarify >> the role of constraints in the class declaration. >> >> On Sun, Jul 28, 2019 at 2:38 AM Cosmia Fu wrote: >> >>> Hi everyone, >>> >>> Though some of you might already knows, I'm pleased to announce a new >>> Haskell book, >>> *To Kata Haskellen Evangelion*. >>> Link: https://cosmius.bitbucket.io/tkhe/ >>> I believe that it does not have to be hard to learn Haskell. >>> >>> I begun to write the book in 2017 December, and... to be honest, >>> I don't know what to write now, though I still think it incomplete. >>> It will probably not be updated for quite a while. >>> So I decide to announce it earlier. >>> >>> I am not a native English speaker, so it might be not fluent or even >>> with a lot of grammar mistakes. >>> It would be very nice of you if you can tell me the mistakes in it, >>> factual, technical or grammar. >>> And also feel free to tell me if you want to read some topic in it. >>> >>> Thank you >>> >>> ---- >>> >>> Cosmia Fu >>> _______________________________________________ >>> 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. > > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Tue Jul 30 19:31:03 2019 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Tue, 30 Jul 2019 21:31:03 +0200 (CEST) Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion Message-ID: Isn't the Eq vs Ord problem similar to all sub-classes, e.g. Applicative vs. Monad, Semigroup vs. Monoid, Foldable vs. Traversable? What is the recommended way of coding? The Traversable module for example has default implementations of fmap and foldMap, as Functor and Foldable are superclasses. This suggests it is okay to define the subclass method first and derive the superclass methods from them. But arguments have been put up against this practice in particular cases, e.g. for AMP [1]. Olaf [1] https://mail.haskell.org/pipermail/haskell-cafe/2019-July/131259.html From allbery.b at gmail.com Tue Jul 30 19:35:45 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 30 Jul 2019 15:35:45 -0400 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: Message-ID: Deriving in that way is more of a question of which breaks more code, I think. Or avoiding breaking code vs. purity arguments, which worry me at least somewhat less because that horse left the stable with Haskell 98 twisting Monad out of shape (granting we're trying to fix at least part of it now), if not earlier. And, well, it's a computer language. "Proper purity" not gonna happen in general, unless the result is a useless toy. But Haskell strives to be usable. On Tue, Jul 30, 2019 at 3:31 PM Olaf Klinke wrote: > Isn't the Eq vs Ord problem similar to all sub-classes, e.g. > Applicative vs. Monad, Semigroup vs. Monoid, Foldable vs. Traversable? > What is the recommended way of coding? The Traversable module for example > has default implementations of fmap and foldMap, as Functor and Foldable > are superclasses. This suggests it is okay to define the subclass method > first and derive the superclass methods from them. But arguments have been > put up against this practice in particular cases, e.g. for AMP [1]. > > Olaf > > [1] https://mail.haskell.org/pipermail/haskell-cafe/2019-July/131259.html > > > > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Wed Jul 31 05:21:46 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 31 Jul 2019 07:21:46 +0200 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: Message-ID: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> Am 30.07.19 um 21:35 schrieb Brandon Allbery: > And, well, it's a computer language. "Proper > purity" not gonna happen in general, unless the result is a useless toy. I do not think that the limitations from Haskell's design choices can be generalized to all programming languages in this way. Purity (i.e. no side effects) is easy in strict languages, for example. In a nonstrict language, you'd need a proof of termination to have purity (nontermination is impure). Another approach would be to control impurities. Based on the observation that all code is impure, such as heating the CPU, taking time, increasing CPU counters, and we do not care about these impurities. One could design a language where one could e.g. write a completely impure logger, call it from pure code, and statically determine that these impurities do not affect the pure code. While I think that your pessimism is justified for Haskell where pretty fundamental design choices would have to be reverted, I conclude it is not necessarily justified in the generality stated. Regards, Jo From allbery.b at gmail.com Wed Jul 31 10:15:37 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 31 Jul 2019 06:15:37 -0400 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> Message-ID: I didn't mean purity in the Haskell sense, but the more general technical sense the original message seemed to me to be reaching for. Purity in the Haskell sense is indeed a more limited question. But languages that are useful int he real world need to make tradeoffs, and even Haskell's version of purity includes such (IO is in many ways a wart, but there's going to be a wart *somewhere*). On Wed, Jul 31, 2019 at 1:22 AM Joachim Durchholz wrote: > Am 30.07.19 um 21:35 schrieb Brandon Allbery: > > And, well, it's a computer language. "Proper > > purity" not gonna happen in general, unless the result is a useless toy. > > I do not think that the limitations from Haskell's design choices can be > generalized to all programming languages in this way. > > Purity (i.e. no side effects) is easy in strict languages, for example. > > In a nonstrict language, you'd need a proof of termination to have > purity (nontermination is impure). > > Another approach would be to control impurities. Based on the > observation that all code is impure, such as heating the CPU, taking > time, increasing CPU counters, and we do not care about these > impurities. One could design a language where one could e.g. write a > completely impure logger, call it from pure code, and statically > determine that these impurities do not affect the pure code. > > While I think that your pessimism is justified for Haskell where pretty > fundamental design choices would have to be reverted, I conclude it is > not necessarily justified in the generality stated. > > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosmiafu at gmail.com Wed Jul 31 12:23:16 2019 From: cosmiafu at gmail.com (Cosmia Fu) Date: Wed, 31 Jul 2019 21:23:16 +0900 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> Message-ID: I am not sure what you are talking about, but in the scope of Haskell, even functions or values involving IO are pure if you do not count the unsafeXXX. On Wed, Jul 31, 2019 at 7:15 PM Brandon Allbery wrote: > I didn't mean purity in the Haskell sense, but the more general technical > sense the original message seemed to me to be reaching for. Purity in the > Haskell sense is indeed a more limited question. But languages that are > useful int he real world need to make tradeoffs, and even Haskell's version > of purity includes such (IO is in many ways a wart, but there's going to be > a wart *somewhere*). > > On Wed, Jul 31, 2019 at 1:22 AM Joachim Durchholz > wrote: > >> Am 30.07.19 um 21:35 schrieb Brandon Allbery: >> > And, well, it's a computer language. "Proper >> > purity" not gonna happen in general, unless the result is a useless >> toy. >> >> I do not think that the limitations from Haskell's design choices can be >> generalized to all programming languages in this way. >> >> Purity (i.e. no side effects) is easy in strict languages, for example. >> >> In a nonstrict language, you'd need a proof of termination to have >> purity (nontermination is impure). >> >> Another approach would be to control impurities. Based on the >> observation that all code is impure, such as heating the CPU, taking >> time, increasing CPU counters, and we do not care about these >> impurities. One could design a language where one could e.g. write a >> completely impure logger, call it from pure code, and statically >> determine that these impurities do not affect the pure code. >> >> While I think that your pessimism is justified for Haskell where pretty >> fundamental design choices would have to be reverted, I conclude it is >> not necessarily justified in the generality stated. >> >> 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. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > 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. -- Sent from my iPhone -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.wehr at gmail.com Wed Jul 31 14:35:03 2019 From: stefan.wehr at gmail.com (Stefan Wehr) Date: Wed, 31 Jul 2019 16:35:03 +0200 Subject: [Haskell-cafe] Call for Participation: Summer BOB 2019 (August 21, Berlin) Message-ID: Here's a quick reminder on the upcoming BOB conference, happening at the third day of ICFP at the same venue. For those going to ICFP anyway: your ticket also gives you access to all BOB talks. For those not going to ICFP: come to BOB conference and also get access to the ICFP talks of day 3! ======================================================================== Summer BOB 2019 Conference “What happens if we simply use what’s best?” August 21, 2019, Berlin co-located with ICFP 2019 http://bobkonf.de/2019-summer/ Program: http://bobkonf.de/2019-summer/program.html Registration: http://bobkonf.de/2019-summer/registration.html ======================================================================== Are you interested in technologies beyond the mainstream, that are a pleasure to use, and effective at getting the job done? BOB is the forum for developers, architects and builders to explore and discover the best tools available today for building software. Our goal is for all participants to leave the conference with new ideas to improve development back at the ranch. Summer BOB is a one-time-only event, in the spirit of the spectacular Winter BOB. The International Conference on Functional Programming is coming to town, and Summer BOB will be right in the middle of it, on the last day of ICFP proper, prior to all the workshops. Summer BOB will feature two tracks: one from practitioners, and one from researchers, and foster communication and cross-pollination between these communities. BOB features two tracks of seven talk each: One research track with invited talks, and one track by practitioners, designed to cross-pollinate and inspire.http://bobkonf.de/2019-summer/program.html Topics include distributed programming, testing, linear algebra, functional design patterns, type systems, formal methods, and interactive development. We are committed to diversity: We aim at exploring a wide range of tools in a welcoming and friendly crowd of diverse people. To that end, a number of support options for participants from groups under-represented in tech are available.http://bobkonf.de/2019-summer/registration.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Wed Jul 31 17:54:05 2019 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 31 Jul 2019 19:54:05 +0200 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> Message-ID: <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> Haskell is pretty thorough in terms of purity, but it had its blind spots around nontermination. I believe that some thought has been spent on mitigating the issues, but I also believe that one would have to redesign parts of the language to fully address them. I agree that one should not count the unsafeXXX functions. Am 31.07.19 um 14:23 schrieb Cosmia Fu: > I am not sure what you are talking about, but in the scope of Haskell, > even functions or values involving IO are pure if you do not count the > unsafeXXX. > > On Wed, Jul 31, 2019 at 7:15 PM Brandon Allbery > wrote: > > I didn't mean purity in the Haskell sense, but the more general > technical sense the original message seemed to me to be reaching > for. Purity in the Haskell sense is indeed a more limited question. > But languages that are useful int he real world need to make > tradeoffs, and even Haskell's version of purity includes such (IO is > in many ways a wart, but there's going to be a wart *somewhere*). > > On Wed, Jul 31, 2019 at 1:22 AM Joachim Durchholz > wrote: > > Am 30.07.19 um 21:35 schrieb Brandon Allbery: > > And, well, it's a computer language. "Proper > > purity" not gonna happen in general, unless the result is a > useless toy. > > I do not think that the limitations from Haskell's design > choices can be > generalized to all programming languages in this way. > > Purity (i.e. no side effects) is easy in strict languages, for > example. > > In a nonstrict language, you'd need a proof of termination to have > purity (nontermination is impure). > > Another approach would be to control impurities. Based on the > observation that all code is impure, such as heating the CPU, > taking > time, increasing CPU counters, and we do not care about these > impurities. One could design a language where one could e.g. > write a > completely impure logger, call it from pure code, and statically > determine that these impurities do not affect the pure code. > > While I think that your pessimism is justified for Haskell where > pretty > fundamental design choices would have to be reverted, I conclude > it is > not necessarily justified in the generality stated. > > 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. > > > > -- > brandon s allbery kf8nh > allbery.b at gmail.com > _______________________________________________ > 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. > > -- > Sent from my iPhone From sag.ibrahim at gmail.com Wed Jul 31 18:25:56 2019 From: sag.ibrahim at gmail.com (ibrahim Sagiroglu) Date: Wed, 31 Jul 2019 21:25:56 +0300 Subject: [Haskell-cafe] Request for Comments Message-ID: Hello all, I have an attempt to present llvm assembly in [1]. Would you consider taking some time to comment on it? [1] https://github.com/ibrahimsag/rw -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.dusek at gmail.com Wed Jul 31 19:44:06 2019 From: jason.dusek at gmail.com (Jason Dusek) Date: Wed, 31 Jul 2019 12:44:06 -0700 Subject: [Haskell-cafe] RfA: wcwidth Message-ID: Hi All, This is a Request for Adoption for WCWidth, a low traffic package that provides the functionality of wcwidth(3) : “The wcwidth() function returns the number of columns needed to represent the wide character c.” https://github.com/solidsnack/wcwidth/ Although there have been just 3 issues and 2 PRs in 10 years, that’s still indicative of a need for maintenance and life has drawn me away from these avocations. A contributor suggested I reach out with an RfA. Hopefully, the community can be better served with a new maintainer. Kind Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Wed Jul 31 20:33:53 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 31 Jul 2019 15:33:53 -0500 Subject: [Haskell-cafe] ANN: To Kata Haskellen Evangelion In-Reply-To: <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> Message-ID: I'm not convinced that nontermination would be worth redesigning the language - the research implementations seem rough. (Moreover, one of the advantages of laziness is precisely that one can write a function like take that works on both streams and lists). Cheers, Vanessa On 7/31/19 12:54 PM, Joachim Durchholz wrote: > Haskell is pretty thorough in terms of purity, but it had its blind > spots around nontermination. > I believe that some thought has been spent on mitigating the issues, > but I also believe that one would have to redesign parts of the > language to fully address them. > > I agree that one should not count the unsafeXXX functions. > > Am 31.07.19 um 14:23 schrieb Cosmia Fu: >> I am not sure what you are talking about, but in the scope of >> Haskell, even functions or values involving IO are pure if you do not >> count the unsafeXXX. >> >> On Wed, Jul 31, 2019 at 7:15 PM Brandon Allbery > > wrote: >> >>     I didn't mean purity in the Haskell sense, but the more general >>     technical sense the original message seemed to me to be reaching >>     for. Purity in the Haskell sense is indeed a more limited question. >>     But languages that are useful int he real world need to make >>     tradeoffs, and even Haskell's version of purity includes such (IO is >>     in many ways a wart, but there's going to be a wart *somewhere*). >> >>     On Wed, Jul 31, 2019 at 1:22 AM Joachim Durchholz >     > wrote: >> >>         Am 30.07.19 um 21:35 schrieb Brandon Allbery: >>          > And, well, it's a computer language. "Proper >>          > purity" not gonna happen in general, unless the result is a >>         useless toy. >> >>         I do not think that the limitations from Haskell's design >>         choices can be >>         generalized to all programming languages in this way. >> >>         Purity (i.e. no side effects) is easy in strict languages, for >>         example. >> >>         In a nonstrict language, you'd need a proof of termination to >> have >>         purity (nontermination is impure). >> >>         Another approach would be to control impurities. Based on the >>         observation that all code is impure, such as heating the CPU, >>         taking >>         time, increasing CPU counters, and we do not care about these >>         impurities. One could design a language where one could e.g. >>         write a >>         completely impure logger, call it from pure code, and statically >>         determine that these impurities do not affect the pure code. >> >>         While I think that your pessimism is justified for Haskell where >>         pretty >>         fundamental design choices would have to be reverted, I conclude >>         it is >>         not necessarily justified in the generality stated. >> >>         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. >> >> >> >>     --     brandon s allbery kf8nh >>     allbery.b at gmail.com >>     _______________________________________________ >>     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. >> >> --  >> Sent from my iPhone > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From raould at gmail.com Wed Jul 31 20:41:10 2019 From: raould at gmail.com (Raoul Duke) Date: Wed, 31 Jul 2019 13:41:10 -0700 Subject: [Haskell-cafe] lazy evangelion In-Reply-To: References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> Message-ID: > > > (Moreover, one of the advantages of laziness is precisely that one can > write a function like take that works on both streams and lists). > > surely that’s not the only way to get such polymorphism in our programming systems? the “precisely” word there makes it sound to me like people think it is better than any alternative specifically for this use case? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Jul 31 21:02:34 2019 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 31 Jul 2019 17:02:34 -0400 Subject: [Haskell-cafe] lazy evangelion In-Reply-To: References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> Message-ID: For one, there's ad-hoc overloading, including typeclasses, but those kinds of solutions have their own drawbacks. On Wed, Jul 31, 2019 at 4:41 PM Raoul Duke wrote: > > (Moreover, one of the advantages of laziness is precisely that one can >> write a function like take that works on both streams and lists). >> >> surely that’s not the only way to get such polymorphism in our > programming systems? the “precisely” word there makes it sound to me like > people think it is better than any alternative specifically for this use > case? > _______________________________________________ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vamchale at gmail.com Wed Jul 31 21:36:53 2019 From: vamchale at gmail.com (Vanessa McHale) Date: Wed, 31 Jul 2019 16:36:53 -0500 Subject: [Haskell-cafe] lazy evangelion In-Reply-To: References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> Message-ID: Well, I am not aware of any - I don't think I can rule them out a priori. Cheers, Vanessa McHale On 7/31/19 3:41 PM, Raoul Duke wrote: > > > (Moreover, one of the advantages of laziness is precisely that > one can > write a function like take that works on both streams and lists). > > surely that’s not the only way to get such polymorphism in our > programming systems? the “precisely” word there makes it sound to me > like people think it is better than any alternative specifically for > this use case? > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From raould at gmail.com Wed Jul 31 21:43:54 2019 From: raould at gmail.com (Raoul Duke) Date: Wed, 31 Jul 2019 14:43:54 -0700 Subject: [Haskell-cafe] lazy evangelion In-Reply-To: References: <72ad2c39-ee1f-6456-8434-2f06c563e5ca@durchholz.org> <3ae44439-31a1-d702-a914-699593b42621@durchholz.org> Message-ID: eg https://docs.oracle.com/javase/7/docs/api/java/util/Iterator.html mayhaps? On Wed, Jul 31, 2019 at 14:37 Vanessa McHale wrote: > Well, I am not aware of any - I don't think I can rule them out a priori. > > Cheers, > Vanessa McHale > On 7/31/19 3:41 PM, Raoul Duke wrote: > > > (Moreover, one of the advantages of laziness is precisely that one can >> write a function like take that works on both streams and lists). >> >> surely that’s not the only way to get such polymorphism in our > programming systems? the “precisely” word there makes it sound to me like > people think it is better than any alternative specifically for this use > case? > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: