From 8hjkl8 at gmail.com Sun Aug 1 12:49:54 2021 From: 8hjkl8 at gmail.com (Kim Chaegon) Date: Sun, 1 Aug 2021 21:49:54 +0900 Subject: [Haskell-cafe] I want to read documents about haskell. Message-ID: I want read documents about haskell, pure functional language. Rgank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Sun Aug 1 13:13:03 2021 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 1 Aug 2021 15:13:03 +0200 Subject: [Haskell-cafe] I want to read documents about haskell. In-Reply-To: References: Message-ID: <20210801131303.GA32240@extensa> Hello Kim, Il 01 agosto 2021 alle 21:49 Kim Chaegon ha scritto: > I want read documents about haskell, pure functional language. Rgank you! Plenty of docs on https://www.haskell.org/documentation/ , see if you find something you like! —F From spam at scientician.net Sun Aug 1 21:07:13 2021 From: spam at scientician.net (Bardur Arantsson) Date: Sun, 1 Aug 2021 23:07:13 +0200 Subject: [Haskell-cafe] Sets, typeclasses and functional dependencies In-Reply-To: <5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de> References: <5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de> Message-ID: On 31/07/2021 11.14, Henning Thielemann wrote: > > A more modern approach would use type functions: > > class Setish set where >   type Element set >   empty :: set >   singleton :: Element set -> set > Just to add: This would be an "extensional" set, i.e one specified explicitly by its elements. But there are also "intensional" sets which are defined by some sort of mathematical property that holds for its elements. Naturally, the operations that make sense for either of those is *very* different. From borgauf at gmail.com Sun Aug 1 22:12:25 2021 From: borgauf at gmail.com (Galaxy Being) Date: Sun, 1 Aug 2021 17:12:25 -0500 Subject: [Haskell-cafe] Explanation of Data.Set, please Message-ID: I'm looking at this code and wondering, first, about the strategy behind the data type Set itself data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip It says it's a "balanced tree." I found this talking about maybe why that is. Will read. But in the meantime, any explanation in plain English as to why we're doing it as a tree and not some other structure would be helpful. And why are we bringing Size along, and in general, why all the strictness !'s? All this might have something to do with why a balanced tree is better than quick-and-dirty list representation like I see in beginner tutorials? Next, is this ZFC? I've seen treatments that supposedly are ZFC-friendly. Finally, I've taken a preliminary look at Agda, and right from the start there's Set, and no doubt an entirely alternative, category universe approach to the concept of set theory. Any contrast and compare between Haskell and Agda's set notions would be appreciated. Haskell seems to dance in and out of Category Theory, while Agda seems pretty much just CT.... -- ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From migmit at gmail.com Sun Aug 1 22:19:07 2021 From: migmit at gmail.com (MigMit) Date: Mon, 2 Aug 2021 00:19:07 +0200 Subject: [Haskell-cafe] Explanation of Data.Set, please In-Reply-To: References: Message-ID: What is called "Set" in Prelude is not "set" in a set-theoretic meaning. It is a finite set. Not sure what you mean by "ZFC-friendly", since it is not a "concept of set theory" at all. It is represented that way for efficiency; balanced trees generally guarantee O(log n) performance, while a list would give you O(n). > On 2 Aug 2021, at 00:12, Galaxy Being wrote: > > I'm looking at this code and wondering, first, about the strategy behind the data type Set itself > > data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip > > It says it's a "balanced tree." I found this talking about maybe why that is. Will read. But in the meantime, any explanation in plain English as to why we're doing it as a tree and not some other structure would be helpful. And why are we bringing Size along, and in general, why all the strictness !'s? All this might have something to do with why a balanced tree is better than quick-and-dirty list representation like I see in beginner tutorials? Next, is this ZFC? I've seen treatments that supposedly are ZFC-friendly. Finally, I've taken a preliminary look at Agda, and right from the start there's Set, and no doubt an entirely alternative, category universe approach to the concept of set theory. Any contrast and compare between Haskell and Agda's set notions would be appreciated. Haskell seems to dance in and out of Category Theory, while Agda seems pretty much just CT.... > > -- > ⨽ > Lawrence Bottorff > Grand Marais, MN, USA > borgauf 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. From ruben.astud at gmail.com Mon Aug 2 01:20:09 2021 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Sun, 1 Aug 2021 21:20:09 -0400 Subject: [Haskell-cafe] Explanation of Data.Set, please In-Reply-To: References: Message-ID: You are asking too much from Data.Set. This module is capturing the notion of a *finite* collection of elements. It deals with a data structure view of set, where you want to use have good performance for the following operations. - lookup - insertion (no duplicate elements) - removal - cardinality - union / intersection The needs of the previous function guided the bang patterns/UNPACK on the definition of the data structure and the use of a balanced tree. -- -- Rubén. pgp: 4EE9 28F7 932E F4AD On 01-08-21 18:12, Galaxy Being wrote: > I'm looking at this > > code and wondering, first, about the strategy behind the data type Set > itself > > data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip > > It says it's a "balanced tree." I found this > talking about > maybe why that is. Will read. But in the meantime, any explanation in plain > English as to why we're doing it as a tree and not some other structure > would be helpful. And why are we bringing Size along, and in general, why > all the strictness !'s? All this might have something to do with why a > balanced tree is better than quick-and-dirty list representation like I see > in beginner tutorials? Next, is this ZFC? I've seen treatments that > supposedly are ZFC-friendly. Finally, I've taken a preliminary look at > Agda, and right from the start there's Set, and no doubt an entirely > alternative, category universe approach to the concept of set theory. Any > contrast and compare between Haskell and Agda's set notions would be > appreciated. Haskell seems to dance in and out of Category Theory, while > Agda seems pretty much just CT.... > > > _______________________________________________ > 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 raoknz at gmail.com Mon Aug 2 02:29:11 2021 From: raoknz at gmail.com (Richard O'Keefe) Date: Mon, 2 Aug 2021 14:29:11 +1200 Subject: [Haskell-cafe] Sets, typeclasses and functional dependencies In-Reply-To: References: <5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de> Message-ID: The thing about powerset is that it is great for reasoning and as a starting point for a derivation, but horrible as a data structure. Power sets get very big very fast, and even in a lazy language, where you might not store an entire powerset, traversing one takes a lot of time. So it's seldom included in practical finite set implementations. On Sat, 31 Jul 2021 at 22:15, Stuart Hungerford wrote: > > On Sat, Jul 31, 2021 at 7:14 PM Henning Thielemann > wrote: > > > [...] > > A more modern approach would use type functions: > > > > class Setish set where > > type Element set > > empty :: set > > singleton :: Element set -> set > > Thanks for the pointer. > > > > My question is how does the functional dependency in Setish interact > > > with "extra" types needed for richer set operations like finding the > > > powerset or taking a cartesian product? > > > > powerset would need a type like: > > > > powerset :: > > (Powersettish powerset, Element powerset ~ set, Setish set) => > > set -> powerset > > > > with an extra Powersettish class. > > > > However, the type checker could not guess the exact powerset type, it > > could be, e.g. > > powerset :: Set a -> Set (Set a) > > or > > powerset :: Set a -> [Set a] > > Okay, I'm starting to see why the "Set" typeclass examples I could > find don't include a powerset or cartesian product method. > > Thanks again, > > Stu > _______________________________________________ > 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 stuart.hungerford at gmail.com Mon Aug 2 08:47:14 2021 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Mon, 2 Aug 2021 18:47:14 +1000 Subject: [Haskell-cafe] Sets, typeclasses and functional dependencies In-Reply-To: References: <5982b2a2-c5d1-b2ef-8b32-d9d691c1fb75@henning-thielemann.de> Message-ID: On Mon, Aug 2, 2021 at 12:29 PM Richard O'Keefe wrote: > The thing about powerset is that it is great for reasoning and as a > starting point > for a derivation, but horrible as a data structure. Power sets get > very big very > fast, and even in a lazy language, where you might not store an entire powerset, > traversing one takes a lot of time. So it's seldom included in > practical finite set > implementations. Very true, although there's something neat about being able to generate 2^{some set}. I'm mainly interested in doing the exercises in the "Haskell Road to Logic and Mathematics" with some added exploration, e.g. a Set typeclass. Stu From hecate at glitchbra.in Mon Aug 2 21:52:52 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Mon, 2 Aug 2021 23:52:52 +0200 Subject: [Haskell-cafe] base64-bytestring memory corruption bug In-Reply-To: References: Message-ID: Hi Fraser, do you have further information about this situation? Le 25/07/2021 à 07:50, Fraser Tweedale a écrit : > Hello, > > I want to bring to wider attention a memory bug present in > base64-bytestring[1]. In summary, in some cases too few bytes are > allocated for the output when performing base64url decoding. This > can lead to memory corruption (which I have observed[2]), and > possibly crashes (which I have not observed). > > I submitted a pull request[2] that fixes the issue some days ago, > but did not receive a response from the maintainers yet. I > understand that maintainers may be busy or unavailable, and that is > fine. So I am posting here mainly to ensure that USERS are aware of > the issue. > > To maintainers: let me know if I can provider further assistance to > resolve this issue and release a fix. > > [1] https://github.com/haskell/base64-bytestring/issues/44 > [2] https://github.com/frasertweedale/hs-jose/issues/102 > [3] https://github.com/haskell/base64-bytestring/pull/45 > > Thanks, > Fraser > _______________________________________________ > 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From frase at frase.id.au Tue Aug 3 03:40:26 2021 From: frase at frase.id.au (Fraser Tweedale) Date: Tue, 3 Aug 2021 13:40:26 +1000 Subject: [Haskell-cafe] base64-bytestring memory corruption bug In-Reply-To: References: Message-ID: A new proposed fix is being discussed in https://github.com/haskell/base64-bytestring/pull/46. Expect a fix merged and new release sometime in the next few days. Big thanks to all involved in pinpointing and resolving this issue. Cheers, Fraser On Mon, Aug 02, 2021 at 11:52:52PM +0200, Hécate wrote: > Hi Fraser, do you have further information about this situation? > > Le 25/07/2021 à 07:50, Fraser Tweedale a écrit : > > Hello, > > > > I want to bring to wider attention a memory bug present in > > base64-bytestring[1]. In summary, in some cases too few bytes are > > allocated for the output when performing base64url decoding. This > > can lead to memory corruption (which I have observed[2]), and > > possibly crashes (which I have not observed). > > > > I submitted a pull request[2] that fixes the issue some days ago, > > but did not receive a response from the maintainers yet. I > > understand that maintainers may be busy or unavailable, and that is > > fine. So I am posting here mainly to ensure that USERS are aware of > > the issue. > > > > To maintainers: let me know if I can provider further assistance to > > resolve this issue and release a fix. > > > > [1] https://github.com/haskell/base64-bytestring/issues/44 > > [2] https://github.com/frasertweedale/hs-jose/issues/102 > > [3] https://github.com/haskell/base64-bytestring/pull/45 > > > > Thanks, > > Fraser > > _______________________________________________ > > 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. > > -- > Hécate ✨ > 🐦: @TechnoEmpress > IRC: Hecate > WWW: https://glitchbra.in > RUN: BSD > > _______________________________________________ > 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 compl.yue at icloud.com Tue Aug 3 09:19:32 2021 From: compl.yue at icloud.com (YueCompl) Date: Tue, 3 Aug 2021 17:19:32 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? Message-ID: <1CB723C2-A8AE-4E10-BCD1-08B6D202B2A1@icloud.com> Dear Cafe, I kinda understand the [Floating](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:Floating ) class doesn't care about NaN, as not expecting all floating point implementations to have such semantics. But [IEEE Silent NaN](https://en.wikipedia.org/wiki/NaN#Quiet_NaN ) has become a norm today, I think it deserves more than mere [isNaN](https://hackage.haskell.org/package/base/docs/GHC-Float.html#v:isNaN ) in the [RealFloat](https://hackage.haskell.org/package/base/docs/GHC-Float.html#t:RealFloat ) class. While [Signaling NaN](https://en.wikipedia.org/wiki/NaN#Signaling_NaN ) can be an `Exception` triggering bottom like "divide by zero" is, the silent `NaN` feels like a different kind of bottom, or some thing similar to `Nothing` as in the `Num a => Maybe a` monad? Is Haskell's type system capable of encoding silent NaN as a special kind/type of bottom that handleable? Though I don't think I've gained correct understanding at all, on "bottom"s, I'm interested in what options we have to encode them, especially ergonomics ways to handle them accordingly. Best regards, Compl -------------- next part -------------- An HTML attachment was scrubbed... URL: From jarnold at sydrom.com Tue Aug 3 16:45:44 2021 From: jarnold at sydrom.com (John Arnold) Date: Tue, 3 Aug 2021 12:45:44 -0400 Subject: [Haskell-cafe] Parsing XML Message-ID: I am building a prototype for processing ISO 20022 Payment Initiation messages. These messages are in XML format and I want the prototype to be built using Haskell. Conducting a search for 'Haskell XML parsing' yields postings that are in the region of 10+yrs old. I am sure there are packages that have been developed/update in the recent past. Any thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thedward at barsoom.net Tue Aug 3 18:03:37 2021 From: thedward at barsoom.net (Thedward Blevins) Date: Tue, 3 Aug 2021 13:03:37 -0500 Subject: [Haskell-cafe] Parsing XML In-Reply-To: References: Message-ID: Did you try looking on Hackage ? After just a quick search I found these: - xml-parser - xml-conduit - hxt - xml On Tue, Aug 3, 2021 at 11:46 AM John Arnold wrote: > I am building a prototype for processing ISO 20022 Payment Initiation > messages. These messages are in XML format and I want the prototype to be > built using Haskell. > > Conducting a search for 'Haskell XML parsing' yields postings that are in > the region of 10+yrs old. > > I am sure there are packages that have been developed/update in the recent > past. > Any thoughts? > _______________________________________________ > 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 hecate at glitchbra.in Tue Aug 3 20:44:27 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Tue, 3 Aug 2021 22:44:27 +0200 Subject: [Haskell-cafe] base64-bytestring memory corruption bug In-Reply-To: References: Message-ID: <9e5d736f-b40b-601a-c174-94b4f663941a@glitchbra.in> Wonderful, happy to know it's been resolved! Le 03/08/2021 à 05:40, Fraser Tweedale a écrit : > A new proposed fix is being discussed in > https://github.com/haskell/base64-bytestring/pull/46. > > Expect a fix merged and new release sometime in the next few days. > > Big thanks to all involved in pinpointing and resolving this issue. > > Cheers, > Fraser > > On Mon, Aug 02, 2021 at 11:52:52PM +0200, Hécate wrote: >> Hi Fraser, do you have further information about this situation? >> >> Le 25/07/2021 à 07:50, Fraser Tweedale a écrit : >>> Hello, >>> >>> I want to bring to wider attention a memory bug present in >>> base64-bytestring[1]. In summary, in some cases too few bytes are >>> allocated for the output when performing base64url decoding. This >>> can lead to memory corruption (which I have observed[2]), and >>> possibly crashes (which I have not observed). >>> >>> I submitted a pull request[2] that fixes the issue some days ago, >>> but did not receive a response from the maintainers yet. I >>> understand that maintainers may be busy or unavailable, and that is >>> fine. So I am posting here mainly to ensure that USERS are aware of >>> the issue. >>> >>> To maintainers: let me know if I can provider further assistance to >>> resolve this issue and release a fix. >>> >>> [1] https://github.com/haskell/base64-bytestring/issues/44 >>> [2] https://github.com/frasertweedale/hs-jose/issues/102 >>> [3] https://github.com/haskell/base64-bytestring/pull/45 >>> >>> Thanks, >>> Fraser >>> _______________________________________________ >>> 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. >> -- >> Hécate ✨ >> 🐦: @TechnoEmpress >> IRC: Hecate >> WWW: https://glitchbra.in >> RUN: BSD >> >> _______________________________________________ >> 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From ruben.astud at gmail.com Tue Aug 3 21:46:46 2021 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Tue, 3 Aug 2021 17:46:46 -0400 Subject: [Haskell-cafe] Parsing XML In-Reply-To: References: Message-ID: Hello. On 03-08-21 12:45, John Arnold wrote: > Conducting a search for 'Haskell XML parsing' yields postings that are in > the region of 10+yrs old. I think that has more to do with the general xml popularity. People aren't writing XML tutorial in haskell anymore. Now if you look at the json parsing tutorial... > I am sure there are packages that have been developed/update in the recent > past. > Any thoughts? The go to option was and is `hxt` [1]. It's a little bit on the huge size, but it should have the biggest use on the ecosystem [2]. There are probably newer options now that use lenses if you are on that sort of thing, but I don't know them. Good luck. Rubén. pgp: 4EE9 28F7 932E F4AD [1]: https://hackage.haskell.org/package/hxt [2]: https://packdeps.haskellers.com/reverse/hxt On 03-08-21 12:45, John Arnold wrote: > I am building a prototype for processing ISO 20022 Payment Initiation > messages. These messages are in XML format and I want the prototype to be > built using Haskell. > > Conducting a search for 'Haskell XML parsing' yields postings that are in > the region of 10+yrs old. > > I am sure there are packages that have been developed/update in the recent > past. > Any thoughts? > -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From magnus at therning.org Wed Aug 4 06:33:31 2021 From: magnus at therning.org (Magnus Therning) Date: Wed, 04 Aug 2021 08:33:31 +0200 Subject: [Haskell-cafe] Parsing XML In-Reply-To: References: Message-ID: <87bl6dpvg2.fsf@therning.org> Thedward Blevins writes: > Did you try looking on Hackage? > > After just a quick search I found these: > > * xml-parser > * xml-conduit > * hxt > * xml The code we have at work related to PAIN.001.001.03 is using the following libs related to XML: - xml-hamlet - xml-conduit - xml-conduit-writer /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus at therning.org @magthe at mastodon.technology http://magnus.therning.org/ You can't depend on your judgement when your imagination is out of focus. — Mark Twain -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 861 bytes Desc: not available URL: From stuart.hungerford at gmail.com Wed Aug 4 06:50:21 2021 From: stuart.hungerford at gmail.com (Stuart Hungerford) Date: Wed, 4 Aug 2021 16:50:21 +1000 Subject: [Haskell-cafe] GHC 9.x on M1 mac? Message-ID: Hi Haskellers, Has anyone been able to build a 9.x series GHC installation for the M1 mac with macOS, in native binary form (i.e. not under Rosetta translation)? TIA, Stu From lemming at henning-thielemann.de Wed Aug 4 07:46:34 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 4 Aug 2021 09:46:34 +0200 (CEST) Subject: [Haskell-cafe] Parsing XML In-Reply-To: <87bl6dpvg2.fsf@therning.org> References: <87bl6dpvg2.fsf@therning.org> Message-ID: <81854da8-dbd5-b954-8b54-4abeea3c2c9@henning-thielemann.de> On Wed, 4 Aug 2021, Magnus Therning wrote: > Thedward Blevins writes: > >> Did you try looking on Hackage? >> >> After just a quick search I found these: >> >> * xml-parser >> * xml-conduit >> * hxt >> * xml > > The code we have at work related to PAIN.001.001.03 is using the following > libs related to XML: > > - xml-hamlet > - xml-conduit > - xml-conduit-writer * xeno * HaXml * xml-basic * tagchup * wraxml From mgajda at mimuw.edu.pl Wed Aug 4 13:08:08 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Wed, 4 Aug 2021 15:08:08 +0200 Subject: [Haskell-cafe] Parsing XML Message-ID: Dear John, I recommend Xeno: https://gitlab.com/migamake/xeno It was released on Hackage some time ago by Chris Done, then maintained by Marco Zocca. It was benchmarked against fastest parsers in both Haskell and other languages: * https://arxiv.org/abs/2011.03536 * http://neilmitchell.blogspot.com/2016/12/new-xml-parser-hexml.html It allows you to use SAX and DOM-style processing. It has an awesome memory efficiency that is surpassed only by PugiXML parser (which builds DOM in place, but occasionally crashes). It does not support some XML features (namespaces, entity normalization etc.), but these can be added as postprocessing after the DOM is built. It is maintained. And there is a yet unreleased version that can be used to parse HTML documents and documents that are not well formed. Disclosure: I am current maintainer. -- Cheers Michał J. Gajda From mgajda at mimuw.edu.pl Wed Aug 4 13:11:05 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Wed, 4 Aug 2021 15:11:05 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? Message-ID: Dear Yue, Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. The problem with this approach is indeed a silent handling. But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. -- Cheers Michał From compl.yue at icloud.com Wed Aug 4 14:00:07 2021 From: compl.yue at icloud.com (YueCompl) Date: Wed, 4 Aug 2021 22:00:07 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: Thanks Michał, I feel less confused as I realized the non-halting possibility per bottoms, from your hint. I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? No such family of `Num` classes exists to my aware by now, I just can't help wondering why. Cheers, Compl > On 2021-08-04, at 02:38, Michał J Gajda wrote: > > Dear Yue, > > Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! > > Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. > > Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. > > The problem with this approach is indeed a silent handling. > > But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > > Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. > -- > Cheers > Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgajda at mimuw.edu.pl Wed Aug 4 14:24:31 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Wed, 4 Aug 2021 16:24:31 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: The infamous `NaN /= NaN` makes only sense for `NaN` originating as a result, since we cannot compare `NaN`s originating from different computations. But it breaks `Eq` instance laws as needed for property tests. That is why comparison on `NaN` is better handled by `isFinite`, `isANumber` predicates. Note that beside `NaN` we also have other anomalous values, like Underflow, Overflow, +inf and -inf. These are all error values, and can hardly be treated in any other way. And they all need to be handled for floating points. Yes, comparing `NaN` with anything should give a rise to another error value. That means that the only way out is making Either Error Float, and then `(>=) :: Either Error Float -> Either Error Float -> Either Error Bool` So basically we need to lift all `Num` operations to the `Either Error` Monad. That is probably best way to fix the problem: once error value appears, we need to treat it consistently throughout entire computation. At the same time, we do not want a single error value to dominate entire computation, so that is why we treat collections of computations as computations that give a collection of good results and a collection of errors separately. If we take this into consideration, we notice that most interesting computations occur on collections of values, and thus yield a collection of results, not just a single output. That is one takeaway from the referenced presentation on data analytics in Haskell. (Similar presentation was also well received on Data Science Europe. It should be on YouTube by now.) Example of a 3D rotation is instructive: if NaN appears for any single coordinate, we can get a useful results for all other coordinates, and thus narrow impact of an error. If the next step is projection on X-Y coordinates, then NaN or Over/Under-flow within Z does not affect the result. To my understanding, that is also the reason why IEEE mandated special treatment of error values: most of the computations happen on large matrices, vectors etc, and crashing for each single NaN would be a true disaster. It can be even ignored, when the NaN is computed for an energy component within a single frame of long-running simulation, and the error disappears within a single time step. -- Cheers Michał On Wed, Aug 4, 2021 at 4:00 PM YueCompl wrote: > > Thanks Michał, > > I feel less confused as I realized the non-halting possibility per bottoms, from your hint. > > I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. > > Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > > > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. > > > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity > > > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. > > So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? > > No such family of `Num` classes exists to my aware by now, I just can't help wondering why. > > Cheers, > Compl > > On 2021-08-04, at 02:38, Michał J Gajda wrote: > > Dear Yue, > > Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! > > Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. > > Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. > > The problem with this approach is indeed a silent handling. > > But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > > Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. > -- > Cheers > Michał > > -- Pozdrawiam Michał From compl.yue at icloud.com Wed Aug 4 14:56:14 2021 From: compl.yue at icloud.com (YueCompl) Date: Wed, 4 Aug 2021 22:56:14 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: <85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com> `Eq` relies on the established `Bool` type, then can we solve it, if given algebraic effects & handlers, by Church-encoding an effectful Boolean type? e.g. true === \a b -> a false === \a b -> b cmpWithNaN === \a b -> perform ComparingWithNaN Then (==) and (/=) in `Eq`, together with friends in `Ord` like (>) (<) all return `cmpWithNaN` when at least one NaN is involved. This mechanism is open so all kinds of anomalies can be handled similarly, otherwise even we have all NaN, Inf, Underflow, Overflow etc. handled well, there must be more situations we haven't thought of. > On 2021-08-04, at 22:24, Michal J Gajda wrote: > > The infamous `NaN /= NaN` makes only sense for `NaN` originating as a > result, since we cannot compare `NaN`s originating from different > computations. > But it breaks `Eq` instance laws as needed for property tests. > That is why comparison on `NaN` is better handled by `isFinite`, > `isANumber` predicates. > Note that beside `NaN` we also have other anomalous values, like > Underflow, Overflow, +inf and -inf. > These are all error values, and can hardly be treated in any other way. > And they all need to be handled for floating points. > > Yes, comparing `NaN` with anything should give a rise to another error value. > That means that the only way out is making Either Error Float, and > then `(>=) :: Either Error Float -> Either Error Float -> Either Error > Bool` > So basically we need to lift all `Num` operations to the `Either Error` Monad. > > That is probably best way to fix the problem: once error value > appears, we need to treat it consistently throughout entire > computation. > At the same time, we do not want a single error value to dominate > entire computation, so that is why we treat collections of > computations as computations that give a collection of good results > and a collection of errors separately. > If we take this into consideration, we notice that most interesting > computations occur on collections of values, and thus yield a > collection of results, not just a single output. > > That is one takeaway from the referenced presentation on data > analytics in Haskell. (Similar presentation was also well received on > Data Science Europe. It should be on YouTube by now.) > > Example of a 3D rotation is instructive: if NaN appears for any single > coordinate, we can get a useful results for all other coordinates, and > thus narrow impact of an error. > If the next step is projection on X-Y coordinates, then NaN or > Over/Under-flow within Z does not affect the result. > > To my understanding, that is also the reason why IEEE mandated special > treatment of error values: most of the computations happen on large > matrices, vectors etc, and crashing for each single NaN would be a > true disaster. > It can be even ignored, when the NaN is computed for an energy > component within a single frame of long-running simulation, and the > error disappears within a single time step. > -- > Cheers > Michał > > On Wed, Aug 4, 2021 at 4:00 PM YueCompl > wrote: >> >> Thanks Michał, >> >> I feel less confused as I realized the non-halting possibility per bottoms, from your hint. >> >> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. >> >> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs >> >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. >> >>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity >> >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. >> >> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: >> >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? >> >> No such family of `Num` classes exists to my aware by now, I just can't help wondering why. >> >> Cheers, >> Compl >> >> On 2021-08-04, at 02:38, Michał J Gajda wrote: >> >> Dear Yue, >> >> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! >> >> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. >> >> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. >> >> The problem with this approach is indeed a silent handling. >> >> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding >> >> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. >> -- >> Cheers >> Michał >> >> > > > -- > Pozdrawiam > Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgajda at mimuw.edu.pl Thu Aug 5 03:51:10 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Thu, 5 Aug 2021 05:51:10 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: <85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com> References: <85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com> Message-ID: Yue, Yes, it seems it would work This useful workaround works uses exception effect. So it may have two disadvantages: 1. You may only catch the effect in a monad that can catch exceptions, like IO. 2. It does not give a clear path for handling collections of computations. Note that DSLs also need to redefine Eq as effectful class. Then `(==) :: Applicative expr => expr a -> expr a -> expr bool`. This solution may be preferred if You have: * a DSL already * additional metadata attached to values, like provenance, security access level, versioning, Merkle hash, memo hash, equivalence class etc. * want to handle error values without exposing Yourself to imprecise exceptions etc. It has disadvantage of redefining several standard classes, and we do not yet seem to have a library that would properly provide these type classes parameterized over any Applicative. But again, the need for more principled handling of error values will likely come as software scales. — Best regards Michał On Wed, 4 Aug 2021 at 16:56 YueCompl wrote: > `Eq` relies on the established `Bool` type, then can we solve it, if given > algebraic effects & handlers, by Church-encoding an effectful Boolean type? > e.g. > > true === \a b -> a > false === \a b -> b > cmpWithNaN === \a b -> perform ComparingWithNaN > > Then (==) and (/=) in `Eq`, together with friends in `Ord` like (>) (<) > all return `cmpWithNaN` when at least one NaN is involved. > > This mechanism is open so all kinds of anomalies can be handled similarly, > otherwise even we have all NaN, Inf, Underflow, Overflow etc. handled well, > there must be more situations we haven't thought of. > > > On 2021-08-04, at 22:24, Michal J Gajda wrote: > > The infamous `NaN /= NaN` makes only sense for `NaN` originating as a > result, since we cannot compare `NaN`s originating from different > computations. > But it breaks `Eq` instance laws as needed for property tests. > That is why comparison on `NaN` is better handled by `isFinite`, > `isANumber` predicates. > Note that beside `NaN` we also have other anomalous values, like > Underflow, Overflow, +inf and -inf. > These are all error values, and can hardly be treated in any other way. > And they all need to be handled for floating points. > > Yes, comparing `NaN` with anything should give a rise to another error > value. > That means that the only way out is making Either Error Float, and > then `(>=) :: Either Error Float -> Either Error Float -> Either Error > Bool` > So basically we need to lift all `Num` operations to the `Either Error` > Monad. > > That is probably best way to fix the problem: once error value > appears, we need to treat it consistently throughout entire > computation. > At the same time, we do not want a single error value to dominate > entire computation, so that is why we treat collections of > computations as computations that give a collection of good results > and a collection of errors separately. > If we take this into consideration, we notice that most interesting > computations occur on collections of values, and thus yield a > collection of results, not just a single output. > > That is one takeaway from the referenced presentation on data > analytics in Haskell. (Similar presentation was also well received on > Data Science Europe. It should be on YouTube by now.) > > Example of a 3D rotation is instructive: if NaN appears for any single > coordinate, we can get a useful results for all other coordinates, and > thus narrow impact of an error. > If the next step is projection on X-Y coordinates, then NaN or > Over/Under-flow within Z does not affect the result. > > To my understanding, that is also the reason why IEEE mandated special > treatment of error values: most of the computations happen on large > matrices, vectors etc, and crashing for each single NaN would be a > true disaster. > It can be even ignored, when the NaN is computed for an energy > component within a single frame of long-running simulation, and the > error disappears within a single time step. > -- > Cheers > Michał > > On Wed, Aug 4, 2021 at 4:00 PM YueCompl wrote: > > > Thanks Michał, > > I feel less confused as I realized the non-halting possibility per > bottoms, from your hint. > > I too think the signaling NaN is dreadful enough, so fortunately it's > rarely seen nowadays. > > Actually what's on my mind was roughly something like "Maybe on steroids", > I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at > https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > > Note that due to the presence of @NaN@, not all elements of 'Float' have > an additive inverse. > > > Also note that due to the presence of -0, Float's 'Num' instance doesn't > have an additive identity > > > Note that due to the presence of @NaN@, not all elements of 'Float' have > an multiplicative inverse. > > > So it should have been another family of `Num` classes, within which, > various NaN related semantics can be legal, amongst which I'd think: > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems > quite acceptable > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or > not? > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a > theoretical framework for this to hold? Maybe `Boolean` type needs > enhancement too to do it? > > No such family of `Num` classes exists to my aware by now, I just can't > help wondering why. > > Cheers, > Compl > > On 2021-08-04, at 02:38, Michał J Gajda wrote: > > Dear Yue, > > Bottom has much weaker semantics than an exception: it means You may never > get a result and thus will never handle it! > > Another reason is convenience: it is frequently the case that giving NaN > in a row of numbers is much more informative than crashing a program with > an exception and never printing the result anyway. > > Finally IEEE special values have clear propagation semantics: they are > basically Maybe on steroids. > > The problem with this approach is indeed a silent handling. > > But in order to fix this, it is better to add preconditions to specific > algorithms that do not allow IEEE special value on input (`isFinite` or > `isNotNaN`) and then track the origin of the special value with the methods > like those described here: > https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > > Never throw an error without telling exactly why it happened and exactly > where to fix it :-). Using bottom is last resort; exceptions likewise. > -- > Cheers > Michał > > > > > -- > Pozdrawiam > Michał > > > -- Pozdrawiam Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From raoknz at gmail.com Thu Aug 5 07:26:27 2021 From: raoknz at gmail.com (Richard O'Keefe) Date: Thu, 5 Aug 2021 19:26:27 +1200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: You quoted "> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse." Let x y and z be finite floating-point numbers such that x + y ==> z. Does there always exist neg(y) such that z + neg(y) ==> x? NO. And the presence or absence of NaN in the system makes no difference. If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly. That is, (x + y) - y == 0, but x is not 0. In the presence of rounding, additive inverses do not in general exist. Neither do multiplicative inverses. Also addition and multiplication are not associative, but you knew that. The only reason Float and Double are in Num is because Haskell doesn't offer ad hoc overloading. People have been saying that the Prelude needs refactoring for years. The main thing that NaN wrecks that wasn't already broken is Eq. I would argue that the right decision there would have been to rule that x == y (when x and y are floating point numbers) precisely when x and y are represented by the same bit pattern, with a separate operation for IEEE "ordered and equal". At some point, Haskell should make provision for decimal floating point, as the current versions of IEEE 754 and C do, and that might be a good reorganisation time. On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe wrote: > > Thanks Michał, > > I feel less confused as I realized the non-halting possibility per bottoms, from your hint. > > I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. > > Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > > > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. > > > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity > > > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. > > So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? > > No such family of `Num` classes exists to my aware by now, I just can't help wondering why. > > Cheers, > Compl > > On 2021-08-04, at 02:38, Michał J Gajda wrote: > > Dear Yue, > > Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! > > Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. > > Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. > > The problem with this approach is indeed a silent handling. > > But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > > Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. > -- > Cheers > Michał > > > _______________________________________________ > 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 compl.yue at icloud.com Thu Aug 5 08:22:56 2021 From: compl.yue at icloud.com (YueCompl) Date: Thu, 5 Aug 2021 16:22:56 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: <85E4F929-17CC-4CC6-9696-0674B55E37DA@icloud.com> Message-ID: But I'd think algebraic effects is orthogonal to Monad/Applicative/Functor, it's capable to separate effects from pure code on its own. Current standard classes in Haskell were designed without algebraic effect in mind. Especially the `Num` and its descendants, allied with `Eq` `Ord` and friends, I do see they can never allow `NaN` to be a legal existence, so there sure need another hierarchy of classes works similarly but embraces IEEE 754 at the same time. The hardware de facto has established intrinsic implementation of NaN/Inf semantics, including propagation during arithmetics and special rules during comparisons, we just need ratification in our type system, maybe retrospectively. Or `NaN` is actually another [billion-dollar mistake](https://en.wikipedia.org/wiki/Tony_Hoare#Apologies_and_retractions ) we'd rather to avoid? Aside from that, currently `ArithException` can only be caught within `IO` monad, but it can occur in evaluation of "pure" code. As I understand it, monad is a sublanguage to express "order" in execution (along with its bigger purpose of effect tracking), while evaluation of pure code has no "order" semantics thus in no need of monads. But pure code has nesting structures nevertheless, so to express the awareness/handling of NaN, "divide by zero" and similar situations, in a specific subsection of the pure code block, monad (i.e. IO here) based exception handling is not ideal here, as it sorta works by delimiting related pure computations into monadic steps, but that's unnatural or abuse of the execution order expressing device. Algebraic effects & handlers is the perfect device for such support, as far as I see it now, but strangely I don't feel it's absolute necessary in doing this job. The situation is still messy in my head... > On 2021-08-05, at 11:51, Michal J Gajda wrote: > > Yue, > > Yes, it seems it would work > This useful workaround works uses exception effect. > So it may have two disadvantages: > > 1. You may only catch the effect in a monad that can catch exceptions, like IO. > 2. It does not give a clear path for handling collections of computations. > > Note that DSLs also need to redefine Eq as effectful class. Then `(==) :: Applicative expr => expr a -> expr a -> expr bool`. > > This solution may be preferred if You have: > > * a DSL already > * additional metadata attached to values, like provenance, security access level, versioning, Merkel hash, memo hash, equivalence class etc. > * want to handle error values without exposing Yourself to imprecise exceptions etc. > > It has disadvantage of redefining several standard classes, and we do not yet seem to have a library that would properly provide these type classes parameterized over any Applicative. > > But again, the need for more principled handling of error values will likely come as software scales. > — > Best regards > Michał > > > > On Wed, 4 Aug 2021 at 16:56 YueCompl > wrote: > `Eq` relies on the established `Bool` type, then can we solve it, if given algebraic effects & handlers, by Church-encoding an effectful Boolean type? e.g. > > true === \a b -> a > false === \a b -> b > cmpWithNaN === \a b -> perform ComparingWithNaN > > Then (==) and (/=) in `Eq`, together with friends in `Ord` like (>) (<) all return `cmpWithNaN` when at least one NaN is involved. > > This mechanism is open so all kinds of anomalies can be handled similarly, otherwise even we have all NaN, Inf, Underflow, Overflow etc. handled well, there must be more situations we haven't thought of. > > >> On 2021-08-04, at 22:24, Michal J Gajda > wrote: >> >> The infamous `NaN /= NaN` makes only sense for `NaN` originating as a >> result, since we cannot compare `NaN`s originating from different >> computations. >> But it breaks `Eq` instance laws as needed for property tests. >> That is why comparison on `NaN` is better handled by `isFinite`, >> `isANumber` predicates. >> Note that beside `NaN` we also have other anomalous values, like >> Underflow, Overflow, +inf and -inf. >> These are all error values, and can hardly be treated in any other way. >> And they all need to be handled for floating points. >> >> Yes, comparing `NaN` with anything should give a rise to another error value. >> That means that the only way out is making Either Error Float, and >> then `(>=) :: Either Error Float -> Either Error Float -> Either Error >> Bool` >> So basically we need to lift all `Num` operations to the `Either Error` Monad. >> >> That is probably best way to fix the problem: once error value >> appears, we need to treat it consistently throughout entire >> computation. >> At the same time, we do not want a single error value to dominate >> entire computation, so that is why we treat collections of >> computations as computations that give a collection of good results >> and a collection of errors separately. >> If we take this into consideration, we notice that most interesting >> computations occur on collections of values, and thus yield a >> collection of results, not just a single output. >> >> That is one takeaway from the referenced presentation on data >> analytics in Haskell. (Similar presentation was also well received on >> Data Science Europe. It should be on YouTube by now.) >> >> Example of a 3D rotation is instructive: if NaN appears for any single >> coordinate, we can get a useful results for all other coordinates, and >> thus narrow impact of an error. >> If the next step is projection on X-Y coordinates, then NaN or >> Over/Under-flow within Z does not affect the result. >> >> To my understanding, that is also the reason why IEEE mandated special >> treatment of error values: most of the computations happen on large >> matrices, vectors etc, and crashing for each single NaN would be a >> true disaster. >> It can be even ignored, when the NaN is computed for an energy >> component within a single frame of long-running simulation, and the >> error disappears within a single time step. >> -- >> Cheers >> Michał >> >> On Wed, Aug 4, 2021 at 4:00 PM YueCompl > wrote: >>> >>> Thanks Michał, >>> >>> I feel less confused as I realized the non-halting possibility per bottoms, from your hint. >>> >>> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. >>> >>> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs >>> >>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. >>> >>>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity >>> >>>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. >>> >>> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: >>> >>> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable >>> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? >>> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? >>> >>> No such family of `Num` classes exists to my aware by now, I just can't help wondering why. >>> >>> Cheers, >>> Compl >>> >>> On 2021-08-04, at 02:38, Michał J Gajda > wrote: >>> >>> Dear Yue, >>> >>> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! >>> >>> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. >>> >>> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. >>> >>> The problem with this approach is indeed a silent handling. >>> >>> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding >>> >>> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. >>> -- >>> Cheers >>> Michał >>> >>> >> >> >> -- >> Pozdrawiam >> Michał > > -- > Pozdrawiam > Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at icloud.com Thu Aug 5 08:41:42 2021 From: compl.yue at icloud.com (YueCompl) Date: Thu, 5 Aug 2021 16:41:42 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: > At some point, Haskell should make provision for decimal floating point, > as the current versions of IEEE 754 and C do, and that might be a good > reorganisation time. Yeah, I think this is the thing I'm anticipating, current standard classes favor lossless computation by the laws, but large portion of the computer numeric solutions are taking loss of precision for efficiency. And neural systems even right following this approach as far as it appears, I sincerely hope Haskell can embrace it to some degree. > On 2021-08-05, at 15:26, Richard O'Keefe wrote: > > You quoted > "> Note that due to the presence of @NaN@, not all elements of 'Float' > have an additive inverse." > > Let x y and z be finite floating-point numbers such that x + y ==> z. > Does there always exist neg(y) such that z + neg(y) ==> x? > NO. > > And the presence or absence of NaN in the system makes no difference. > If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly. > That is, (x + y) - y == 0, but x is not 0. > > In the presence of rounding, additive inverses do not in general exist. > Neither do multiplicative inverses. > > Also addition and multiplication are not associative, but you knew that. > The only reason Float and Double are in Num is because Haskell doesn't > offer ad hoc overloading. People have been saying that the Prelude needs > refactoring for years. > > The main thing that NaN wrecks that wasn't already broken is Eq. I would > argue that the right decision there would have been to rule that x == y > (when x and y are floating point numbers) precisely when x and y are > represented by the same bit pattern, with a separate operation for IEEE > "ordered and equal". > > At some point, Haskell should make provision for decimal floating point, > as the current versions of IEEE 754 and C do, and that might be a good > reorganisation time. > > > On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe > wrote: >> >> Thanks Michał, >> >> I feel less confused as I realized the non-halting possibility per bottoms, from your hint. >> >> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. >> >> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs >> >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. >> >>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity >> >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. >> >> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: >> >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? >> >> No such family of `Num` classes exists to my aware by now, I just can't help wondering why. >> >> Cheers, >> Compl >> >> On 2021-08-04, at 02:38, Michał J Gajda wrote: >> >> Dear Yue, >> >> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! >> >> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. >> >> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. >> >> The problem with this approach is indeed a silent handling. >> >> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding >> >> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. >> -- >> Cheers >> Michał >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. From olf at aatal-apotheke.de Thu Aug 5 18:48:09 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 05 Aug 2021 20:48:09 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? Message-ID: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> > So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? > > No such family of `Num` classes exists to my aware by now, I just can't help wondering why. > > Cheers, > Compl > I like to think of NaN as a glimpse of interval arithmetic. NaN is the interval -infintity to infinity [*]. When ordering intervals by reverse inclusion, NaN is indeed the bottom of the domain. For a general (closed) interval [x,y], how would you answer the questions [x,y] < [1,1]? [x,y] /= [1,1]? There are several possibilities known, extending relations on points to relations on sets. See Smyth-, Hoare- and Egli-Milner lifting of relations. So a more descriptive type of Float-ordering may be (<) :: Float -> Float -> RelationLifting -> Bool For example, NaN /= NaN under all three relation liftings mentioned above, but also NaN == NaN, so a /= b = not (a == b) does not hold anymore. > If we take this into consideration, we notice that most interesting > computations occur on collections of values, and thus yield a > collection of results, not just a single output. Indeed, one route to real arithmetic is via limits of collections of approximants. For example, consider a dense set of rationals, excluding zero, where that all arithmetic operations are well-defined and total on the approximants. Then express a real number as (Dedekind-)cuts and see what cut operations like 0/0 result in. Each non-proper cut corresponds to a special Float value. Incidentally, this is how Conway constructed his surreal numbers that also contain values like infinity and -0. I'm in favour that there be two floating-point types: One IEEE- compliant that behaves just like in other languages, and one more lawful one (thereby with fewer class instances) that leverages the expressive power of Haskell. Ho matter how broken, the former should be the default unless we want to alienate numerically inclined Haskell adopters. Olaf [*] The mathematical function \(x,y) -> x/y attains every real value arbitrarily close to (0,0), whence NaN = 0/0 should be interpreted as the interval encompassing the real line. Likewise log(0) for complex 0. From ifl21.publicity at gmail.com Thu Aug 5 20:53:39 2021 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Thu, 5 Aug 2021 16:53:39 -0400 Subject: [Haskell-cafe] IFL'21 Final call for papers Message-ID: ================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl ================================================================================ Note: - We do accept extended abstracts for presentation - Submission is open - Registration is open 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 2021 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. Industrial track and topics of interest This year's edition of IFL explicitly solicits original work concerning *applications* of functional programming in industry and academia. These contributions will be reviewed by experts with an industrial background. 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 specialisation * run-time code generation * partial evaluation * (abstract) interpretation * meta-programming * 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 * testing and proofing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * applications of functional programming in the industry, including ** functional programming techniques for large applications ** successes of the application functional programming ** challenges for functional programming encountered ** any topic related to the application of functional programming that is interesting for the IFL community Post-symposium peer-review Following IFL tradition, IFL 2021 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. 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 for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. Moreover, the proceedings will also be made publicly available as open access. Important dates Submission deadline of draft papers: 17 August 2021 Notification of acceptance for presentation: 19 August 2021 Registration deadline: 30 August 2021 IFL Symposium: 1-3 September 2021 Submission of papers for proceedings: 6 December 2021 Notification of acceptance: 3 February 2022 Camera-ready version: 15 March 2022 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 . (For LaTeX users, start your document with \documentclass[format=sigconf]{acmart}.) Note that this format has a rather long but limited list of packages that can be used. Please make sure that your document adheres to this list. The submission Web page for IFL21 is https://easychair.org/conferences/?conf=ifl21 . Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured 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. Organisation IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands PC: Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary Virtual symposium Because of the Covid-19 pandemic, this year IFL 2021 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. Registration Please use the link below to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8ofIqshfQFrf4jnvsA/viewform?usp=sf_link Thanks to the sponsors and the support of the Radboud university registration is free of charge. [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Thu Aug 5 21:27:12 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Thu, 05 Aug 2021 21:27:12 +0000 Subject: [Haskell-cafe] [ANN] Cabal-3.6.0.0 Message-ID: Hello All, The Cabal team is excited to announce the release of Cabal-3.6.0.0! This is the fourth release of the 3.0 release series, and highlights include support for GHC 9.2, as well as many new code quality improvements + organization work on the repo itself. For future plans, we've announced a State of the Cabal post which describes where we want to take the library and executable over the next year or two here: https://discourse.haskell.org/t/state-of-the-cabal-q1-q2-2021/2548. If you'd like to get involved, feel free to contact anyone from the maintainer team directly, or drop by #hackage on libera.chat ( http://libera.chat/ ) to speak with us. Additionally, as we continue to modernize Cabal, I'd like to highlight and show appreciation for all of the help we've gotten from the community, including the developer hours coming from Well-Typed, Haskell Foundation/Haskell.org ( http://foundation/Haskell.org ) , Obsidian Systems, and the Haskell Language Server folks. I'm glad we could work together! For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/Cabal-3.6.0.0.md. If you have issues, we'd love to hear about there here: https://github.com/haskell/cabal/issues. Happy hacking! Emily -------------- next part -------------- An HTML attachment was scrubbed... URL: From icfp.publicity at googlemail.com Fri Aug 6 02:51:16 2021 From: icfp.publicity at googlemail.com (Sam Tobin-Hochstadt) Date: Thu, 05 Aug 2021 22:51:16 -0400 Subject: [Haskell-cafe] Call for Participation: ICFP 2021 Message-ID: <610ca3a4aac4a_1ba72e4145@homer.mail> ===================================================================== Call for Participation ICFP 2021 26th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 22 - August 27, 2021 Online http://icfp21.sigplan.org/ Early Registration until August 7! ===================================================================== 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, the conference will be a virtual event. All activities will take place online. The main conference will take place from August 23-25, 2021 during two time bands. The first band will be 4PM-11PM Seoul time, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 3PM-10PM New York, the following day. We’re excited to announce that ICFP 2021 will feature an invited talk from Ravi Chugh of the University of Chicago. Keynote sessions will take place at 10 PM Seoul/9 AM New York. ICFP has officially accepted 35 exciting papers, and (in its second year) there will also be presentations of 4 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 7th, 2021. Registration is not free, but is significantly lower than usual, including a $10 discounted registration option available to all. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2021conf/ICFP21/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp21.sigplan.org/home * Accepted papers: http://icfp21.sigplan.org/track/icfp-2021-papers#event-overview * JFP Talks: https://icfp21.sigplan.org/track/icfp-2021-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2021conf/ICFP21/register.php Early registration ends 8 August, 2021. * Programming contest: https://icfpcontest2021.github.io/ * Student Research Competition: https://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/26) * Haskell Implementors' Workshop (8/22) * Haskell Symposium (8/26-8/27) * Higher-Order Programming with Effects (8/22) * miniKanren Workshop (8/26) * ML Family Workshop (8/26) * OCaml Workshop (8/27) * Programming Languages Mentoring Workshop (8/22) * Scheme Workshop (8/27) * Type-Driven Development (8/22) ### ICFP Organizers General Chair: Sukyoung Ryu (KAIST, South Korea) Program Chair: Ron Garcia (UBC, Canada) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Gabriel Scherer (INRIA Saclay, France) Industrial Relations Chair: Alan Jeffrey (Roblox, USA) Simon Marlow (Facebook, UK) Programming Contest Organizers: Alex Lang and Jasper Van der Jeugt Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Anders Miltner (University of Texas, USA) Workshops Co-Chairs: Zoe Paraskevopoulou (Northeastern University, USA) Leonidas Lampropoulos (University of Maryland, USA) Video Co-Chairs: Leif Andersen (Northeastern University, USA) Ben Chung (Northeastern University, USA) Student Volunteer Co-Chairs: Hanneli Tavante (McGill University, Canada) Jaemin Hong (KAIST, South Korea) Lily Bryant (UBC, Canada) Accessibility Co-Chairs: Lindsey Kuper (UCSC, USA) Kathrin Stark (Princeton, USA) From xnningxie at gmail.com Fri Aug 6 04:06:37 2021 From: xnningxie at gmail.com (Ningning Xie) Date: Fri, 6 Aug 2021 00:06:37 -0400 Subject: [Haskell-cafe] Call for Lightning Talks: Haskell Implementors' Workshop @ ICFP'21 Message-ID: Call for Lightning Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Thursday, 19 Aug, 2021 (or when slots are full, whichever is sooner) Workshop: Sunday, 22 Aug, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. We will have a number of slots for lightning talks. Lightning talks will be ~7 minutes and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Submissions should be made via Google form: https://forms.gle/BmUSyWWTXt1AMTec8 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Contact ------- * Ningning Xie -------------- next part -------------- An HTML attachment was scrubbed... URL: From victor.perez at imdea.org Fri Aug 6 12:02:54 2021 From: victor.perez at imdea.org (Victor Perez) Date: Fri, 6 Aug 2021 14:02:54 +0200 Subject: [Haskell-cafe] Call for Workshops - FLoC 2022 Message-ID: <997f8788-71eb-da80-4789-541a833f2eec@imdea.org> Second Call for Workshops- FLoC 2022 — The 2022 Federated Logic Conference July 31 - August 12, 2022 Haifa, Israel http://www.floc2022.org/ CALL FOR WORKSHOPS The Eighth Federated Logic Conference (FLoC 2022) will host the following ten conferences and affiliated workshops. LICS (37th Annual ACM/IEEE Symposium on Logic in Computer Science) http://lics.rwth-aachen.de/ Workshop chair: Frederic Blanqui Frederic.Blanqui at inria.fr FSCD (7th International Conference on Formal Structures for Computation and Deduction) http://fscd-conference.org/ Workshop chair: Nachum Dershowitz nachumd at tau.ac.il ITP (13th International Conference on Interactive Theorem Proving) https://itp-conference.github.io/ Workshop chair: Cyril Cohen cyril.cohen at inria.fr IJCAR (International Joint Conference on Automated Reasoning) http://www.ijcar.org Workshop chairs: Simon Robillard simon.robillard at imt-atlantique.fr Sophie Tourret stourret at mpi-inf.mpg.de CSF (35th IEEE Computer Security Foundations Symposium) http://www.ieee-security.org/CSFWweb/ Workshop chair: Musard Balliu musard at kth.se CAV (34th International Conference on Computer Aided Verification) http://i-cav.org/ Workshop chair: TBD KR (19th International Conference on Principles of Knowledge Representation and Reasoning) http://www.kr.org/ Workshop chair: Stefan Borgwardt stefan.borgwardt at tu-dresden.de ICLP (38th International Conference on Logic Programming) https://www.cs.nmsu.edu/ALP/conferences/ Workshop chair: Daniela Inclezan inclezd at miamioh.edu SAT (25th International Conference on Theory and Applications of Satisfiability Testing) http://www.satisfiability.org Workshop chair: Alexander Nadel alexander.nadel at intel.com CP (25th International Conference on Principles and Practice of Constraint Programming) http://a4cp.org/events/cp-conference-series Workshop chair: TBD SUBMISSION OF WORKSHOP PROPOSALS Researchers and practitioners are invited to submit proposals for workshops on topics in the field of computer science, related to logic in the broad sense. Each workshop proposal must indicate one affiliated conference of FLoC 2022. It is strongly suggested that prospective workshop organizers contact the relevant conference workshop chair before submitting a proposal. Each proposal should consist of the following two parts. 1) A short scientific justification of the proposed topic, its significance, and the particular benefits of the workshop to the community, as well as a list of previous or related workshops (if relevant). 2) An organisational part including: - contact information for the workshop organizers; - proposed affiliated conference; - estimate of the number of workshop participants (please note that small workshops, i.e., of less than ~13 participants, will likely be cancelled or merged); - proposed format and agenda (e.g. paper presentations, tutorials, demo sessions, etc.); - potential invited speakers (note that expenses of workshop invited speakers are not covered by FLoC); - procedures for selecting papers and participants; - plans for dissemination, if any (e.g. a journal special issue); - duration (which may vary from one day to two days); - preferred period (pre or post FLoC); - virtual/hybrid backup plans (including platform preference). The FLoC Organizing Committee will determine the final list of accepted workshops based on the recommendations from the Workshop Chairs of the hosting conferences and availability of space and facilities. Proposals should be submitted through EasyChair: https://easychair.org/conferences/?conf=floc2022workshops Please see the Workshop Guidelines page: https://floc2022.org/workshops/ for further details and FAQ. IMPORTANT DATES Submission of workshop proposals deadline: September 27, 2021 (note extended deadline) Notification: November 1, 2021 Pre-FLoC workshops: Sunday & Monday, July 31–August 1, 2022 (note corrected dates) Post-FLoC workshops: Thursday & Friday, August 11-12, 2022 CONTACT INFORMATION Questions regarding proposals should be sent to the workshop chairs of the proposed affiliated conference. General questions should be sent to: shaull at technion.ac.il GuillermoAlberto.Perez at uantwerpen.be FLoC 2022 WORKSHOP CHAIRS Shaull Almagor Guillermo A. Perez From compl.yue at icloud.com Fri Aug 6 14:21:51 2021 From: compl.yue at icloud.com (YueCompl) Date: Fri, 6 Aug 2021 22:21:51 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> Message-ID: <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> Thanks Olaf, Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? > On 2021-08-06, at 02:48, Olaf Klinke wrote: > >> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: >> >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? >> >> No such family of `Num` classes exists to my aware by now, I just can't help wondering why. >> >> Cheers, >> Compl >> > I like to think of NaN as a glimpse of interval arithmetic. NaN is the > interval -infintity to infinity [*]. When ordering intervals by reverse > inclusion, NaN is indeed the bottom of the domain. For a general > (closed) interval [x,y], how would you answer the questions > [x,y] < [1,1]? > [x,y] /= [1,1]? > There are several possibilities known, extending relations on points to > relations on sets. See Smyth-, Hoare- and Egli-Milner lifting of > relations. So a more descriptive type of Float-ordering may be > (<) :: Float -> Float -> RelationLifting -> Bool > For example, NaN /= NaN under all three relation liftings mentioned > above, but also NaN == NaN, so a /= b = not (a == b) does not hold > anymore. > >> If we take this into consideration, we notice that most interesting >> computations occur on collections of values, and thus yield a >> collection of results, not just a single output. > > Indeed, one route to real arithmetic is via limits of collections of > approximants. For example, consider a dense set of rationals, excluding > zero, where that all arithmetic operations are well-defined and total > on the approximants. Then express a real number as (Dedekind-)cuts and > see what cut operations like 0/0 result in. Each non-proper cut > corresponds to a special Float value. Incidentally, this is how Conway > constructed his surreal numbers that also contain values like infinity > and -0. > > I'm in favour that there be two floating-point types: One IEEE- > compliant that behaves just like in other languages, and one more > lawful one (thereby with fewer class instances) that leverages the > expressive power of Haskell. Ho matter how broken, the former should be > the default unless we want to alienate numerically inclined Haskell > adopters. > > Olaf > > [*] The mathematical function \(x,y) -> x/y attains every real value > arbitrarily close to (0,0), whence NaN = 0/0 should be interpreted as > the interval encompassing the real line. Likewise log(0) for complex 0. > From olf at aatal-apotheke.de Fri Aug 6 22:16:39 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 07 Aug 2021 00:16:39 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> Message-ID: On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote: > Thanks Olaf, > > Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. > Pen-and-paper or GHCi experiments suffice here, no fancy theoretical background needed. Say Q is the type of rationals 0 < q and we express type NonNegativeNumber = ([Q],[Q]) where the first (infinite) list is the lower approximants and the second the upper approximants. Multiplication is then defined as (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) The extremes of this type are 0 = ([],Q) infty = (Q,[]) It is easily seen that 0 * infty = ([],[]) a number with no lower and no upper approximants, in other words, NaN. Excercise: Define division for this type and find out what 1/0 and 0/0 is. > Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? > Yes. I think it is vital that we provide a migration path for programmers coming from other languages. Under the Dedekind cut/interval interpretation, NaN would behave differently, as I pointed out. So I'd leave Float as it is, but be more verbose about its violation of type class laws. To this end, one could have (and now I might be closer to your initial question) numerical type classes like HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only those types that obey the laws in all elements. Naturally, Float would not be a member. Who would use these new classes? Probably no one, because we all like to take the quick and dirty route. But at least it says clearly: Careful, you can not rely on these laws when using Float. Olaf From compl.yue at icloud.com Sat Aug 7 07:35:56 2021 From: compl.yue at icloud.com (YueCompl) Date: Sat, 7 Aug 2021 15:35:56 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> Message-ID: <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com> Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before. But I need some help to get it going: λ> :set -XTypeSynonymInstances λ> :set -XFlexibleInstances λ> λ> import Data.Ratio λ> type Q = Rational -- this is probably wrong ... λ> λ> type NonNegativeNumber = ([Q],[Q]) λ> :{ λ| instance Num NonNegativeNumber where λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) λ| :} :9:12: warning: [-Wmissing-methods] • No explicit implementation for ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’) • In the instance declaration for ‘Num NonNegativeNumber’ λ> λ> zero = ([],Q) :13:13: error: Data constructor not in scope: Q λ> infty = (Q,[]) :14:10: error: Data constructor not in scope: Q λ> λ> zero * infty -- expect: = ([],[]) :16:1: error: Variable not in scope: zero :16:8: error: Variable not in scope: infty λ> I'd like to do more exercises, but I'm stuck here ... > On 2021-08-07, at 06:16, Olaf Klinke wrote: > > On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote: >> Thanks Olaf, >> >> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. >> > Pen-and-paper or GHCi experiments suffice here, no fancy theoretical > background needed. Say Q is the type of rationals 0 < q and we express > type NonNegativeNumber = ([Q],[Q]) > where the first (infinite) list is the lower approximants and the > second the upper approximants. Multiplication is then defined as > (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) > The extremes of this type are > 0 = ([],Q) > infty = (Q,[]) > It is easily seen that > 0 * infty = ([],[]) > a number with no lower and no upper approximants, in other words, NaN. > Excercise: Define division for this type and find out what 1/0 and 0/0 > is. > >> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? >> > Yes. I think it is vital that we provide a migration path for > programmers coming from other languages. Under the Dedekind > cut/interval interpretation, NaN would behave differently, as I pointed > out. So I'd leave Float as it is, but be more verbose about its > violation of type class laws. To this end, one could have (and now I > might be closer to your initial question) numerical type classes like > HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only > those types that obey the laws in all elements. Naturally, Float would > not be a member. Who would use these new classes? Probably no one, > because we all like to take the quick and dirty route. But at least it > says clearly: Careful, you can not rely on these laws when using Float. > > Olaf > -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at icloud.com Sat Aug 7 08:16:21 2021 From: compl.yue at icloud.com (YueCompl) Date: Sat, 7 Aug 2021 16:16:21 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com> References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com> Message-ID: <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com> Another failed attempt: λ> :set -XTypeSynonymInstances λ> :set -XFlexibleInstances λ> λ> data Q = Q λ> λ> type NonNegativeNumber = ([Q],[Q]) λ> :{ λ| instance Num NonNegativeNumber where λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) λ| :} :12:25: error: • No instance for (Num Q) arising from a use of ‘*’ • In the expression: x * x' In the expression: [x * x' | x <- l, x' <- l'] In the expression: ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r']) λ> λ> zero = ([],Q) λ> infty = (Q,[]) λ> zero * infty :17:8: error: • Couldn't match type ‘Q’ with ‘[a]’ Expected type: ([a], Q) Actual type: (Q, [a0]) • In the second argument of ‘(*)’, namely ‘infty’ In the expression: zero * infty In an equation for ‘it’: it = zero * infty • Relevant bindings include it :: ([a], Q) (bound at :17:1) λ> > On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe wrote: > > Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before. > > But I need some help to get it going: > > λ> :set -XTypeSynonymInstances > λ> :set -XFlexibleInstances > λ> > λ> import Data.Ratio > λ> type Q = Rational -- this is probably wrong ... > λ> > λ> type NonNegativeNumber = ([Q],[Q]) > λ> :{ > λ| instance Num NonNegativeNumber where > λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) > λ| :} > > :9:12: warning: [-Wmissing-methods] > • No explicit implementation for > ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’) > • In the instance declaration for ‘Num NonNegativeNumber’ > λ> > λ> zero = ([],Q) > > :13:13: error: Data constructor not in scope: Q > λ> infty = (Q,[]) > > :14:10: error: Data constructor not in scope: Q > λ> > λ> zero * infty -- expect: = ([],[]) > > :16:1: error: Variable not in scope: zero > > :16:8: error: Variable not in scope: infty > λ> > > I'd like to do more exercises, but I'm stuck here ... > > >> On 2021-08-07, at 06:16, Olaf Klinke > wrote: >> >> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote: >>> Thanks Olaf, >>> >>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. >>> >> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical >> background needed. Say Q is the type of rationals 0 < q and we express >> type NonNegativeNumber = ([Q],[Q]) >> where the first (infinite) list is the lower approximants and the >> second the upper approximants. Multiplication is then defined as >> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) >> The extremes of this type are >> 0 = ([],Q) >> infty = (Q,[]) >> It is easily seen that >> 0 * infty = ([],[]) >> a number with no lower and no upper approximants, in other words, NaN. >> Excercise: Define division for this type and find out what 1/0 and 0/0 >> is. >> >>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? >>> >> Yes. I think it is vital that we provide a migration path for >> programmers coming from other languages. Under the Dedekind >> cut/interval interpretation, NaN would behave differently, as I pointed >> out. So I'd leave Float as it is, but be more verbose about its >> violation of type class laws. To this end, one could have (and now I >> might be closer to your initial question) numerical type classes like >> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only >> those types that obey the laws in all elements. Naturally, Float would >> not be a member. Who would use these new classes? Probably no one, >> because we all like to take the quick and dirty route. But at least it >> says clearly: Careful, you can not rely on these laws when using Float. >> >> 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 compl.yue at icloud.com Sat Aug 7 10:21:32 2021 From: compl.yue at icloud.com (YueCompl) Date: Sat, 7 Aug 2021 18:21:32 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com> References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com> <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com> Message-ID: <2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com> Okay, I got it working to some extent: (and I find it a good showcase for my https://marketplace.visualstudio.com/items?itemName=ComplYue.vscode-ghci extension, improved it a bit to support this very scenario, with the src file at https://github.com/complyue/typing.hs/blob/main/src/PoC/Floating.hs ) Obviously my naive implementation `(l, r) / (l', r') = ([x / x' | x <- l, x' <- l'], [y / y' | y <- r, y' <- r'])` is wrong, I think I need to figure out how to represent 1 (the unit number) of this type, even before I can come to a correct definition of the division (/) operation, but so far no clue ... > On 2021-08-07, at 16:16, YueCompl via Haskell-Cafe wrote: > > Another failed attempt: > > λ> :set -XTypeSynonymInstances > λ> :set -XFlexibleInstances > λ> > λ> data Q = Q > λ> > λ> type NonNegativeNumber = ([Q],[Q]) > λ> :{ > λ| instance Num NonNegativeNumber where > λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) > λ| :} > > :12:25: error: > • No instance for (Num Q) arising from a use of ‘*’ > • In the expression: x * x' > In the expression: [x * x' | x <- l, x' <- l'] > In the expression: > ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r']) > λ> > λ> zero = ([],Q) > λ> infty = (Q,[]) > λ> zero * infty > > :17:8: error: > • Couldn't match type ‘Q’ with ‘[a]’ > Expected type: ([a], Q) > Actual type: (Q, [a0]) > • In the second argument of ‘(*)’, namely ‘infty’ > In the expression: zero * infty > In an equation for ‘it’: it = zero * infty > • Relevant bindings include > it :: ([a], Q) (bound at :17:1) > λ> > > >> On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe > wrote: >> >> Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before. >> >> But I need some help to get it going: >> >> λ> :set -XTypeSynonymInstances >> λ> :set -XFlexibleInstances >> λ> >> λ> import Data.Ratio >> λ> type Q = Rational -- this is probably wrong ... >> λ> >> λ> type NonNegativeNumber = ([Q],[Q]) >> λ> :{ >> λ| instance Num NonNegativeNumber where >> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) >> λ| :} >> >> :9:12: warning: [-Wmissing-methods] >> • No explicit implementation for >> ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’) >> • In the instance declaration for ‘Num NonNegativeNumber’ >> λ> >> λ> zero = ([],Q) >> >> :13:13: error: Data constructor not in scope: Q >> λ> infty = (Q,[]) >> >> :14:10: error: Data constructor not in scope: Q >> λ> >> λ> zero * infty -- expect: = ([],[]) >> >> :16:1: error: Variable not in scope: zero >> >> :16:8: error: Variable not in scope: infty >> λ> >> >> I'd like to do more exercises, but I'm stuck here ... >> >> >>> On 2021-08-07, at 06:16, Olaf Klinke > wrote: >>> >>> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote: >>>> Thanks Olaf, >>>> >>>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. >>>> >>> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical >>> background needed. Say Q is the type of rationals 0 < q and we express >>> type NonNegativeNumber = ([Q],[Q]) >>> where the first (infinite) list is the lower approximants and the >>> second the upper approximants. Multiplication is then defined as >>> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) >>> The extremes of this type are >>> 0 = ([],Q) >>> infty = (Q,[]) >>> It is easily seen that >>> 0 * infty = ([],[]) >>> a number with no lower and no upper approximants, in other words, NaN. >>> Excercise: Define division for this type and find out what 1/0 and 0/0 >>> is. >>> >>>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? >>>> >>> Yes. I think it is vital that we provide a migration path for >>> programmers coming from other languages. Under the Dedekind >>> cut/interval interpretation, NaN would behave differently, as I pointed >>> out. So I'd leave Float as it is, but be more verbose about its >>> violation of type class laws. To this end, one could have (and now I >>> might be closer to your initial question) numerical type classes like >>> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only >>> those types that obey the laws in all elements. Naturally, Float would >>> not be a member. Who would use these new classes? Probably no one, >>> because we all like to take the quick and dirty route. But at least it >>> says clearly: Careful, you can not rely on these laws when using Float. >>> >>> 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. > > _______________________________________________ > 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: PastedGraphic-1.png Type: image/png Size: 81036 bytes Desc: not available URL: From christopher at conforti.xyz Sat Aug 7 19:18:45 2021 From: christopher at conforti.xyz (Christopher Conforti) Date: Sat, 7 Aug 2021 15:18:45 -0400 Subject: [Haskell-cafe] Organizing your code files Message-ID: <20210807151845.6b80d63d@ccc-pc.confortihome.net> Hi List, I'm a relatively new Haskeller. I've gotten the syntax of the language more or less down, and I'm slowly expanding my vocabulary. I've found in other languages that my coding style and how my code is organized affect both the quality of my code and how easy it is to understand. 'Coding style' refers to how code is organized within a block. For example: ``` foo bar baz bing = x + y * z ``` versus: ``` foo bar baz bing = x + y * z ``` Code organization refers both to how code is organized within a source file (i.e., how code blocks are arranged, how they're grouped, so on) and how source files themselves are organized. I've got the first part down--I've developed a code style that I'm satisfied with, I've tried to fine-tune my style to make maximum effective use of available space (limiting myself to 72 columns, and a block size of no more than 30 lines) so as to force myself to extract and abtract away unnecessary details. The second part is the one I'm having trouble with. There are so many ways to organize one's code that I don't even know where to begin developing a method that I like other than to ask other Haskellers how they do it and why they like doing it that way. So there you have it: How do you organize your code, and why? Cheers! -- Christopher Conforti -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From olf at aatal-apotheke.de Sat Aug 7 20:54:43 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Sat, 07 Aug 2021 22:54:43 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: <2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com> References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com> <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com> <2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com> Message-ID: Dear Compl, Apologies, my code was meant as math formula in Haskell syntax. For starters, something like [x*y | x <- xs, y <- ys] will not go past the first element of xs if the other list ys is infinite. Hence you need another way to enumerate an infinite 2-D grid. I also used the symbol Q as shorthand for "a list that is cofinal in the set Q" which in case of lower approximants can be [1..] and in the case of upper approximants can be (fmap recip [1..]). If you can maintain the invariant that both lists of approximants are ascending or descending, respecively, then you can replace the above list comprehension by zipWith (*) xs ys which will also be much faster and does the right thing if one list is empty and the other is infinite. Further I wouldn't go directly for a full Num instance but define the arithmetic functions one by one under a different name. That way the "No explicit implementation for ..." doesn't bite you. Once you have defined all, the Num instance is just aliasing the Num functions with your type-specific ones. For division, you need to think this way: I have a quotient a/b. When I wobble a or b in either direction, does the quotient get smaller (lower approximant) or larger (upper approximant)? Clearly, when replacing a by one of its lower approximants x, then x/b < a/b. (This is only true because we're excluding negative numbers!) Likewise for upper approximants to a. Next, if b is replaced by one of its upper approximants y', then x/y' < x/b < a/b. We conclude that the lower approximants of a/b are of the form x/y' where x is a lower approximant of a and y' is an upper approximant of b. When you're done, you will have implemented exact real arithmetic, which does not suffer from the rounding errors but is usually also much slower than floating point arithmetic. And as a by-product you will have a proof that NaN is the price we must pay for totality of (/) and (*). I also attach a chapter from my monograph "Haskell for mathematicians" which is a literate program containing three different implementations of exact reals in Haskell, Conway's surreal numbers being one of them, as well as a more comprehensive surreal numbers implementation. Olaf On Sat, 2021-08-07 at 18:21 +0800, YueCompl wrote: > Okay, I got it working to some extent: > (and I find it a good showcase for my https://marketplace.visualstudio.com/items?itemName=ComplYue.vscode-ghci extension, improved it a bit to support this very scenario, with the src file at https://github.com/complyue/typing.hs/blob/main/src/PoC/Floating.hs ) > > > > Obviously my naive implementation `(l, r) / (l', r') = ([x / x' | x <- l, x' <- l'], [y / y' | y <- r, y' <- r'])` is wrong, I think I need to figure out how to represent 1 (the unit number) of this type, even before I can come to a correct definition of the division (/) operation, but so far no clue ... > > > On 2021-08-07, at 16:16, YueCompl via Haskell-Cafe wrote: > > > > Another failed attempt: > > > > λ> :set -XTypeSynonymInstances > > λ> :set -XFlexibleInstances > > λ> > > λ> data Q = Q > > λ> > > λ> type NonNegativeNumber = ([Q],[Q]) > > λ> :{ > > λ| instance Num NonNegativeNumber where > > λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) > > λ| :} > > > > :12:25: error: > > • No instance for (Num Q) arising from a use of ‘*’ > > • In the expression: x * x' > > In the expression: [x * x' | x <- l, x' <- l'] > > In the expression: > > ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r']) > > λ> > > λ> zero = ([],Q) > > λ> infty = (Q,[]) > > λ> zero * infty > > > > :17:8: error: > > • Couldn't match type ‘Q’ with ‘[a]’ > > Expected type: ([a], Q) > > Actual type: (Q, [a0]) > > • In the second argument of ‘(*)’, namely ‘infty’ > > In the expression: zero * infty > > In an equation for ‘it’: it = zero * infty > > • Relevant bindings include > > it :: ([a], Q) (bound at :17:1) > > λ> > > > > > > > On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe > wrote: > > > > > > Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before. > > > > > > But I need some help to get it going: > > > > > > λ> :set -XTypeSynonymInstances > > > λ> :set -XFlexibleInstances > > > λ> > > > λ> import Data.Ratio > > > λ> type Q = Rational -- this is probably wrong ... > > > λ> > > > λ> type NonNegativeNumber = ([Q],[Q]) > > > λ> :{ > > > λ| instance Num NonNegativeNumber where > > > λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) > > > λ| :} > > > > > > :9:12: warning: [-Wmissing-methods] > > > • No explicit implementation for > > > ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’) > > > • In the instance declaration for ‘Num NonNegativeNumber’ > > > λ> > > > λ> zero = ([],Q) > > > > > > :13:13: error: Data constructor not in scope: Q > > > λ> infty = (Q,[]) > > > > > > :14:10: error: Data constructor not in scope: Q > > > λ> > > > λ> zero * infty -- expect: = ([],[]) > > > > > > :16:1: error: Variable not in scope: zero > > > > > > :16:8: error: Variable not in scope: infty > > > λ> > > > > > > I'd like to do more exercises, but I'm stuck here ... > > > > > > > > > > On 2021-08-07, at 06:16, Olaf Klinke > wrote: > > > > > > > > On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote: > > > > > Thanks Olaf, > > > > > > > > > > Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. > > > > > > > > > Pen-and-paper or GHCi experiments suffice here, no fancy theoretical > > > > background needed. Say Q is the type of rationals 0 < q and we express > > > > type NonNegativeNumber = ([Q],[Q]) > > > > where the first (infinite) list is the lower approximants and the > > > > second the upper approximants. Multiplication is then defined as > > > > (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) > > > > The extremes of this type are > > > > 0 = ([],Q) > > > > infty = (Q,[]) > > > > It is easily seen that > > > > 0 * infty = ([],[]) > > > > a number with no lower and no upper approximants, in other words, NaN. > > > > Excercise: Define division for this type and find out what 1/0 and 0/0 > > > > is. > > > > > > > > > Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? > > > > > > > > > Yes. I think it is vital that we provide a migration path for > > > > programmers coming from other languages. Under the Dedekind > > > > cut/interval interpretation, NaN would behave differently, as I pointed > > > > out. So I'd leave Float as it is, but be more verbose about its > > > > violation of type class laws. To this end, one could have (and now I > > > > might be closer to your initial question) numerical type classes like > > > > HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only > > > > those types that obey the laws in all elements. Naturally, Float would > > > > not be a member. Who would use these new classes? Probably no one, > > > > because we all like to take the quick and dirty route. But at least it > > > > says clearly: Careful, you can not rely on these laws when using Float. > > > > > > > > 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. > > > > _______________________________________________ > > 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: haskell_for_analysists.lhs Type: text/x-literate-haskell Size: 26665 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: surreal.hs Type: text/x-haskell Size: 9933 bytes Desc: not available URL: From hecate at glitchbra.in Sun Aug 8 06:50:24 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Sun, 8 Aug 2021 08:50:24 +0200 Subject: [Haskell-cafe] Organizing your code files In-Reply-To: <20210807151845.6b80d63d@ccc-pc.confortihome.net> References: <20210807151845.6b80d63d@ccc-pc.confortihome.net> Message-ID: <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> Hi Christopher! On my end, I make use of automated style formatters, so that this kind of thing can be kept consistent during CI. I invite you not to think too much about the micro-details of code styles, but rather find a tool that you can configure so that your style can be enforced automatically. You'll be able to spend more cycles on programme development. I can give you an example of a recent library I wrote: https://github.com/Kleidukos/effectful-contrib/blob/8ae8ad1d76e0c43610619fc04a545dc622bafb88/effectful-cache/src/Data/Cache/Effect.hs#L47-L57 Note that: * Type variables are made explicit, and as such I annotate even the simplest of them (with `:: Type`) * I align the separators (., => and ->) * I use stylish-haskell & hlint * If you want finer automated control, try something like Britanny. Le 07/08/2021 à 21:18, Christopher Conforti a écrit : > Hi List, > I'm a relatively new Haskeller. I've gotten the syntax of the > language more or less down, and I'm slowly expanding my vocabulary. I've > found in other languages that my coding style and how my code is > organized affect both the quality of my code and how easy it is to > understand. > > 'Coding style' refers to how code is organized within a block. For > example: > ``` > foo bar baz bing = x + y * z > ``` > versus: > ``` > foo > bar > baz > bing > = x + y * z > ``` > > Code organization refers both to how code is organized within a > source file (i.e., how code blocks are arranged, how they're grouped, > so on) and how source files themselves are organized. > > I've got the first part down--I've developed a code style that I'm > satisfied with, I've tried to fine-tune my style to make maximum > effective use of available space (limiting myself to 72 columns, and a > block size of no more than 30 lines) so as to force myself to extract > and abtract away unnecessary details. > > The second part is the one I'm having trouble with. There are so many > ways to organize one's code that I don't even know where to begin > developing a method that I like other than to ask other Haskellers how > they do it and why they like doing it that way. > > So there you have it: How do you organize your code, and why? > > Cheers! > > > _______________________________________________ > 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgajda at mimuw.edu.pl Mon Aug 9 10:18:47 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Mon, 9 Aug 2021 12:18:47 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: So we have two things here: * lossy computation that needs a distance (metric) between points below epsilon instead of a comparison; in this case we should never ask for exact equality, but rather ask if a result is within a certain radius from a result. That means we measure convergence according to a metric, not equivalence. ``` class Ord m => Metric m a where dist :: a -> a -> m a ~= b = dist a b <= epsilon ``` * handling and propagation of different error values. That would require a rehash of both standard libraries and most mathematical algebra libraries for Haskell. For at least two reasons: * libraries assume a naive equality works for all types. Holds in a world of infinte precision and lossless operations, but never holds for approximations. * our propagation of universal error values is incomplete, and usually missing from complex algorithms. In other words `Either String` Monad does not work: we want collections of error values just like we have collections of inputs. Personally I will be overjoyed when our community finally gets the better type class library for approximated types. Would You agree to review a teaser if I post it here? — Cheers Michał On Thu, 5 Aug 2021 at 10:41 YueCompl wrote: > > At some point, Haskell should make provision for decimal floating point, > > as the current versions of IEEE 754 and C do, and that might be a good > > reorganisation time. > > > Yeah, I think this is the thing I'm anticipating, current standard classes > favor lossless computation by the laws, but large portion of the computer > numeric solutions are taking loss of precision for efficiency. And neural > systems even right following this approach as far as it appears, I > sincerely hope Haskell can embrace it to some degree. > > > > On 2021-08-05, at 15:26, Richard O'Keefe wrote: > > > > You quoted > > "> Note that due to the presence of @NaN@, not all elements of 'Float' > > have an additive inverse." > > > > Let x y and z be finite floating-point numbers such that x + y ==> z. > > Does there always exist neg(y) such that z + neg(y) ==> x? > > NO. > > > > And the presence or absence of NaN in the system makes no difference. > > If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly. > > That is, (x + y) - y == 0, but x is not 0. > > > > In the presence of rounding, additive inverses do not in general exist. > > Neither do multiplicative inverses. > > > > Also addition and multiplication are not associative, but you knew that. > > The only reason Float and Double are in Num is because Haskell doesn't > > offer ad hoc overloading. People have been saying that the Prelude needs > > refactoring for years. > > > > The main thing that NaN wrecks that wasn't already broken is Eq. I would > > argue that the right decision there would have been to rule that x == y > > (when x and y are floating point numbers) precisely when x and y are > > represented by the same bit pattern, with a separate operation for IEEE > > "ordered and equal". > > > > At some point, Haskell should make provision for decimal floating point, > > as the current versions of IEEE 754 and C do, and that might be a good > > reorganisation time. > > > > > > On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe > > wrote: > >> > >> Thanks Michał, > >> > >> I feel less confused as I realized the non-halting possibility per > bottoms, from your hint. > >> > >> I too think the signaling NaN is dreadful enough, so fortunately it's > rarely seen nowadays. > >> > >> Actually what's on my mind was roughly something like "Maybe on > steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, > as seen at > https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > >> > >>> Note that due to the presence of @NaN@, not all elements of 'Float' > have an additive inverse. > >> > >>> Also note that due to the presence of -0, Float's 'Num' instance > doesn't have an additive identity > >> > >>> Note that due to the presence of @NaN@, not all elements of 'Float' > have an multiplicative inverse. > >> > >> So it should have been another family of `Num` classes, within which, > various NaN related semantics can be legal, amongst which I'd think: > >> > >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, > seems quite acceptable > >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground > or not? > >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's > a theoretical framework for this to hold? Maybe `Boolean` type needs > enhancement too to do it? > >> > >> No such family of `Num` classes exists to my aware by now, I just can't > help wondering why. > >> > >> Cheers, > >> Compl > >> > >> On 2021-08-04, at 02:38, Michał J Gajda wrote: > >> > >> Dear Yue, > >> > >> Bottom has much weaker semantics than an exception: it means You may > never get a result and thus will never handle it! > >> > >> Another reason is convenience: it is frequently the case that giving > NaN in a row of numbers is much more informative than crashing a program > with an exception and never printing the result anyway. > >> > >> Finally IEEE special values have clear propagation semantics: they are > basically Maybe on steroids. > >> > >> The problem with this approach is indeed a silent handling. > >> > >> But in order to fix this, it is better to add preconditions to specific > algorithms that do not allow IEEE special value on input (`isFinite` or > `isNotNaN`) and then track the origin of the special value with the methods > like those described here: > https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > >> > >> Never throw an error without telling exactly why it happened and > exactly where to fix it :-). Using bottom is last resort; exceptions > likewise. > >> -- > >> Cheers > >> Michał > >> > >> > >> _______________________________________________ > >> 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. > > -- Pozdrawiam Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at icloud.com Mon Aug 9 11:36:56 2021 From: compl.yue at icloud.com (YueCompl) Date: Mon, 9 Aug 2021 19:36:56 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: <7931FC1B-BEED-4B9A-9857-4C24DF2D5B17@icloud.com> Dear Michał, I suppose by "You" you mean more people in this list those are more capable and have greater wisdom in this topic, I don't think myself a qualified Haskeller yet, but I can't help thinking about it. I especially wonder at this moment, if more proper & prevalent handling of metric errors can lead to new discoveries in neural programming (more principled training of neural networks? synthetic samples & labels beyond mere data acquisition?) I have strong feel that Haskell shall really shine in modeling or trialing related ideas, compared to other languages and tools. Can't speak for others but I quite anticipate your teaser, even though I may not fully understand it with my limited expertise in this area. Best regards, Compl > On 2021-08-09, at 18:18, Michal J Gajda wrote: > > So we have two things here: > > * lossy computation that needs a distance (metric) between points below epsilon instead of a comparison; in this case we should never ask for exact equality, but rather ask if a result is within a certain radius from a result. That means we measure convergence according to a metric, not equivalence. > > > ``` > class Ord m => Metric m a where > dist :: a -> a -> m > > a ~= b = dist a b <= epsilon > ``` > > * handling and propagation of different error values. > > That would require a rehash of both standard libraries and most mathematical algebra libraries for Haskell. > > For at least two reasons: > > * libraries assume a naive equality works for all types. Holds in a world of infinte precision and lossless operations, but never holds for approximations. > > * our propagation of universal error values is incomplete, and usually missing from complex algorithms. In other words `Either String` Monad does not work: we want collections of error values just like we have collections of inputs. > > Personally I will be overjoyed when our community finally gets the better type class library for approximated types. > > Would You agree to review a teaser if I post it here? > — > Cheers > Michał > > On Thu, 5 Aug 2021 at 10:41 YueCompl > wrote: > > At some point, Haskell should make provision for decimal floating point, > > as the current versions of IEEE 754 and C do, and that might be a good > > reorganisation time. > > > Yeah, I think this is the thing I'm anticipating, current standard classes favor lossless computation by the laws, but large portion of the computer numeric solutions are taking loss of precision for efficiency. And neural systems even right following this approach as far as it appears, I sincerely hope Haskell can embrace it to some degree. > > > > On 2021-08-05, at 15:26, Richard O'Keefe > wrote: > > > > You quoted > > "> Note that due to the presence of @NaN@, not all elements of 'Float' > > have an additive inverse." > > > > Let x y and z be finite floating-point numbers such that x + y ==> z. > > Does there always exist neg(y) such that z + neg(y) ==> x? > > NO. > > > > And the presence or absence of NaN in the system makes no difference. > > If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly. > > That is, (x + y) - y == 0, but x is not 0. > > > > In the presence of rounding, additive inverses do not in general exist. > > Neither do multiplicative inverses. > > > > Also addition and multiplication are not associative, but you knew that. > > The only reason Float and Double are in Num is because Haskell doesn't > > offer ad hoc overloading. People have been saying that the Prelude needs > > refactoring for years. > > > > The main thing that NaN wrecks that wasn't already broken is Eq. I would > > argue that the right decision there would have been to rule that x == y > > (when x and y are floating point numbers) precisely when x and y are > > represented by the same bit pattern, with a separate operation for IEEE > > "ordered and equal". > > > > At some point, Haskell should make provision for decimal floating point, > > as the current versions of IEEE 754 and C do, and that might be a good > > reorganisation time. > > > > > > On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe > > > wrote: > >> > >> Thanks Michał, > >> > >> I feel less confused as I realized the non-halting possibility per bottoms, from your hint. > >> > >> I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. > >> > >> Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > >> > >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. > >> > >>> Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity > >> > >>> Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. > >> > >> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: > >> > >> * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable > >> * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? > >> * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? > >> > >> No such family of `Num` classes exists to my aware by now, I just can't help wondering why. > >> > >> Cheers, > >> Compl > >> > >> On 2021-08-04, at 02:38, Michał J Gajda > wrote: > >> > >> Dear Yue, > >> > >> Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! > >> > >> Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. > >> > >> Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. > >> > >> The problem with this approach is indeed a silent handling. > >> > >> But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > >> > >> Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. > >> -- > >> Cheers > >> Michał > >> > >> > >> _______________________________________________ > >> 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. > > -- > Pozdrawiam > Michał -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at icloud.com Mon Aug 9 11:51:36 2021 From: compl.yue at icloud.com (YueCompl) Date: Mon, 9 Aug 2021 19:51:36 +0800 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: <7e2587df761322041068d76cefb047b1e566a406.camel@aatal-apotheke.de> <7146ADF7-D147-45EE-B5B7-4B4F8C501187@icloud.com> <7619187F-3F39-470F-B2B2-11884A7A7E18@icloud.com> <671C9BA0-5FB9-4C1E-BC73-834A4D00DBA0@icloud.com> <2452CA59-5207-4053-AC59-EFFDD660AC4B@icloud.com> Message-ID: <7B8A977D-C496-4AAE-992C-84FB714C921F@icloud.com> Thanks Olaf, The surreal implementation should help a lot for me to understand the ideas deep enough. I developed the habit to understand things by tweaking code one little bit a time, and see the differences I made, to get intuitions about how it works, that's due to my career as a software engineer / hacker I guess. I already felt the difference with Haskell in software engineering practices, than with other programming communities, and I'm quite happy that I can enjoy the beauty of math here, though I'm some slow in understanding things mathematically. I think I just need more time :-) Best regards, Compl > On 2021-08-08, at 04:54, Olaf Klinke wrote: > > Dear Compl, > > Apologies, my code was meant as math formula in Haskell syntax. > For starters, something like > [x*y | x <- xs, y <- ys] > will not go past the first element of xs if the other list ys is > infinite. Hence you need another way to enumerate an infinite 2-D grid. > I also used the symbol Q as shorthand for "a list that is cofinal in > the set Q" which in case of lower approximants can be [1..] and in the > case of upper approximants can be (fmap recip [1..]). > If you can maintain the invariant that both lists of approximants are > ascending or descending, respecively, then you can replace the above > list comprehension by > zipWith (*) xs ys > which will also be much faster and does the right thing if one list is > empty and the other is infinite. > > Further I wouldn't go directly for a full Num instance but define the > arithmetic functions one by one under a different name. That way the > "No explicit implementation for ..." doesn't bite you. Once you have > defined all, the Num instance is just aliasing the Num functions with > your type-specific ones. > > For division, you need to think this way: I have a quotient a/b. When I > wobble a or b in either direction, does the quotient get smaller (lower > approximant) or larger (upper approximant)? Clearly, when replacing a > by one of its lower approximants x, then x/b < a/b. (This is only true > because we're excluding negative numbers!) Likewise for upper > approximants to a. Next, if b is replaced by one of its upper > approximants y', then x/y' < x/b < a/b. We conclude that the lower > approximants of a/b are of the form x/y' where x is a lower approximant > of a and y' is an upper approximant of b. > > When you're done, you will have implemented exact real arithmetic, > which does not suffer from the rounding errors but is usually also much > slower than floating point arithmetic. And as a by-product you will > have a proof that NaN is the price we must pay for totality of (/) and > (*). > > I also attach a chapter from my monograph "Haskell for mathematicians" > which is a literate program containing three different implementations > of exact reals in Haskell, Conway's surreal numbers being one of them, > as well as a more comprehensive surreal numbers implementation. > > Olaf > > On Sat, 2021-08-07 at 18:21 +0800, YueCompl wrote: >> Okay, I got it working to some extent: >> (and I find it a good showcase for my https://marketplace.visualstudio.com/items?itemName=ComplYue.vscode-ghci extension, improved it a bit to support this very scenario, with the src file at https://github.com/complyue/typing.hs/blob/main/src/PoC/Floating.hs ) >> >> >> >> Obviously my naive implementation `(l, r) / (l', r') = ([x / x' | x <- l, x' <- l'], [y / y' | y <- r, y' <- r'])` is wrong, I think I need to figure out how to represent 1 (the unit number) of this type, even before I can come to a correct definition of the division (/) operation, but so far no clue ... >> >>> On 2021-08-07, at 16:16, YueCompl via Haskell-Cafe wrote: >>> >>> Another failed attempt: >>> >>> λ> :set -XTypeSynonymInstances >>> λ> :set -XFlexibleInstances >>> λ> >>> λ> data Q = Q >>> λ> >>> λ> type NonNegativeNumber = ([Q],[Q]) >>> λ> :{ >>> λ| instance Num NonNegativeNumber where >>> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) >>> λ| :} >>> >>> :12:25: error: >>> • No instance for (Num Q) arising from a use of ‘*’ >>> • In the expression: x * x' >>> In the expression: [x * x' | x <- l, x' <- l'] >>> In the expression: >>> ([x * x' | x <- l, x' <- l'], [y * y' | y <- r, y' <- r']) >>> λ> >>> λ> zero = ([],Q) >>> λ> infty = (Q,[]) >>> λ> zero * infty >>> >>> :17:8: error: >>> • Couldn't match type ‘Q’ with ‘[a]’ >>> Expected type: ([a], Q) >>> Actual type: (Q, [a0]) >>> • In the second argument of ‘(*)’, namely ‘infty’ >>> In the expression: zero * infty >>> In an equation for ‘it’: it = zero * infty >>> • Relevant bindings include >>> it :: ([a], Q) (bound at :17:1) >>> λ> >>> >>> >>>> On 2021-08-07, at 15:35, YueCompl via Haskell-Cafe > wrote: >>>> >>>> Great! I'm intrigued by the idea that GHCi can make such math sentences runnable! I've never thought it this way before. >>>> >>>> But I need some help to get it going: >>>> >>>> λ> :set -XTypeSynonymInstances >>>> λ> :set -XFlexibleInstances >>>> λ> >>>> λ> import Data.Ratio >>>> λ> type Q = Rational -- this is probably wrong ... >>>> λ> >>>> λ> type NonNegativeNumber = ([Q],[Q]) >>>> λ> :{ >>>> λ| instance Num NonNegativeNumber where >>>> λ| (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) >>>> λ| :} >>>> >>>> :9:12: warning: [-Wmissing-methods] >>>> • No explicit implementation for >>>> ‘+’, ‘abs’, ‘signum’, ‘fromInteger’, and (either ‘negate’ or ‘-’) >>>> • In the instance declaration for ‘Num NonNegativeNumber’ >>>> λ> >>>> λ> zero = ([],Q) >>>> >>>> :13:13: error: Data constructor not in scope: Q >>>> λ> infty = (Q,[]) >>>> >>>> :14:10: error: Data constructor not in scope: Q >>>> λ> >>>> λ> zero * infty -- expect: = ([],[]) >>>> >>>> :16:1: error: Variable not in scope: zero >>>> >>>> :16:8: error: Variable not in scope: infty >>>> λ> >>>> >>>> I'd like to do more exercises, but I'm stuck here ... >>>> >>>> >>>>> On 2021-08-07, at 06:16, Olaf Klinke > wrote: >>>>> >>>>> On Fri, 2021-08-06 at 22:21 +0800, YueCompl wrote: >>>>>> Thanks Olaf, >>>>>> >>>>>> Metaphors to other constructs are quite inspiring to me, though I don't have sufficient theoretical background to fully understand them atm. >>>>>> >>>>> Pen-and-paper or GHCi experiments suffice here, no fancy theoretical >>>>> background needed. Say Q is the type of rationals 0 < q and we express >>>>> type NonNegativeNumber = ([Q],[Q]) >>>>> where the first (infinite) list is the lower approximants and the >>>>> second the upper approximants. Multiplication is then defined as >>>>> (l,r) * (l',r') = ([x*x'|x <- l, x' <- l'],[y*y'|y <- r, y' <- r']) >>>>> The extremes of this type are >>>>> 0 = ([],Q) >>>>> infty = (Q,[]) >>>>> It is easily seen that >>>>> 0 * infty = ([],[]) >>>>> a number with no lower and no upper approximants, in other words, NaN. >>>>> Excercise: Define division for this type and find out what 1/0 and 0/0 >>>>> is. >>>>> >>>>>> Am I understanding it right, that you mean `0/0` is hopeful to get ratified as "a special Float value corresponding to one non-proper Dedekind-cuts", but `NaN` as with IEEE semantics is so broken that it can only live outlaw, even Haskell the language shall decide to bless it? >>>>>> >>>>> Yes. I think it is vital that we provide a migration path for >>>>> programmers coming from other languages. Under the Dedekind >>>>> cut/interval interpretation, NaN would behave differently, as I pointed >>>>> out. So I'd leave Float as it is, but be more verbose about its >>>>> violation of type class laws. To this end, one could have (and now I >>>>> might be closer to your initial question) numerical type classes like >>>>> HonestEq, HonestOrd, HonestMonoid and HonestRing whose members are only >>>>> those types that obey the laws in all elements. Naturally, Float would >>>>> not be a member. Who would use these new classes? Probably no one, >>>>> because we all like to take the quick and dirty route. But at least it >>>>> says clearly: Careful, you can not rely on these laws when using Float. >>>>> >>>>> 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. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. > > From olf at aatal-apotheke.de Mon Aug 9 21:59:58 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 09 Aug 2021 23:59:58 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? Message-ID: <4371a0a10fc612ece9a8b73ba2ed26e321487bac.camel@aatal-apotheke.de> > * libraries assume a naive equality works for all types. Holds in a world > of infinte precision and lossless operations, but never holds for > approximations. > > * our propagation of universal error values is incomplete, and usually > missing from complex algorithms. In other words `Either String` Monad does > not work: we want collections of error values just like we have collections > of inputs. > > Personally I will be overjoyed when our community finally gets the better > type class library for approximated types. > > Would You agree to review a teaser if I post it here? Yes, please. I'm curious whether there is a single abstraction that can describe both finite precision with variable errors as well as potentially infinite precision with known errors. Olaf From johannes.waldmann at htwk-leipzig.de Tue Aug 10 14:32:27 2021 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Tue, 10 Aug 2021 16:32:27 +0200 Subject: [Haskell-cafe] Organizing your code files Message-ID: Hécate: > * Type variables are made explicit, and as such I annotate even the > simplest of them (with `:: Type`) This! I am moving towards that style. Especially in teaching (type abstraction, type application) where I want everything to be very much explicit - before discussing abbreviations and omissions (type inference). With current GHC, this is entirely possible but looks somewhat clumsy {-# language ExplicitForall, KindSignatures #-} import Data.Kind (Type) g :: forall (t :: Type) . t -> t ; g x = x {-# language TypeApplications #-} g @N Z yes I could hide these pragmas somewhere but that again feels wrong. But - good thing: after https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst (I understand that GHC2021 is default-enabled in GHC-9.2) we no longer need to write these pragmas. Yay! Sadly, we still need the import. - J. NB: Haskell's implicit declaration of type variables by their starting with lowercase letters always reminds me of Fortran's implicit type specification for variables, going by the first letter (I .. N means integer). Fortran has "implicit none" though, so let's have "t :: Type"... From benjamin.redelings at gmail.com Tue Aug 10 15:57:15 2021 From: benjamin.redelings at gmail.com (Benjamin Redelings) Date: Tue, 10 Aug 2021 11:57:15 -0400 Subject: [Haskell-cafe] Help on syntactic sugar for combining lazy & strict monads? In-Reply-To: References: Message-ID: <379f9543-ac04-a459-ddb1-cec1732d22d5@gmail.com> Hi Olaf, If you recall, I actually wrote to this list asking for help. Adam Scibior's response was quite helpful, but this conversation, as far as I can tell, has not provided any help, so I will regretfully have to stop replying at some point.  Unfortunately, I don't have enough time to respond to everything - my apologies! I may be able to clarify some of the questions that you asked. But I doubt that I can actually satisfy all of your concerns.  So, perhaps these responses will mostly clarify our points of disagreement. 1. It seems like you are assuming that the semantics of a probabilistic program is determined by running it under a rejection sampling interpreter.  Such an interpreter would:   (a) interpret statements like "x <- normal 0 1" by performing a (pseudo)random sample from the distribution   (b) interpret statements like "2.0 `observed_from` normal z 1`" by first sampling from "normal z 1" and then rejecting the program run if the sample from "normal z 1" does not satisfy (2.0==). That is a rejection sampler, and it would work if the observations did not have probability 0.  But it is only one kind of sampler.  There are other kinds of samplers, that you (maybe?) have not considered:   * importance sampling: the paper that I recommended is using the observation statements to weight the samples by the probability DENSITY of the observations.  This is called "importance sampling" -- we generate sampling from one distribution, but reweight them to approximate a different distribution.   * MCMC: my approach is based on MCMC, and so performs a random walk over the space of program traces.  In this case, running the program must compute the probability DENSITY of samples from the prior (like "x <- normal 0 1") as well as observations (like observing 2.0 from "normal z 1"). These three alternative interpreters are alternative ways of sampling from the posterior distribution.  However, none of these three interpreters constitutes the semantics of the probabilistic program. I mentioned the Giry monad (which I am no expert on) because it gives semantics that is not based on any interpreter.  I do not think that the semantics of probabilistic programs should be given by an interpreter.  Perhaps we disagree on this. 2. You wrote "If the observe_from statement is never demanded, then what semantics should it have?" > run_lazy $ do >    x <- normal 0 1 >    y <- normal x 1 >    z <- normal y 1 >    2.0 `observe_from` normal z 1 >    return y The semantics that it should have seems fairly obvious? This program leads to the following (un-normalized!) probability density on (x,y,z):     Pr(x) * Pr(y|x) * Pr(z|y) * Pr(2.0|z) = normal_pdf(x,0,1) * normal_pdf(y,x,1) * normal_pdf(z,y,1) * normal_pdf(2.0,z,1) Therefore, the program leads to both (i) a distribution on (x,y,z) and (ii) a distribution on the return value y. I don't think this has anything to to with whether there is a result that is demanded, but perhaps we disagree on that. 3. You wrote "But conditioning usually is a function "Observation a -> Dist a -> Dist a" so you must use the result of the conditioning somehow." I was initially very confused by this, because it sounded like you are saying that because people USUALLY do something, therefore I HAVE AN OBLIGATION to do something.  But, now I realize that you mean "IT MUST BE THE CASE that you use the result of the conditioning somehow".  It is indeed the case that the "observe_from" command affects the intepreter somehow. I think this is pretty simple ... the `observe_from` statement has a side-effect.  For both (i) importance-sampling interpreters and (ii) MCMC interpreters, the side-effect is to weight the current trace by the probability (or probability density) of the observation. However, like the "put" command in the state monad, the result "()" of the observation is not demanded.  So in that sense, I am not "using the result".  It is perhaps interesting that the lazy state monad does not have the problem that "put" commands are ignored. 4. You wrote "And isn't the principle of Monte Carlo to approximate the posterior by sampling from it?" I am not really sure what this means.  Sometimes you can generate samples directly from the posterior, and sometimes you can't.  In most situations where you have observations, you CANNOT generate samples from the posterior. For example, in MCMC, we talk about the distribution of the sampled points CONVERGING to the posterior.  If an MCMC chain has points X[t] for t = 0...\infty, there is no t where X[t] is distributed according to the posterior distribution. 5. You wrote "I claim that once you have typed everything, it becomes clear where the problem is." That is an interesting claim.  I don't think that there is actually "problem" per se, so I am not were that typing everything can reveal where it is.  Also, this exact same issue comes up in the Practical Probabilistic Programming with Monads paper, and they have typed everything.  So, I guess I disbelieve this claim, until I see evidence to the contrary. I guess we will see, after I finish programming the type system. 6. You wrote: > I believe I understand the Giry monad well, and it is my measuring > stick for functional probabilistic programming. Even more well-suited > for programming ought to be the valuation monad, because that is a > monad on domains, the [*] semantic spaces of the lambda calculus. > Unfortunately, to my knowledge until now attempts were unsuccessful to > find a cartesian closed category of domains which is also closed under > this probabilistic powerdomain construction. > > [*] There are of course other semantics, domains being one option. Given your expertise in this area, I doubt that I can shed any light on this.  I presume that you have read https://arxiv.org/pdf/1811.04196.pdf, and similar papers.  This is getting pretty far afield from my original question. 7. You wrote: >> >> 2. The paper "Practical Probabilistic Programming with Monads" - >> https://doi.org/10.1145/2804302.2804317 > > Wasn't that what you linked to in your original post? As said above, > measure spaces is the wrong target category, in my opinion. There is > too much non constructive stuff in there. See the work of Culbertson > and Sturtz, which is categorically nice but not very constructive. The link was indeed in my original post, but it did not seem like you had read it, since you did not consider the possibility of probabilistic programs generating WEIGHTED samples. Also, the idea that probabilistic programs should not yield measures seems weird.  Partly because I am not sure what your alternative is, and partly because everybody else seems to disagree with you.  For example, the following paper assumes measures: https://link.springer.com/chapter/10.1007/978-3-030-72019-3_16 Again, this is getting pretty far away from my original question. 8. You wrote: > Perhaps I am being too much of a point-free topologist here. Call me > pedantic. Or I don't understand sampling at all. To me, a point is an > idealised object, only open sets really exist and are observable. If > the space is discrete, points are open sets. But on the real line you > can not measure with infinite precision, so any observation must > contain an interval. That aligns very nicely with functional > programming, where only finite parts of infinite lazy structures are > ever observable, and these finite parts are the open sets in the > domain semantics. So please explain how observing 2.0 from a > continuous distribution is not nonsensical. You haven't actually shown that observing 2.0 from a continuous distribution is nonsensical.  What you have done is stated that you don't like it, and that you would like people to represent observations as intervals instead of points.  However, its not my job to convince you that point observations make sense, so I think I'll just leave that where it is. OK, that's enough for now. -BenRI On 7/22/21 2:15 AM, Olaf Klinke wrote: >> However, a lazy interpreter causes problems when trying to introduce >> *observation* statements (aka conditioning statements) into the monad >> [3].  For example, >> >> run_lazy $ do >>    x <- normal 0 1 >>    y <- normal x 1 >>    z <- normal y 1 >>    2.0 `observe_from` normal z 1 >>    return y >> >> In the above code fragment, y will be forced because it is returned, and >> y will force x.  However, the "observe_from" statement will never be >> forced, because it does not produce a result that is demanded. > > I'm very confused. If the observe_from statement is never demanded, > then what semantics should it have? What is the type of observe_from? > It seems it is > a -> m a -> m () > for whatever monad m you are using. But conditioning usually is a > function > Observation a -> Dist a -> Dist a > so you must use the result of the conditioning somehow. And isn't the > principle of Monte Carlo to approximate the posterior by sampling from > it? I tend to agree with your suggestion that observations and > sampling can not be mixed (in the same do-notation) but the latter > have to be collected in a prior, then conditioned by an observation. > > What is the semantic connection between your sample and obsersvation > monad? What is the connection between both and the semantic > probability distributions? I claim that once you have typed > everything, it becomes clear where the problem is. > > Olaf > > P.S. It has always bugged me that probabilists use elements and events > interchangingly, while this can only be done on discrete spaces. So > above I would rather like to write > (2.0==) `observe_from` (normal 0 1) > which still is a non-sensical statement if (normal 0 1) is a > continuous distribution where each point set has probability zero. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.protzenko at gmail.com Wed Aug 11 21:14:02 2021 From: jonathan.protzenko at gmail.com (Jonathan Protzenko) Date: Wed, 11 Aug 2021 14:14:02 -0700 Subject: [Haskell-cafe] Call for participation: ML Family Workshop 2021 Message-ID: We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. We invite you to subscribe to, and attend the workshop, in addition to the main ICFP conference. We are thrilled to announce that Don Syme will give this year's keynote: "Narratives and Lessons from The Early History of F#". Please join us! The program features 14 exciting submissions, including 4 short talks. The workshop will be held online in the 6pm-3am time band (Seoul Time). Talks will be pre-recorded and uploaded online for those who cannot attend. * Program: https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#program * Keynote: https://icfp21.sigplan.org/details/mlfamilyworkshop-2021-papers/15/Keynote-Narratives-and-Lessons-from-The-Early-History-of-F- * ICFP home: http://icfp21.sigplan.org/home ## Program committee Danel Ahman (University of Ljubljana) Robert Atkey (University of Strathclyde) Frédéric Bour (Tarides) Ezgi Çiçek (Facebook London) Youyou Cong (Tokyo Institute of Technology) Richard A. Eisenberg (Tweag I/O) Martin Elsman (University of Copenhagen, Denmark) Ohad Kammar (University of Edinburgh) Naoki Kobayashi (University of Tokyo, Japan) Benoît Montagu (Inria) Jonathan Protzenko (Microsoft Research) (Chair) Kristina Sojakova (INRIA Paris) Don Syme (Microsoft) Matías Toro (University of Chile) Katsuhiro Ueno (Tohoku University) From christopher at conforti.xyz Wed Aug 11 22:27:46 2021 From: christopher at conforti.xyz (Christopher Conforti) Date: Wed, 11 Aug 2021 18:27:46 -0400 Subject: [Haskell-cafe] Organizing your code files In-Reply-To: <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> References: <20210807151845.6b80d63d@ccc-pc.confortihome.net> <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> Message-ID: <20210811182746.02e5ec71@ccc-pc.confortihome.net> On Sun, 8 Aug 2021 08:50:24 +0200 Hécate wrote: > On my end, I make use of automated style formatters, so that this > kind of thing can be kept consistent during CI. I invite you not to > think too much about the micro-details of code styles, but rather > find a tool that you can configure so that your style can be enforced > automatically. You'll be able to spend more cycles on programme > development. Indeed, this is the direction I'm heading. However, I'm doing it by hand first so I can refine my methods to a point I'm satisfied with, and then build the automation afterwards, hopefully doing it right the first time. I place value on this because I plan to stick with the same style throughout all my code so that I can read and reuse my own code 30 years from now and not have to think about how much I hate past me. The sort of information I'm after answers questions similar to and including, "Why put this typeclass in this source file and not that one?" and "Should I put all my type signatures, typeclasses and data structures at the top? At the bottom? Should I put them in a separate source file?" Having outside perspectives from actual people that I'm having conversations with will help me both learn the finer points of the topic (from actual programmers) and piece together a strategy I'm happy with. On Sun, 8 Aug 2021 08:50:24 +0200 Hécate wrote: > Note that: > > * Type variables are made explicit, and as such I annotate even the > simplest of them (with `:: Type`) > * I align the separators (., => and ->) > * I use stylish-haskell & hlint > * If you want finer automated control, try something like Britanny. Your code is a pleasure to read; I shall enjoy studying it. :-) -- Christopher Conforti -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hecate at glitchbra.in Thu Aug 12 05:39:56 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 12 Aug 2021 07:39:56 +0200 Subject: [Haskell-cafe] Organizing your code files In-Reply-To: <20210811182746.02e5ec71@ccc-pc.confortihome.net> References: <20210807151845.6b80d63d@ccc-pc.confortihome.net> <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> <20210811182746.02e5ec71@ccc-pc.confortihome.net> Message-ID: I think I can provide answers to those questions, based on what I have seen in the ecosystem so far: > Why put this typeclass in this source file and not that one? As you may know, modules can export other modules they depend on, but I would advise to put the typeclass definition in its own .Class module, such as Control.Monad.IO.Class . > Should I put all my type signatures, typeclasses and data structures at the top? At the bottom? Should I put them in a separate source file? Here is the layout I have seen most used: module   ( export1   , export2   ) where imports data types instances type aliases newtypes instances functions (main API) functions (helpers) More generally at the project level, make sure you have a tree with few chokepoints. I encourage you to read this article https://www.parsonsmatt.org/2019/11/27/keeping_compilation_fast.html. Cheers. PS: > I can read and reuse my own code 30 years from now and not have to think about how much I hate past me. This is bound to happen whether or not you have a strong & enforced formatting style. We simply grow up as programmers with time. Le 12/08/2021 à 00:27, Christopher Conforti a écrit : > On Sun, 8 Aug 2021 08:50:24 +0200 > Hécate wrote: > >> On my end, I make use of automated style formatters, so that this >> kind of thing can be kept consistent during CI. I invite you not to >> think too much about the micro-details of code styles, but rather >> find a tool that you can configure so that your style can be enforced >> automatically. You'll be able to spend more cycles on programme >> development. > Indeed, this is the direction I'm heading. However, I'm doing it by > hand first so I can refine my methods to a point I'm satisfied with, > and then build the automation afterwards, hopefully doing it right the > first time. I place value on this because I plan to stick with the same > style throughout all my code so that I can read and reuse my own code 30 > years from now and not have to think about how much I hate past me. > > The sort of information I'm after answers questions similar to and > including, "Why put this typeclass in this source file and not that > one?" and "Should I put all my type signatures, typeclasses and data > structures at the top? At the bottom? Should I put them in a separate > source file?" > > Having outside perspectives from actual people that I'm having > conversations with will help me both learn the finer points of the > topic (from actual programmers) and piece together a strategy I'm happy > with. > > On Sun, 8 Aug 2021 08:50:24 +0200 > Hécate wrote: >> Note that: >> >> * Type variables are made explicit, and as such I annotate even the >> simplest of them (with `:: Type`) >> * I align the separators (., => and ->) >> * I use stylish-haskell & hlint >> * If you want finer automated control, try something like Britanny. > Your code is a pleasure to read; I shall enjoy studying it. :-) > > > _______________________________________________ > 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. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu Aug 12 06:12:26 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 12 Aug 2021 08:12:26 +0200 (CEST) Subject: [Haskell-cafe] Organizing your code files In-Reply-To: References: <20210807151845.6b80d63d@ccc-pc.confortihome.net> <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> <20210811182746.02e5ec71@ccc-pc.confortihome.net> Message-ID: <6516c265-e993-f8d2-6698-29b474952e5d@henning-thielemann.de> On Thu, 12 Aug 2021, Hécate wrote: > Here is the layout I have seen most used: > > module >   ( export1 >   , export2 >   ) where I prefer terminator style, because that simplifies re-ordering of lines: module ( export1, export2, ) where > More generally at the project level, make sure you have a tree with few chokepoints. I encourage you to read this article > https://www.parsonsmatt.org/2019/11/27/keeping_compilation_fast.html. I second to avoid a big Types module. I propose to define one module per major type, name the module after the type, such that you can make use of qualification, like Text.concat, Window.open, Path.join, Matrix.transpose. You may still need Private modules in order to break import cycles and share secret definitions between the modules. From svenpanne at gmail.com Thu Aug 12 07:06:18 2021 From: svenpanne at gmail.com (Sven Panne) Date: Thu, 12 Aug 2021 09:06:18 +0200 Subject: [Haskell-cafe] Organizing your code files In-Reply-To: <20210811182746.02e5ec71@ccc-pc.confortihome.net> References: <20210807151845.6b80d63d@ccc-pc.confortihome.net> <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> <20210811182746.02e5ec71@ccc-pc.confortihome.net> Message-ID: Am Do., 12. Aug. 2021 um 00:33 Uhr schrieb Christopher Conforti < christopher at conforti.xyz>: > Indeed, this is the direction I'm heading. However, I'm doing it by > hand first so I can refine my methods to a point I'm satisfied with, > and then build the automation afterwards, hopefully doing it right the > first time. [...] IMHO this is exactly the wrong way round: Pick one of the existing formatters (hindent, brittany, ormolu, ...) and stick with it for a while. If you don't like what you see, you can try another one. But the main point is: These formatters embody good practice learned the hard way from lots of other people, and using them will make your code more readable not only by you, but by others, too. The "not invented here" syndrome is seldom a good idea, and consistency is far more important than small details you might not like. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu Aug 12 14:59:03 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 12 Aug 2021 07:59:03 -0700 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: Well said. I do think signalling nans as a runtime flag option that converts them into exceptions is still a pretty viable option. The right hooks in the rts are there ! On Thu, Aug 5, 2021 at 12:28 AM Richard O'Keefe wrote: > You quoted > "> Note that due to the presence of @NaN@, not all elements of 'Float' > have an additive inverse." > > Let x y and z be finite floating-point numbers such that x + y ==> z. > Does there always exist neg(y) such that z + neg(y) ==> x? > NO. > > And the presence or absence of NaN in the system makes no difference. > If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly. > That is, (x + y) - y == 0, but x is not 0. > > In the presence of rounding, additive inverses do not in general exist. > Neither do multiplicative inverses. > > Also addition and multiplication are not associative, but you knew that. > The only reason Float and Double are in Num is because Haskell doesn't > offer ad hoc overloading. People have been saying that the Prelude needs > refactoring for years. > > The main thing that NaN wrecks that wasn't already broken is Eq. I would > argue that the right decision there would have been to rule that x == y > (when x and y are floating point numbers) precisely when x and y are > represented by the same bit pattern, with a separate operation for IEEE > "ordered and equal". > > At some point, Haskell should make provision for decimal floating point, > as the current versions of IEEE 754 and C do, and that might be a good > reorganisation time. > > > On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe > wrote: > > > > Thanks Michał, > > > > I feel less confused as I realized the non-halting possibility per > bottoms, from your hint. > > > > I too think the signaling NaN is dreadful enough, so fortunately it's > rarely seen nowadays. > > > > Actually what's on my mind was roughly something like "Maybe on > steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, > as seen at > https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs > > > > > Note that due to the presence of @NaN@, not all elements of 'Float' > have an additive inverse. > > > > > Also note that due to the presence of -0, Float's 'Num' instance > doesn't have an additive identity > > > > > Note that due to the presence of @NaN@, not all elements of 'Float' > have an multiplicative inverse. > > > > So it should have been another family of `Num` classes, within which, > various NaN related semantics can be legal, amongst which I'd think: > > > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, > seems quite acceptable > > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground > or not? > > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's > a theoretical framework for this to hold? Maybe `Boolean` type needs > enhancement too to do it? > > > > No such family of `Num` classes exists to my aware by now, I just can't > help wondering why. > > > > Cheers, > > Compl > > > > On 2021-08-04, at 02:38, Michał J Gajda wrote: > > > > Dear Yue, > > > > Bottom has much weaker semantics than an exception: it means You may > never get a result and thus will never handle it! > > > > Another reason is convenience: it is frequently the case that giving NaN > in a row of numbers is much more informative than crashing a program with > an exception and never printing the result anyway. > > > > Finally IEEE special values have clear propagation semantics: they are > basically Maybe on steroids. > > > > The problem with this approach is indeed a silent handling. > > > > But in order to fix this, it is better to add preconditions to specific > algorithms that do not allow IEEE special value on input (`isFinite` or > `isNotNaN`) and then track the origin of the special value with the methods > like those described here: > https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding > > > > Never throw an error without telling exactly why it happened and exactly > where to fix it :-). Using bottom is last resort; exceptions likewise. > > -- > > Cheers > > Michał > > > > > > _______________________________________________ > > 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 ruben.astud at gmail.com Thu Aug 12 15:41:04 2021 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Thu, 12 Aug 2021 11:41:04 -0400 Subject: [Haskell-cafe] Different advice for type classes for end-user app and libraries? Message-ID: Hello list! Currently I am working a end user application. Through the years I had incorporated the advice from r/haskell that classes without laws were not desirable. Their lack meant that we didn't have a contract boundary that should be respected by the instances. They secretly could `throw exc` on their implementation and you wouldn't notice. But on the current app I am working on, I follow the advice from this blogpost [1] that I should use classes for domain modelling. This manifest on classes like class UserQueryCapability f where getUser :: Id -> f User for interacting with a DB. Functions can be written against the interface and I can mock up with QuickCheck some pretty broad cases. The classes usually don't have a superclass constrain on `Monad` as in `MonadReader` because I *cannot* establish a law relating the monadic behavior and `getUser`. The name has Capability in it and not Monad because I won't lie that way. Making sure that these effect classes are orthogonal is something I have to check by hand. But in the back of my head there is the concern about the lack of laws could bite me even on a end user-app. Is my intuition well founded that this case is OK? Thanks for your time! [1]: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html -- -- Rubén. pgp: 4EE9 28F7 932E F4AD From mgajda at mimuw.edu.pl Thu Aug 12 16:21:42 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Thu, 12 Aug 2021 18:21:42 +0200 Subject: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom? In-Reply-To: References: Message-ID: It would be very kind if You contributed an example code for these. I do not think anybody else in the discussion knows RTS as well as You. Cheers M czw., 12 sie 2021, 16:59 użytkownik Carter Schonwald < carter.schonwald at gmail.com> napisał: > Well said. > > I do think signalling nans as a runtime flag option that converts them > into exceptions is still a pretty viable option. The right hooks in the > rts are there ! > > On Thu, Aug 5, 2021 at 12:28 AM Richard O'Keefe wrote: > >> You quoted >> "> Note that due to the presence of @NaN@, not all elements of 'Float' >> have an additive inverse." >> >> Let x y and z be finite floating-point numbers such that x + y ==> z. >> Does there always exist neg(y) such that z + neg(y) ==> x? >> NO. >> >> And the presence or absence of NaN in the system makes no difference. >> If, for example, you add 1.0e-18 to 1.0e0, the answer is 1.0e0 exactly. >> That is, (x + y) - y == 0, but x is not 0. >> >> In the presence of rounding, additive inverses do not in general exist. >> Neither do multiplicative inverses. >> >> Also addition and multiplication are not associative, but you knew that. >> The only reason Float and Double are in Num is because Haskell doesn't >> offer ad hoc overloading. People have been saying that the Prelude needs >> refactoring for years. >> >> The main thing that NaN wrecks that wasn't already broken is Eq. I would >> argue that the right decision there would have been to rule that x == y >> (when x and y are floating point numbers) precisely when x and y are >> represented by the same bit pattern, with a separate operation for IEEE >> "ordered and equal". >> >> At some point, Haskell should make provision for decimal floating point, >> as the current versions of IEEE 754 and C do, and that might be a good >> reorganisation time. >> >> >> On Thu, 5 Aug 2021 at 02:05, YueCompl via Haskell-Cafe >> wrote: >> > >> > Thanks Michał, >> > >> > I feel less confused as I realized the non-halting possibility per >> bottoms, from your hint. >> > >> > I too think the signaling NaN is dreadful enough, so fortunately it's >> rarely seen nowadays. >> > >> > Actually what's on my mind was roughly something like "Maybe on >> steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, >> as seen at >> https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs >> > >> > > Note that due to the presence of @NaN@, not all elements of 'Float' >> have an additive inverse. >> > >> > > Also note that due to the presence of -0, Float's 'Num' instance >> doesn't have an additive identity >> > >> > > Note that due to the presence of @NaN@, not all elements of 'Float' >> have an multiplicative inverse. >> > >> > So it should have been another family of `Num` classes, within which, >> various NaN related semantics can be legal, amongst which I'd think: >> > >> > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, >> seems quite acceptable >> > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground >> or not? >> > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's >> a theoretical framework for this to hold? Maybe `Boolean` type needs >> enhancement too to do it? >> > >> > No such family of `Num` classes exists to my aware by now, I just can't >> help wondering why. >> > >> > Cheers, >> > Compl >> > >> > On 2021-08-04, at 02:38, Michał J Gajda wrote: >> > >> > Dear Yue, >> > >> > Bottom has much weaker semantics than an exception: it means You may >> never get a result and thus will never handle it! >> > >> > Another reason is convenience: it is frequently the case that giving >> NaN in a row of numbers is much more informative than crashing a program >> with an exception and never printing the result anyway. >> > >> > Finally IEEE special values have clear propagation semantics: they are >> basically Maybe on steroids. >> > >> > The problem with this approach is indeed a silent handling. >> > >> > But in order to fix this, it is better to add preconditions to specific >> algorithms that do not allow IEEE special value on input (`isFinite` or >> `isNotNaN`) and then track the origin of the special value with the methods >> like those described here: >> https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-in-haskell-a-case-study-of-multicloud-api-binding >> > >> > Never throw an error without telling exactly why it happened and >> exactly where to fix it :-). Using bottom is last resort; exceptions >> likewise. >> > -- >> > Cheers >> > Michał >> > >> > >> > _______________________________________________ >> > 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 hecate at glitchbra.in Thu Aug 12 16:29:47 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Thu, 12 Aug 2021 18:29:47 +0200 Subject: [Haskell-cafe] Different advice for type classes for end-user app and libraries? In-Reply-To: References: Message-ID: <8d0b7f22-e276-8604-282f-c86b69969fdd@glitchbra.in> You're using classes in the context of MTL in an effect system-ish fashion, which is not *quite* what was the original intent and wisdom of Typeclasses in Haskell. Here Typeclasses are being used to implement a query interface, which is not the most "natural" usage of ad-hoc polymorphism. As such, I wouldn't expect such typeclasses to fully comply to the customs of Typeclasses. Don't worry too much about it. You're already playing outside of the customary bounds for Typeclasses. :) Le 12/08/2021 à 17:41, Ruben Astudillo a écrit : > Hello list! > > Currently I am working a end user application. Through the years I had > incorporated the advice from r/haskell that classes without laws were not > desirable. Their lack meant that we didn't have a contract boundary that > should be respected by the instances. They secretly could `throw exc` on > their implementation and you wouldn't notice. > > But on the current app I am working on, I follow the advice from this > blogpost [1] that I should use classes for domain modelling. This manifest > on classes like > > class UserQueryCapability f where > getUser :: Id -> f User > > for interacting with a DB. Functions can be written against the interface > and I can mock up with QuickCheck some pretty broad cases. The classes > usually don't have a superclass constrain on `Monad` as in `MonadReader` > because I *cannot* establish a law relating the monadic behavior and > `getUser`. The name has Capability in it and not Monad because I won't lie > that way. > > Making sure that these effect classes are orthogonal is something I have to > check by hand. But in the back of my head there is the concern about the > lack of laws could bite me even on a end user-app. Is my intuition well > founded that this case is OK? > > Thanks for your time! > > [1]: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html > -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From jeffbrown.the at gmail.com Thu Aug 12 18:38:01 2021 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Thu, 12 Aug 2021 13:38:01 -0500 Subject: [Haskell-cafe] Organizing your code files In-Reply-To: References: <20210807151845.6b80d63d@ccc-pc.confortihome.net> <89698672-2535-a4d2-c751-e19ebe510d36@glitchbra.in> <20210811182746.02e5ec71@ccc-pc.confortihome.net> Message-ID: If you put calling functions before called ones, then when you reload GHCI and it dumps a lot of errors at you, the last one is usually a good place to start, because it depends on nothing else flagged as an error in the same module. Also I always flag mutually recursive functions or types with a hard-to-miss "PITFALL: mutually recursive with " comment, as those are easier to understand if you begin recognizing the mutual recursion. On Thu, Aug 12, 2021 at 2:11 AM Sven Panne wrote: > Am Do., 12. Aug. 2021 um 00:33 Uhr schrieb Christopher Conforti < > christopher at conforti.xyz>: > >> Indeed, this is the direction I'm heading. However, I'm doing it by >> hand first so I can refine my methods to a point I'm satisfied with, >> and then build the automation afterwards, hopefully doing it right the >> first time. [...] > > > IMHO this is exactly the wrong way round: Pick one of the existing > formatters (hindent, brittany, ormolu, ...) and stick with it for a while. > If you don't like what you see, you can try another one. But the main point > is: These formatters embody good practice learned the hard way from lots of > other people, and using them will make your code more readable not only by > you, but by others, too. The "not invented here" syndrome is seldom a good > idea, and consistency is far more important than small details you might > not like. > > Cheers, > S. > _______________________________________________ > 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. -- Jeff Brown | Jeffrey Benjamin Brown LinkedIn | Github | Twitter | Facebook | very old Website -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilypi at cohomolo.gy Fri Aug 13 00:24:20 2021 From: emilypi at cohomolo.gy (Emily Pillmore) Date: Fri, 13 Aug 2021 00:24:20 +0000 Subject: [Haskell-cafe] base64-bytestring memory corruption bug In-Reply-To: <9e5d736f-b40b-601a-c174-94b4f663941a@glitchbra.in> References: <9e5d736f-b40b-601a-c174-94b4f663941a@glitchbra.in> Message-ID: Happy to announce https://hackage.haskell.org/package/base64-bytestring-1.2.1.0 , with the fix. Thanks again for raising this. For future versions, there I'd like to put out an open invitation to the community  to help harden the existing baseN libraries. Feel free to get in touch with me on their respective issue trackers. Cheers, Emily On Tue, Aug 03, 2021 at 2:44 PM, Hécate < hecate at glitchbra.in > wrote: > > > > Wonderful, happy to know it's been resolved! > > > > Le 03/08/2021 à 05:40, Fraser Tweedale a écrit : > > >> >> >> A new proposed fix is being discussed in >> https:/ / github. com/ haskell/ base64-bytestring/ pull/ 46 ( >> https://github.com/haskell/base64-bytestring/pull/46 ). >> >> >> >> Expect a fix merged and new release sometime in the next few days. >> >> >> >> Big thanks to all involved in pinpointing and resolving this issue. >> >> >> >> Cheers, >> Fraser >> >> >> >> On Mon, Aug 02, 2021 at 11:52:52PM +0200, Hécate wrote: >> >> >>> >>> >>> Hi Fraser, do you have further information about this situation? >>> >>> >>> >>> Le 25/07/2021 à 07:50, Fraser Tweedale a écrit : >>> >>> >>>> >>>> >>>> Hello, >>>> >>>> >>>> >>>> I want to bring to wider attention a memory bug present in >>>> base64-bytestring[1]. In summary, in some cases too few bytes are >>>> allocated for the output when performing base64url decoding. This can lead >>>> to memory corruption (which I have observed[2]), and possibly crashes >>>> (which I have not observed). >>>> >>>> >>>> >>>> I submitted a pull request[2] that fixes the issue some days ago, but did >>>> not receive a response from the maintainers yet. I understand that >>>> maintainers may be busy or unavailable, and that is fine. So I am posting >>>> here mainly to ensure that USERS are aware of the issue. >>>> >>>> >>>> >>>> To maintainers: let me know if I can provider further assistance to >>>> resolve this issue and release a fix. >>>> >>>> >>>> >>>> [1] https:/ / github. com/ haskell/ base64-bytestring/ issues/ 44 ( >>>> https://github.com/haskell/base64-bytestring/issues/44 ) >>>> [2] https:/ / github. com/ frasertweedale/ hs-jose/ issues/ 102 ( >>>> https://github.com/frasertweedale/hs-jose/issues/102 ) >>>> [3] https:/ / github. com/ haskell/ base64-bytestring/ pull/ 45 ( >>>> https://github.com/haskell/base64-bytestring/pull/45 ) >>>> >>>> >>>> >>>> Thanks, >>>> Fraser >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. >>>> org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only >>>> members subscribed via the mailman list are allowed to post. >>>> >>>> >>> >>> >>> >>> -- >>> Hécate ✨ >>> 🐦: @TechnoEmpress >>> IRC: Hecate >>> WWW: https:/ / glitchbra. in ( https://glitchbra.in/ ) >>> RUN: BSD >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. >>> org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ) Only >>> members subscribed via the mailman list are allowed to post. >>> >>> >> >> > > > > -- > Hécate ✨ > 🐦: @TechnoEmpress > IRC: Hecate > WWW: https:/ / glitchbra. in ( https://glitchbra.in/ ) > RUN: BSD > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: http:/ / mail. haskell. > org/ cgi-bin/ mailman/ listinfo/ haskell-cafe ( > 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 mgajda at mimuw.edu.pl Fri Aug 13 13:05:19 2021 From: mgajda at mimuw.edu.pl (Michal J Gajda) Date: Fri, 13 Aug 2021 15:05:19 +0200 Subject: [Haskell-cafe] Different advice for type classes for end-user app and libraries? Message-ID: Dear Ruben, > Currently I am working a end user application. Through the years I had > incorporated the advice from r/haskell that classes without laws were not > desirable. Their lack meant that we didn't have a contract boundary that > should be respected by the instances. They secretly could `throw exc` on > their implementation and you wouldn't notice. Indeed you are right. This is especially pressing for the type classes that convey relations between multiple types. Luckily, diligent students of Haskell source code will find common patterns for the laws that occur -- see below. > But on the current app I am working on, I follow the advice from this > blogpost [1] that I should use classes for domain modelling. This manifest > on classes like > class UserQueryCapability f where > getUser :: Id -> f User Before we get to the laws, I would recommend that you use technique of "linguistic analysis" to find a better name for the class. If not, you may want to remove words that are implicit in the object. Class name of "UserQuery" may be better, because "capability" is implicit in the fact that it is a type class. See example here: https://olegchursin.medium.com/a-brief-introduction-to-domain-modeling-862a30b38353#f72f > for interacting with a DB. Functions can be written against the interface > and I can mock up with QuickCheck some pretty broad cases. The classes > usually don't have a superclass constrain on `Monad` as in `MonadReader` > because I *cannot* establish a law relating the monadic behavior and > `getUser`. The name has Capability in it and not Monad because I won't lie > that way. First method is to recognize a common pattern: you have a function that reads a part of the state. That means it is similar to `lookup userId <$> ask`. `ask` follows certain laws, and you may apply these laws here: getUser u >> getUser u == ask -- idempotence getUser u >> return () == return () -- no effect of reading To get inspiration for other laws you may look at how this type class interacts with other type classes that deal with `User` objects here. There are several other techniques that apply in special cases. For example if you have multiple self-contained implementations of a type class, you may use `quickspec` to get equational laws for different implementations, and look for common laws between different implementations. https://hackage.haskell.org/package/quickspec These two ways seem to be most applicable from the example you have provided so far. > Making sure that these effect classes are orthogonal is something I have to > check by hand. But in the back of my head there is the concern about the > lack of laws could bite me even on a end user-app. Is my intuition well > founded that this case is OK? Lack of laws may mean one of the following: * type class is not an abstraction and thus does not allow you to tell anything abstract about it * you may have undocumented tacit knowledge about the type class that gets lost in the implementation * your users will find it harder to use type class as interface (as it is intended to be used). Advert: If the above description is insufficient, and the task is too challenging to fully solve within haskell-cafe mailing list, you may contact https://www.migamake.com for consulting on type class design and training. We do provide business analysis for Haskell projects too. -- All the best Michał From zubin at well-typed.com Sat Aug 14 13:10:06 2021 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 14 Aug 2021 18:40:06 +0530 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 8.10.6 released Message-ID: <20210814131006.ttd55aaxh6etlq43@zubin-msi> The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.6/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_6.html Blog Post: https://www.haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html This is a bugfix release, fixing many issues present in GHC 8.10.5, including: - A fix for segmentation faults in GHCi on `aarch64-darwin` due to an incorrect foreign import in `haskeline`. See [this blog post](https://www.haskell.org/ghc/blog/20210709-capi-usage.html) by Ben Gamari for more details on how your library could be affected. - A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763). - No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959). - Numerous bug fixes for the new LLVM based `aarch64-darwin` backend (#20132). - Fixes and stability improvements for the non-moving GC (#19715). - Many other bug fixes for the RTS (#18033, #20132, #20093, #19421). - Many packaging related fixes, including versioned `ghc-pkg` executables (#20087), and actually distributing GHC versions linked against the `integer-simple` big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the `GMP` library due to a misconfiguration of the builders. - A significant refactoring of `process` fixing numerous bugs mostly on Apple platforms (#19994, [process refactoring](https://github.com/haskell/process/pull/208)). - A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948). - Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950). A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.6-notes.html). As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From dwincort at gmail.com Sat Aug 14 21:34:11 2021 From: dwincort at gmail.com (Daniel Winograd-Cort) Date: Sat, 14 Aug 2021 17:34:11 -0400 Subject: [Haskell-cafe] Functional Art, Music, Modeling and Design (FARM 2021) Aug 21: Call for Participation Message-ID: ====================================================================== FARM 2021 9th ACM SIGPLAN International Workshop on Functional Art, Music, Modeling and Design 27 August, 2021, co-virtual with ICFP 2021 https://functional-art.org/2021/ ====================================================================== The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. Registration ------------ You can register via the ICFP 2021 registration: http://icfp21.sigplan.org/attending/registration Don't be confused that it says ~ICFP~ - FARM is part of a larger event around ICFP 2021, and you can register for FARM without registering for ICFP. Keynote ------- Phoenix Perry will hold the keynote. Accepted papers --------------- minimum: a self-extensible programming language for sound and music Tomoya Matsuura and Kazuhiro Jo MidifilePerformer: a case study for chronologies Juliette Chabassier, Myriam Desainte-Catherine, Jean Haury, Marin Pobel and Bernard Serpette Temporal-Scope Grammars for Polyphonic Music Generation Lukas Eibensteiner, Martin Ilčík and Michael Wimmer The W-calculus: A Synchronous Framework for the Verified Modelling of Digital Signal Processing Algorithms Emilio Jesus Gallego Arias, Pierre Jouvelot, Sylvain Ribstein and Dorian Desblancs Human-in-the-loop Program Synthesis for Live Coding Mark Santolucito Live Performances ----------------- FARM 2021 will feature a session of live performances: - John Leo, Logical Soundness - Emiddio Vasquez, Title TBA - José Miguel Fernandez, Homotopy Workshop Organisation --------------------- Workshop Chair: Daniel Winograd-Cort (Luminous Computing) Program Chair: Jean-Louis Giavitto (IRCAM Paris) Publicity Chair: Michael Sperber (Active Group GmbH) Performance Chair: John MacCallum (HfMT Hamburg) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivanperezdominguez at gmail.com Sun Aug 15 01:22:31 2021 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 14 Aug 2021 21:22:31 -0400 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions Message-ID: Hello Café, TL;DR: should the deprecation GHC option be transitively reported for re-exported definitions? I have a library that is exposing too much. As a minimal example, say the library contains: - Module A, which defines several functions and types. - Module B, which exports *specific definitions* from module A and has none of its own. It so happens that, to keep things as clean and abstract as possible, only module B should be exposed. As per library policy, we give users time to adapt. A way to do that would be to deprecate module A, but configure B to ignore deprecations (-Wno-deprecations) so GHC does not complain during the compilation of the library itself. My expectation was that library users who imported *A directly* would get a warning, but importing definitions in A *via B* would not give out any warnings. That, however, is not what is happening: In the use of ‘functionInA’ (imported from B, but defined in A): Deprecated: "This module will be hidden in future versions." There are "workarounds": I could move all definitions in A to new module C, deprecate A, and re-export C in B, or I could re-define the exported definitions in B as identities of those in A (easy for functions, probably more cumbersome for data constructors or classes.) However, more generally, if you use a function from A in a NEW function definition in B and then export *that second definition instead*, the compiler won't tell *the library user* that B is internally relying on a deprecated function. Reexporting a function without changes could conceptually be seen as an "extreme" case of that, where where the name and the implementation in B coincide with those in A. So I ask: should deprecation work the way it is working in the first place? All the best, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun Aug 15 01:35:41 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 14 Aug 2021 21:35:41 -0400 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions In-Reply-To: References: Message-ID: > On 14 Aug 2021, at 9:22 pm, Ivan Perez wrote: > > I have a library that is exposing too much. As a minimal example, say the library contains: > - Module A, which defines several functions and types. > - Module B, which exports specific definitions from module A and has none of its own. The simplest solution might be: module B (somefunction) import qualified A somefunction = A.somefunction This creates a *new* function in B, which is not deprecated, without re-exporting anything from A. -- Viktor. From ivanperezdominguez at gmail.com Sun Aug 15 01:53:14 2021 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sat, 14 Aug 2021 21:53:14 -0400 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions In-Reply-To: References: Message-ID: Hi Yes. As I said, "I could re-define the exported definitions in B as identities of those in A (easy for functions, *probably more cumbersome for data constructors or classes*)." For example, if B needs to re-export a record with fields and data constructors, then you can't export those with a type synonym. You can re-define and export the data constructor and the record fields as functions, but then you can't do pattern matching or use record syntax on them anymore. More generally, the question remains. Should it work the way it does? Cheers, Ivan On Sat, 14 Aug 2021 at 21:40, Viktor Dukhovni wrote: > > On 14 Aug 2021, at 9:22 pm, Ivan Perez > wrote: > > > > I have a library that is exposing too much. As a minimal example, say > the library contains: > > - Module A, which defines several functions and types. > > - Module B, which exports specific definitions from module A and has > none of its own. > > The simplest solution might be: > > module B (somefunction) > > import qualified A > > somefunction = A.somefunction > > This creates a *new* function in B, which is not deprecated, without > re-exporting anything from A. > > -- > Viktor. > > _______________________________________________ > 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 tikhon at jelv.is Sun Aug 15 02:00:07 2021 From: tikhon at jelv.is (Tikhon Jelvis) Date: Sat, 14 Aug 2021 19:00:07 -0700 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions In-Reply-To: References: Message-ID: Ivan mentioned that option in his email—seems like that could be okay (but awkward!) for functions, but would not work well for other definitions like typeclasses. On Sat, Aug 14, 2021, 18:44 Viktor Dukhovni wrote: > > On 14 Aug 2021, at 9:22 pm, Ivan Perez > wrote: > > > > I have a library that is exposing too much. As a minimal example, say > the library contains: > > - Module A, which defines several functions and types. > > - Module B, which exports specific definitions from module A and has > none of its own. > > The simplest solution might be: > > module B (somefunction) > > import qualified A > > somefunction = A.somefunction > > This creates a *new* function in B, which is not deprecated, without > re-exporting anything from A. > > -- > Viktor. > > _______________________________________________ > 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 oleg.grenrus at iki.fi Sun Aug 15 02:52:47 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sun, 15 Aug 2021 05:52:47 +0300 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions In-Reply-To: References: Message-ID: <6de93b79-f221-8d3b-0cef-49b2080a65b1@iki.fi> I think the confusion stems from what the deprecation of the module means, i.e.     module A {-# DEPRECATED "This module will be hidden in future versions". #-} ( ... ) where I think it does two things: 1. deprecates the module A, so if it's  imported anywhere, the deprecation warning will be reported 2. deprecates all symbols defined in the module, so the use-sites are reported as well. (This is like deprecating an individual binding, {-# DEPRECATED symbolInA "..." #-}. The second point is why re-exporting names defined in A still causes the warning. The thing is deprecated, it doesn't matter how you import it. However, if A re-exports some other symbols (e.g. from A.Internal), these things are not deprecated, and thus no warnings. This explains why a workaround you mention works. Or we could even argue that the (first) workaround is not even a workaround, but the right way to do what you want. Defining new binding is not the same as re-exporting. There is a bit discussion about it in [1], e.g. users can define different RULES for the thing "renamed" in B. There is an interesting challenge in [1] too: >  the proposal would be stronger if it explicitly explained that much of what is proposed [renaming on import] could be done with existing mechanisms [like writing new definitions, type, etc.] For your use case (in second workaround) you'll rely that redefinition (as "heavy" renaming) will strip the deprecation bit. But we can argue that it's still a renaming, so it should not! :) [1]: https://github.com/ghc-proposals/ghc-proposals/pull/408#issuecomment-806064864 - Oleg On 15.8.2021 4.22, Ivan Perez wrote: > Hello Café, > > TL;DR: should the deprecation GHC option be transitively reported for > re-exported definitions? > > I have a library that is exposing too much. As a minimal example, say > the library contains: > - Module A, which defines several functions and types. > - Module B, which exports /specific definitions/ from module A and has > none of its own. > > It so happens that, to keep things as clean and abstract as possible, > only module B should be exposed. > > As per library policy, we give users time to adapt. A way to do that > would be to deprecate module A, but configure B to ignore deprecations > (-Wno-deprecations) so GHC does not complain during the compilation of > the library itself. > > My expectation was that library users who imported /A directly/ would > get a warning, but importing definitions in A /via B/ would not give > out any warnings. > > That, however, is not what is happening: > > In the use of ‘functionInA’ >     (imported from B, but defined in A): >     Deprecated: "This module will be hidden in future versions." > > There are "workarounds": I could move all definitions in A to new > module C, deprecate A, and re-export C in B, or I could re-define the > exported definitions in B as identities of those in A (easy for > functions, probably more cumbersome for data constructors or classes.) > > However, more generally, if you use a function from A in a NEW > function definition in B and then export /that second definition > instead/, the compiler won't tell /the library user/ that B is > internally relying on a deprecated function. Reexporting a function > without changes could conceptually be seen as an "extreme" case of > that, where where the name and the implementation in B coincide with > those in A. > > So I ask: should deprecation work the way it is working in the first > place? > > All the best, > > Ivan > > _______________________________________________ > 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 tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sun Aug 15 07:34:07 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sun, 15 Aug 2021 08:34:07 +0100 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions In-Reply-To: References: Message-ID: <20210815073407.GD26993@cloudinit-builder> On Sat, Aug 14, 2021 at 09:53:14PM -0400, Ivan Perez wrote: > For example, if B needs to re-export a record with fields and data > constructors, then you can't export those with a type synonym. You can > re-define and export the data constructor and the record fields as > functions, but then you can't do pattern matching or use record syntax on > them anymore. Indeed, it doesn't work for types *in general*. From ivanperezdominguez at gmail.com Sun Aug 15 09:59:31 2021 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 15 Aug 2021 05:59:31 -0400 Subject: [Haskell-cafe] Deprecation being transitively reported for re-exported definitions In-Reply-To: <6de93b79-f221-8d3b-0cef-49b2080a65b1@iki.fi> References: <6de93b79-f221-8d3b-0cef-49b2080a65b1@iki.fi> Message-ID: On Sat, 14 Aug 2021 at 23:00, Oleg Grenrus wrote: > I think the confusion stems from what the deprecation of the module means, > i.e. > > module A {-# DEPRECATED "This module will be hidden in future > versions". #-} ( ... ) where > > I think it does two things: > > 1. deprecates the module A, so if it's imported anywhere, the deprecation > warning will be reported > 2. deprecates all symbols defined in the module, so the use-sites are > reported as well. (This is like deprecating an individual binding, {-# > DEPRECATED symbolInA "..." #-}. > This was also my understanding AFTER I saw the unexpected warning. So, you can say that *a definition within a module is deprecated*, and that *a module AND ALL definitions in it are deprecated. *However*, *you cannot express that* the module (name) itself is deprecated without deprecating what's in it*. It's just a level of expressiveness we do not have. If module deprecation did not lead to what you labeled (2), you could still deprecate everything in it to warn users of deprecated functions that are being re-exported through a different path. So you could obtain the same effect as now, by just annotating specific definitions. Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at mailbox.org Sun Aug 15 20:12:39 2021 From: amindfv at mailbox.org (amindfv at mailbox.org) Date: Sun, 15 Aug 2021 14:12:39 -0600 Subject: [Haskell-cafe] Parsing XML In-Reply-To: References: Message-ID: HaXml is pretty old at this point but one big advantage is it has an executable DtdToHaskell which takes an XML DTD file and automatically creates Haskell data types, a parser, and a pretty-printer. Tom On Tue, Aug 03, 2021 at 12:45:44PM -0400, John Arnold wrote: > I am building a prototype for processing ISO 20022 Payment Initiation > messages. These messages are in XML format and I want the prototype to be > built using Haskell. > > Conducting a search for 'Haskell XML parsing' yields postings that are in > the region of 10+yrs old. > > I am sure there are packages that have been developed/update in the recent > past. > Any thoughts? > _______________________________________________ > 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 ivanperezdominguez at gmail.com Sun Aug 15 20:44:13 2021 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Sun, 15 Aug 2021 16:44:13 -0400 Subject: [Haskell-cafe] Parsing XML In-Reply-To: References: Message-ID: DTDToHaskell was indeed a great idea. However, the last time I tried to use HaXml for a real project, I was not able to compile the resulting file because the DTD defined two namespaces. It would be great if someone could address that limitation. As with many other topics, XML handling is an area where it's easy to make a novel library based on a new concept, but *very* hard to create a full, industry-ready implementation that handles non-trivial, real-world DTDs and XML. Just in this thread, people have listed many libraries. Their features overlap in part but not perfectly. Their level of maintainership is unclear. Comparing all of this work to determine what a good choice would be is VERY hard* . To me, this highlights the fact that our community might do better if we focused on contributing to existing implementations, and resisted the urge to create new ones. All the best, Ivan (*It's not always easy to measure any one dimension. The complexity of comparing implementations may quickly degenerate to something like m * (n ^ 2) where m is the number of dimensions compared and n is the number of solutions, but I think it can get even worse, but even then you may be left with the task of defining a good order relationship on an m-dimensional space. All of this to say that it's REALLY complex and adding a new implementation should rarely be seen as the solution.) On Sun, 15 Aug 2021 at 16:17, amindfv--- via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > HaXml is pretty old at this point but one big advantage is it has an > executable DtdToHaskell which takes an XML DTD file and automatically > creates Haskell data types, a parser, and a pretty-printer. > > Tom > > > On Tue, Aug 03, 2021 at 12:45:44PM -0400, John Arnold wrote: > > I am building a prototype for processing ISO 20022 Payment Initiation > > messages. These messages are in XML format and I want the prototype to be > > built using Haskell. > > > > Conducting a search for 'Haskell XML parsing' yields postings that are in > > the region of 10+yrs old. > > > > I am sure there are packages that have been developed/update in the > recent > > past. > > Any thoughts? > > > _______________________________________________ > > 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 jeffbrown.the at gmail.com Mon Aug 16 00:31:28 2021 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Sun, 15 Aug 2021 19:31:28 -0500 Subject: [Haskell-cafe] Parsing XML In-Reply-To: References: Message-ID: I really enjoyed hxt. If it's of interest, here's a simple program I wrote to convert Freeplane (.mm) files to org format. https://github.com/JeffreyBenjaminBrown/rescue-freeplane On Sun, Aug 15, 2021 at 3:50 PM Ivan Perez wrote: > DTDToHaskell was indeed a great idea. However, the last time I tried to > use HaXml for a real project, I was not able to compile the resulting file > because the DTD defined two namespaces. It would be great if someone could > address that limitation. > > As with many other topics, XML handling is an area where it's easy to make > a novel library based on a new concept, but *very* hard to create a full, > industry-ready implementation that handles non-trivial, real-world DTDs and > XML. > > Just in this thread, people have listed many libraries. Their features > overlap in part but not perfectly. Their level of maintainership is > unclear. Comparing all of this work to determine what a good choice would > be is VERY hard* . To me, this highlights the fact that our community might > do better if we focused on contributing to existing implementations, and > resisted the urge to create new ones. > > All the best, > > Ivan > > (*It's not always easy to measure any one dimension. The complexity of > comparing implementations may quickly degenerate to something like m * (n ^ > 2) where m is the number of dimensions compared and n is the number of > solutions, but I think it can get even worse, but even then you may be left > with the task of defining a good order relationship on an m-dimensional > space. All of this to say that it's REALLY complex and adding a new > implementation should rarely be seen as the solution.) > > On Sun, 15 Aug 2021 at 16:17, amindfv--- via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > >> HaXml is pretty old at this point but one big advantage is it has an >> executable DtdToHaskell which takes an XML DTD file and automatically >> creates Haskell data types, a parser, and a pretty-printer. >> >> Tom >> >> >> On Tue, Aug 03, 2021 at 12:45:44PM -0400, John Arnold wrote: >> > I am building a prototype for processing ISO 20022 Payment Initiation >> > messages. These messages are in XML format and I want the prototype to >> be >> > built using Haskell. >> > >> > Conducting a search for 'Haskell XML parsing' yields postings that are >> in >> > the region of 10+yrs old. >> > >> > I am sure there are packages that have been developed/update in the >> recent >> > past. >> > Any thoughts? >> >> > _______________________________________________ >> > 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. -- Jeff Brown | Jeffrey Benjamin Brown LinkedIn | Github | Twitter | Facebook | very old Website -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Mon Aug 16 10:20:33 2021 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Mon, 16 Aug 2021 10:20:33 +0000 Subject: [Haskell-cafe] Assistant/Associate Professorships in Nottingham Message-ID: Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make multiple new appointments at the Assistant or Associate Professor level: https://tinyurl.com/wruwpnpt https://tinyurl.com/284svw4y Applications in the area of the Functional Programming (FP) lab are strongly encouraged! The FP lab is keen to receive applications from candidates with an excellent publication record (e.g. papers in leading venues such as LICS, POPL, ICFP, JFP, TOPLAS, etc) and the ability to secure external funding to support their research. Further information about the FP lab is available from: https://tinyurl.com/y2ekdkqa The deadline for applications is Monday 20th September 2021. The advert mentions some specific research areas, but the positions are open to applicants from any area of Computer Science. -- Graham Hutton and Thorsten Altenkirch 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 hjgtuyl at chello.nl Wed Aug 18 16:27:41 2021 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Wed, 18 Aug 2021 18:27:41 +0200 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: <611cee71a99b7_ecfbb3170dd30425039c@gitlab.mail> References: <611cee71a99b7_ecfbb3170dd30425039c@gitlab.mail> Message-ID: L.S., Did anyone else get a message like the one below? I did not try to log on to GitLab, as far as I can remember I do not have an account there. Is this some kind of physhing-attempt? Regards, Henk-Jan van Tuyl ------- Forwarded message ------- From: GitLab To: hjgtuyl at chello.nl Subject: Unlock instructions Date: Wed, 18 Aug 2021 13:26:41 +0200 Hello, Henk-Jan! Your GitLab account has been locked due to an excessive amount of unsuccessful sign in attempts. Your account will automatically unlock in 10 minutes or you may click the link below to unlock now. Unlock account -- Message from Stanford University: Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. https://foldingathome.org/ -- http://Van.Tuyl.eu https://HenkJanvanTuyl.werkaandemuur.nl/ https://sfeeraandemuur.nl/winkel/nekutimo/ https://github.com/HJvT https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourdemonad.html https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl/computing/EWD1056.html Haskell programming -- From migmit at gmail.com Wed Aug 18 16:50:00 2021 From: migmit at gmail.com (MigMit) Date: Wed, 18 Aug 2021 19:50:00 +0300 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: References: Message-ID: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> I did. I have an account there, but no projects. Sent from my iPhone > On Aug 18, 2021, at 19:35, Henk-Jan van Tuyl via Haskell-Cafe wrote: > >  > > L.S., > > Did anyone else get a message like the one below? > > I did not try to log on to GitLab, as far as I can remember I do not have an account there. Is this some kind of physhing-attempt? > > Regards, > Henk-Jan van Tuyl > > > ------- Forwarded message ------- > From: GitLab > To: hjgtuyl at chello.nl > Subject: Unlock instructions > Date: Wed, 18 Aug 2021 13:26:41 +0200 > > > > > > > > > > > > > > > > > > > > > > Hello, Henk-Jan! > > > > Your GitLab account has been locked due to an excessive amount of unsuccessful sign in attempts. Your account will automatically unlock in 10 minutes or you may click the link below to unlock now. > > > > > Unlock account > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > Message from Stanford University: > > Folding at home > > What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. > https://foldingathome.org/ > > -- > http://Van.Tuyl.eu > https://HenkJanvanTuyl.werkaandemuur.nl/ > https://sfeeraandemuur.nl/winkel/nekutimo/ > https://github.com/HJvT > https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourdemonad.html > https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl/computing/EWD1056.html > Haskell programming > -- > _______________________________________________ > 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 Aug 18 16:54:48 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 18 Aug 2021 12:54:48 -0400 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> References: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> Message-ID: https://mail.haskell.org/pipermail/ghc-devs/2021-August/020102.html On Wed, Aug 18, 2021 at 12:53 PM MigMit wrote: > I did. I have an account there, but no projects. > > Sent from my iPhone > > > On Aug 18, 2021, at 19:35, Henk-Jan van Tuyl via Haskell-Cafe < > haskell-cafe at haskell.org> wrote: > > > >  > > > > L.S., > > > > Did anyone else get a message like the one below? > > > > I did not try to log on to GitLab, as far as I can remember I do not > have an account there. Is this some kind of physhing-attempt? > > > > Regards, > > Henk-Jan van Tuyl > > > > > > ------- Forwarded message ------- > > From: GitLab > > To: hjgtuyl at chello.nl > > Subject: Unlock instructions > > Date: Wed, 18 Aug 2021 13:26:41 +0200 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, Henk-Jan! > > > > > > > > Your GitLab account has been locked due to an excessive amount of > unsuccessful sign in attempts. Your account will automatically unlock in 10 > minutes or you may click the link below to unlock now. > > > > > > > > > > Unlock account > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Message from Stanford University: > > > > Folding at home > > > > What if you could share your unused computer power to help find a cure? > In just 5 minutes you can join the world's biggest networked computer and > get us closer sooner. Watch the video. > > https://foldingathome.org/ > > > > -- > > http://Van.Tuyl.eu > > https://HenkJanvanTuyl.werkaandemuur.nl/ > > https://sfeeraandemuur.nl/winkel/nekutimo/ > > https://github.com/HJvT > > > https://web.archive.org/web/20201109033750/members.chello.nl/hjgtuyl/tourdemonad.html > > > https://web.archive.org/web/20201111212601/http://members.chello.nl/hjgtuyl/computing/EWD1056.html > > Haskell programming > > -- > > _______________________________________________ > > 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 amy at nualeargais.ie Thu Aug 19 12:50:21 2021 From: amy at nualeargais.ie (=?UTF-8?Q?Amy_de_Buitl=C3=A9ir?=) Date: Thu, 19 Aug 2021 13:50:21 +0100 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: References: Message-ID: <1a58f3e6ecb5af5b81d3a5714af3dc4e@nualeargais.ie> I got one of those emails as well, and I don't remember setting up an account there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan at serokell.io Thu Aug 19 17:48:08 2021 From: ivan at serokell.io (Ivan Gromakovskii) Date: Thu, 19 Aug 2021 20:48:08 +0300 Subject: [Haskell-cafe] Maintainership of 3 packages on Hackage by Adjoint Inc Message-ID: <7c42266b-8747-e980-c1e5-5036f8b314e3@serokell.io> Hello, I am a Haskell software developer and I use some packages maintained by Adjoint Inc from Hackage. Specifically, I am interested in 3 packages: • elliptic-curve • pairing • galois-field Latest versions of these packages have upper bound restrictions on their dependencies which do not allow to build them with latest versions available on Hackage. For two packages these restrictions are already updated in the source repos on GitHub, they just need to be updated on Hackage. For the third one I opened a PR on GitHub. I opened an issue about updating elliptic-curve and commented another one about pairing. Unfortunately, both issues were closed even though Hackage versions were not updated. My PR wasn't closed, but apparently I was banned or something because now I can't write comments there. Since I was unable to get any information on GitHub, I tried to contact the maintainer by email (info at adjoint.io) written in the "maintainer" field in all 3 packages, saying that I can make all the updated myself if they give me permission. Unfortunately, this email address doesn't seem to work because I got "Delivery Status Notification (Failure)" in response. So it looks like these packages are effectively unmaintained, but require some maintenance. I found the "Taking over a package " page which is exactly about my case. I think I am in the situation where I cannot contact the author/maintainer, that's why I am writing to Haskell Cafe. I can't CC the maintainer (info at adjoint.io) because the address simply doesn't exist. If anybody on the mailing list can reach out to Adjoint, please do that, I'll be very thankful. Best, Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: From xnningxie at gmail.com Fri Aug 20 21:57:39 2021 From: xnningxie at gmail.com (Ningning Xie) Date: Fri, 20 Aug 2021 17:57:39 -0400 Subject: [Haskell-cafe] Call for Participation: Haskell Implementors' Workshop 2021 Message-ID: Call for Participation ACM SIGPLAN Haskell Implementors' Workshop Sunday 22 Aug 20:00-05:00 (Seoul) https://icfp21.sigplan.org/home/hiw-2021 We are happy to announce that Haskell Implementors' Workshop is taking place this Sunday, co-located with ICFP 2021. The workshop will be live streamed on Youtube. We invite you to watch the talks, and attend the workshop. The program features 11 exciting talks, along with 4 lightning talks. The keynote is given by Bengt Marten Agren (Standard Chartered Bank), on "Haskell reinterpreted – large-scale real-world experience with the Mu compiler in Financial Markets". Program details: https://icfp21.sigplan.org/home/hiw-2021#program Keynote details: https://icfp21.sigplan.org/details/hiw-2021-papers/14/Haskell-reinterpreted-large-scale-real-world-experience-with-the-Mu-compiler-in-Fin Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie -------------- next part -------------- An HTML attachment was scrubbed... URL: From sumitraja at gmail.com Sat Aug 21 05:14:29 2021 From: sumitraja at gmail.com (Sumit Raja) Date: Sat, 21 Aug 2021 15:14:29 +1000 Subject: [Haskell-cafe] Maintainership of 3 packages on Hackage by Adjoint Inc In-Reply-To: References: Message-ID: Hi Ivan, Stephen Diehl (https://github.com/sdiehl) has been very helpful in the past with these packages. I haven't seen any activity from other Adjoint members in a while. Maye Stephen is on this list and can help. As an aside, are you using these libraries for research purposes or in the wild? I'm interested in their suitability for non-research purposes or if something like blst (https://github.com/supranational/blst) with a Haskell FFI wrapper is more suitable/secure. Regards Sumit Message: 2 > Date: Thu, 19 Aug 2021 20:48:08 +0300 > From: Ivan Gromakovskii > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] Maintainership of 3 packages on Hackage by > Adjoint Inc > Message-ID: <7c42266b-8747-e980-c1e5-5036f8b314e3 at serokell.io> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I am a Haskell software developer and I use some packages maintained by > Adjoint Inc from Hackage. Specifically, I am interested in 3 packages: > > • elliptic-curve > > • pairing > > • galois-field > > Latest versions of these packages have upper bound restrictions on their > dependencies which do not allow to build them with latest versions > available on Hackage. For two packages these restrictions are already > updated in the source repos on GitHub, they just need to be updated on > Hackage. For the third one I opened a PR > on GitHub. > > I opened an issue > about updating > elliptic-curve and commented > another one about > pairing. Unfortunately, both issues were closed even though Hackage > versions were not updated. My PR wasn't closed, but apparently I was > banned or something because now I can't write comments there. > > Since I was unable to get any information on GitHub, I tried to contact > the maintainer by email (info at adjoint.io) written in the "maintainer" > field in all 3 packages, saying that I can make all the updated myself > if they give me permission. Unfortunately, this email address doesn't > seem to work because I got "Delivery Status Notification (Failure)" in > response. > > So it looks like these packages are effectively unmaintained, but > require some maintenance. I found the "Taking over a package > " page which is exactly > about my case. I think I am in the situation where I cannot contact the > author/maintainer, that's why I am writing to Haskell Cafe. I can't CC > the maintainer (info at adjoint.io) because the address simply doesn't > exist. If anybody on the mailing list can reach out to Adjoint, please > do that, I'll be very thankful. > > Best, > > Ivan > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210819/93edbf52/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > ------------------------------ > > End of Haskell-Cafe Digest, Vol 216, Issue 18 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Sat Aug 21 09:50:24 2021 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 21 Aug 2021 15:20:24 +0530 Subject: [Haskell-cafe] The State of GHC 8.10 Message-ID: <20210821095024.aobr5jrtedls4om6@zubin-msi> Hi all, GHC 8.10.6 was released last week, with high hopes of finally putting an end to the long running saga of the GHC 8.10 series. Unfortunately, this was not to be the case as we soon discovered #19950, an issue that we claimed to have fixed in the 8.10.6 release, was still affecting the released compiler. #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). It surfaced in GHC 8.10.5 since we upgraded the toolchain on our Darwin builders to one of the affected versions. The original fix/workaround for #19950 was tested on the master and GHC-9.2 branches and found to be working, and so backported to the 8.10 branch. Unfortunately, Darwin releases for 8.10 are still done using the Make build system, which did not pick up the extra linker options needed to work around the issue. It places a heavy burden on developers to have so many active branches of the compiler to keep in mind, and the current situation with 4 active branches is simply not sustainable. As the oldest currently active branch, it is currently a priority to retire the 8.10 branch of GHC from active development as soon as possible. We have now fixed and verified the fix for #19950 on the 8.10 branch and prepared a GHC 8.10.7 release including it. As of now, the only change in GHC 8.10.7 is to link the x86_64 darwin release build with a few extra linker options to work around #19950. If you have any other critical issues that prevent you from using GHC 8.10(.6), please raise them soon by either pointing to existing tickets on the tracker or creating a new one. We are planning to cut the new release as soon as early next week, and we are really hoping that this would be the final release in the 8.10 series. Cheers, Zubin. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From travis.cardwell at extrema.is Sun Aug 22 07:26:40 2021 From: travis.cardwell at extrema.is (Travis Cardwell) Date: Sun, 22 Aug 2021 16:26:40 +0900 Subject: [Haskell-cafe] The State of GHC 8.10 In-Reply-To: <20210821095024.aobr5jrtedls4om6@zubin-msi> References: <20210821095024.aobr5jrtedls4om6@zubin-msi> Message-ID: Hi Zubin, Thank you for message! On Sat, Aug 21, 2021 at 6:58 PM Zubin Duggal wrote: > As the oldest currently active branch, it is currently a priority to > retire the 8.10 branch of GHC from active development as soon as > possible. With talk of retiring the 8.10 branch, I think it might be worthwhile to remind folks that GHC 8.10(.6) is still the most recent release that is suitable for production use. GHC 9.0.1 is *not* suitable for production use due to major issues, and GHC 9.0.2 is not ready yet. Major GHC 9.0.1 issues: * https://mail.haskell.org/pipermail/haskell-cafe/2021-March/133540.html * https://gitlab.haskell.org/ghc/ghc/-/issues/19345 * https://gitlab.haskell.org/ghc/ghc/-/issues/19976 GHC 9.0.2 progress: * https://gitlab.haskell.org/ghc/ghc/-/milestones/367 Thank you to the GHC developers for great progress. Four active branches does indeed sound daunting. I hope that the GHC 8.10.7 release goes well, and I am really looking forward to a production-ready release of GHC 9 whenever it is ready! Cheers, Travis From svenpanne at gmail.com Sun Aug 22 09:00:39 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 22 Aug 2021 11:00:39 +0200 Subject: [Haskell-cafe] The State of GHC 8.10 In-Reply-To: References: <20210821095024.aobr5jrtedls4om6@zubin-msi> Message-ID: Am So., 22. Aug. 2021 um 09:33 Uhr schrieb Travis Cardwell via Haskell-Cafe : > With talk of retiring the 8.10 branch, I think it might be worthwhile to > remind folks that GHC 8.10(.6) is still the most recent release that is > suitable for production use. GHC 9.0.1 is *not* suitable for production > use due to major issues, and GHC 9.0.2 is not ready yet. [...] > Exactly, The 8.10 series is the *only* one with full tool support at the moment, so retiring this seems to be a bit premature. The only recent LTS versions on Stackage are for 8.10, 9.0 is only available via nightly, and there is no 9.2 at all. The Haskell Language doesn't have support for 9.2, either.OK, there are only alphas for 9.2 up to now, nevertheless some alphas for the corresponding tools would be nice, too. I'm totally aware of the fact that there are different people working on the different tools/compilers/libraries, but this doesn't matter at all as an "end user". The Haskell ecosystem needs much more coordination to offer a smoother user experience. Other language ecosystems are *much* more comfortable to install and use. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Sun Aug 22 09:31:00 2021 From: zubin at well-typed.com (Zubin Duggal) Date: Sun, 22 Aug 2021 15:01:00 +0530 Subject: [Haskell-cafe] The State of GHC 8.10 In-Reply-To: References: <20210821095024.aobr5jrtedls4om6@zubin-msi> Message-ID: <20210822093100.wric5wewurrsqpmk@zubin-msi> I should clarify. By "retiring" I mean that we will not backport any more features or bug fixes to the 8.10 branch or put out new releases once 8.10.7 is out. Of course, this will only be the case if nothing critical comes up (for some definition of critical). We fully intend to ensure that GHC 8.10(.7) is a stable and robust release, ready for production use. This was the very purpose of my initial email, to ensure that there are no hidden release breaking bugs lurking somewhere. As of now, the only "critical" issue we know of in the 8.10.6 release is #19950, which will be resolved in 8.10.7. We encourage you to use GHC 8.10 as an end user or library developer, the previous email is not in any way meant to imply that we are asking you to migrate off of GHC 8.10. The purpose was simply to make sure that any (release critical) issue faced by users of GHC 8.10 is resolved in time for 8.10.7 so there is no further need of additional releases in the 8.10 series. On 21/08/22 11:00, Sven Panne wrote: >Am So., 22. Aug. 2021 um 09:33 Uhr schrieb Travis Cardwell via Haskell-Cafe >: > >> With talk of retiring the 8.10 branch, I think it might be worthwhile to >> remind folks that GHC 8.10(.6) is still the most recent release that is >> suitable for production use. GHC 9.0.1 is *not* suitable for production >> use due to major issues, and GHC 9.0.2 is not ready yet. [...] >> > >Exactly, The 8.10 series is the *only* one with full tool support at the >moment, so retiring this seems to be a bit premature. The only recent LTS >versions on Stackage are for 8.10, 9.0 is only available via nightly, and >there is no 9.2 at all. The Haskell Language doesn't have support for 9.2, >either.OK, there are only alphas for 9.2 up to now, nevertheless some >alphas for the corresponding tools would be nice, too. > >I'm totally aware of the fact that there are different people working on >the different tools/compilers/libraries, but this doesn't matter at all as >an "end user". The Haskell ecosystem needs much more coordination to offer >a smoother user experience. Other language ecosystems are *much* more >comfortable to install and use. > >Cheers, > S. >_______________________________________________ >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: not available URL: From svenpanne at gmail.com Sun Aug 22 12:35:34 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 22 Aug 2021 14:35:34 +0200 Subject: [Haskell-cafe] ghcup and XDG support Message-ID: The ghcup-hs README contains a rather nebulous remark ( https://github.com/haskell/ghcup-hs#xdg-support): Note that ghcup makes some assumptions about structure of files in XDG_BIN_HOME. So if you have other tools installing e.g. stack/cabal/ghc into it, this will likely clash. In that case consider disabling XDG support. Which assumptions does it make? What will clash and when? I very much prefer XDG-style installations, but I don't want to find out the downsides the hard way afterwards... ;-) Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christopher at conforti.xyz Sun Aug 22 12:55:54 2021 From: christopher at conforti.xyz (Christopher Conforti) Date: Sun, 22 Aug 2021 08:55:54 -0400 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: References: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> Message-ID: <20210822085554.582def0f@ccc-pc.confortihome.net> On Wed, 18 Aug 2021 12:54:48 -0400 Brandon Allbery wrote: > https://mail.haskell.org/pipermail/ghc-devs/2021-August/020102.html It's almost as if big, single points of failure are not as resilient as a distributed web (or "bazaar") of independently-hosted sources. :-P https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows I promise I'm not trying to be rude here, and the GHC team may already utilize one of these models; I freely admit that I do not know those details. It's just I see this sort of thing a lot and it can sometimes be incredibly destructive to projects; the solution--hosting one's own git server--is simple, effective, and inexpensive. (I have one and it costs me only $3.50/mo so I have basically no reason not to have one.) The only reason I can imagine that the practice isn't more widespread is that people are concerned about security. A good host will make that easier, and after the application of a few simple rules a much more secure system is possible with not that much effort at all. Food for thought. -- Christopher Conforti -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From jo at durchholz.org Sun Aug 22 13:35:05 2021 From: jo at durchholz.org (Joachim Durchholz) Date: Sun, 22 Aug 2021 15:35:05 +0200 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: <20210822085554.582def0f@ccc-pc.confortihome.net> References: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> <20210822085554.582def0f@ccc-pc.confortihome.net> Message-ID: Am 22.08.21 um 14:55 schrieb Christopher Conforti: > On Wed, 18 Aug 2021 12:54:48 -0400 > Brandon Allbery wrote: > >> https://mail.haskell.org/pipermail/ghc-devs/2021-August/020102.html > > It's almost as if big, single points of failure are not as resilient as > a distributed web (or "bazaar") of independently-hosted sources. :-P > > https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows > > ... It's just I see this sort of thing a lot and it can > sometimes be incredibly destructive to projects; the solution--hosting > one's own git server--is simple, effective, and inexpensive. The error message reports that there was an excessive amount of wrong logins, not a successful hack. Anybody who knows your public username can stage such an attack against your account - either the account gets locked, or the account gets hammered with password bruteforce attempts until the attacker is successful. This is independently of whether the account is self-hosted or on a big service. > The only reason I can imagine that the practice isn't more widespread > is that people are concerned about security. A good host will make that > easier, and after the application of a few simple rules a much more > secure system is possible with not that much effort at all. Doing your own security means you have to constantly monitor the threat landscape. Which is pretty much a fulltime job. You can skimp on it if you're hosting just your own data - a single person's data is usually not worth attacking. gitlab.haskell.org is a language community. It is much more valuable to an attacker, so "not that much effort at all" won't worth. (Full disclosure: I am the "security person" for our team. I do not to the threat landscape monitoring, that's - thankfully - done by a full security team, I'm more the guy who just keeps up-to-date on what the security team is doing and passing on what's relevant to the team. Even that minimum task is taking more time off my normal work than I'd like.) Regards, Jo From ben at well-typed.com Sun Aug 22 14:22:22 2021 From: ben at well-typed.com (Ben Gamari) Date: Sun, 22 Aug 2021 10:22:22 -0400 Subject: [Haskell-cafe] The State of GHC 8.10 In-Reply-To: References: <20210821095024.aobr5jrtedls4om6@zubin-msi> Message-ID: <877dgdo8zc.fsf@smart-cactus.org> Travis Cardwell via Haskell-Cafe writes: > Hi Zubin, > > Thank you for message! > > On Sat, Aug 21, 2021 at 6:58 PM Zubin Duggal wrote: >> As the oldest currently active branch, it is currently a priority to >> retire the 8.10 branch of GHC from active development as soon as >> possible. > > With talk of retiring the 8.10 branch, I think it might be worthwhile to > remind folks that GHC 8.10(.6) is still the most recent release that is > suitable for production use. GHC 9.0.1 is *not* suitable for production > use due to major issues, and GHC 9.0.2 is not ready yet. > Indeed 9.0.2 is not yet ready. However, we are actively working towards remedying this. Likewise, 9.2.1 is very close to being released. To clarify: by "retiring 8.10", Zubin means that the 8.10 series is moving into a truly "critical-bugfix-only" mode. This contrasts with our treatment of 8.10 thusfar, where we have been both trying to fix general bugs *and* backport rudimentary Darwin/ARM support. In this sense, 8.10 has been a rather odd release; in nearly all other releases the "feature-set" of a compiler release series is fixed after the N.N.1 release is cut. To stabilize Darwin support, our work has been focussed on 8.10. At this point we believe that 8.10.7 should be a very usable release and therefore we will focus our further efforts on 9.0 and 9.2. If after 8.10.7 we find an issue that renders the compiler unusable for a large numbers of users, we will of course make another release. However, we also very much hope that this won't be necessary. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From christopher at conforti.xyz Sun Aug 22 14:31:56 2021 From: christopher at conforti.xyz (Christopher Conforti) Date: Sun, 22 Aug 2021 10:31:56 -0400 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: References: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> <20210822085554.582def0f@ccc-pc.confortihome.net> Message-ID: <20210822103156.7acf934b@ccc-pc.confortihome.net> On Sun, 22 Aug 2021 15:35:05 +0200 Joachim Durchholz wrote: > (Full disclosure: I am the "security person" for our team. I do not > to the threat landscape monitoring, that's - thankfully - done by a > full security team, I'm more the guy who just keeps up-to-date on > what the security team is doing and passing on what's relevant to the > team. Even that minimum task is taking more time off my normal work > than I'd like.) > > 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. I meant no disrespect, of course; forgive my ignorance. I've never worked with another person, let alone a team, so I can only speak from what's worked for me. -- Christopher Conforti -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From svenpanne at gmail.com Sun Aug 22 17:11:37 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 22 Aug 2021 19:11:37 +0200 Subject: [Haskell-cafe] Some tooling questions Message-ID: Just 2 quick questions to see if I understand things correctly: * Current Haddock versions have the ability to render hyperlinked coloured source code built-in, there is no need for a separate HsColour executable anymore (IIRC, this was required in ancient times), correct? * The haskell-language-server executables have all their "plugins" compiled and linked into them, correct? So there is e.g. no need for an external ormolu, hlint, ... executable. This would be a good thing, but using the word "plugin" for this is quite confusing for the end user IMHO. For me, plugins are something which you can install in addition to something else. This doesn't seem to be the case here, if I understand the source code correctly. And some final questions regarding the Haskell Language Server: Why are there separate haskell-language-server-X.Y executables plus a wrapper? Why are the executables tied to a fixed GHC version and what exactly does the wrapper do? Which of these executables is used e.g. by Emacs' lsp-mode? This looks quite complicated, at least compared to all the other LSP backends I know: For C++, just point to any clangd; for Groovy, just point to a JAR; for Python just install a single python-lsp-server package (which has real plugins as separate packages BTW), etc. Slightly confused, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From godzbanebane at gmail.com Sun Aug 22 18:24:10 2021 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Sun, 22 Aug 2021 21:24:10 +0300 Subject: [Haskell-cafe] Some tooling questions In-Reply-To: References: Message-ID: Hi! The different executables are necessary because of things like TH and base being tied to ghc versions. It uses potentially *all* of them - the HLS "wrapper" runs first, detecting what ghc version your project is on (or what your "global" ghc is in your current environment), and runs the corresponding HLS. I would recommend using ghcup to install HLS, as it takes care to install all of the binaries automatically (unless something else has already done so). Cheers, ====== Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Sun Aug 22 18:59:26 2021 From: svenpanne at gmail.com (Sven Panne) Date: Sun, 22 Aug 2021 20:59:26 +0200 Subject: [Haskell-cafe] Some tooling questions In-Reply-To: References: Message-ID: Am So., 22. Aug. 2021 um 20:24 Uhr schrieb Georgi Lyubenov < godzbanebane at gmail.com>: > [...] I would recommend using ghcup to install HLS, as it takes care to > install all of the binaries automatically (unless something else has > already done so). > Installing HLS was the least confusing part of this mess: Download https://github.com/haskell/haskell-language-server/releases/download/1.3.0/haskell-language-server-Linux-1.3.0.tar.gz, unpack into ~/.local/bin, done. (Well, actually I like to unpack things into ~/.local/opt/ and use symlinks into ~/.local/bin to keep things separated, but that's just my personal taste.) The real confusion came when I realized that HLS 1.3.0 is far from feature-complete for GHC 9.0.1, some issues on its issue tracker gave contradicting information, installing e.g. ormolu by hand didn't help etc. etc. Regarding ghcup: IIRC it was very cabal-centric when it came out, but personally I totally ignore cabal and use stack exclusively (like most people if I remember the last surveys correctly). Recent versions of ghcup seem to handle stack, too, but there are mysterious remarks about XDG directory structures on the ghcup-hs project page (see my other mail). Furthermore, I'm not sure what the current state of affairs regarding cabal vs. stack is: I really don't want to have duplicated toolchains and tons of GBs of duplicated compiled packages lying around, but this was the case when I last had a look. Some packages don't work with stack out of the box and need cabal (or vice versa), and then things get really annoying and space-/time-consuming. Setting up a development environment from scratch for a recent GHC involves tools battling against each other, reading incomplete and/or confusing documentation and tons of free disk space. It's a bit like an ancient text adventure, but less entertaining... :-} Cheers, S. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sun Aug 22 21:56:37 2021 From: ben at well-typed.com (Ben Gamari) Date: Sun, 22 Aug 2021 17:56:37 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.1-rc1 now available Message-ID: <87wnodm9dq.fsf@smart-cactus.org> Hi all, The GHC developers are very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.2.1-rc1 GHC 9.2 will bring a number of exciting features including: * A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1. * Many changes in the area of records, including the new `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well as Support for `DuplicateRecordFields` with `PatternSynonyms`. * Introduction of the new `GHC2021` language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable. * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box. * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism over levity of boxed objects (#17526) * Implementation of the `UnliftedDataTypes` extension, allowing users to define types which do not admit lazy evaluation ([proposal]) * The new [-hi profiling] mechanism which provides significantly improved insight into thunk leaks. * Support for the `ghc-debug` out-of-process heap inspection library [ghc-debug] * Support for profiling of pinned objects with the cost-centre profiler (#7275) * Introduction of Haddock documentation support in TemplateHaskell (#5467) Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy testing, - Ben [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From david.feuer at gmail.com Sun Aug 22 22:10:20 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Aug 2021 18:10:20 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: <87wnodm9dq.fsf@smart-cactus.org> References: <87wnodm9dq.fsf@smart-cactus.org> Message-ID: Have array and reference types and primos been updated to be BoxedRep-polymorphic, or is it still just expensive scaffolding? On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > > Hi all, > > The GHC developers are very happy to announce the availability of the > release cadidate of the 9.2.1 release. Binary distributions, source > distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.2.1-rc1 > > GHC 9.2 will bring a number of exciting features including: > > * A native code generation backend for AArch64, significantly speeding > compilation time on ARM platforms like the Apple M1. > > * Many changes in the area of records, including the new > `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well > as Support for `DuplicateRecordFields` with `PatternSynonyms`. > > * Introduction of the new `GHC2021` language extension set, giving > users convenient access to a larger set of language extensions which > have been long considered stable. > > * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure > for source-to-source program rewriting out-of-the-box. > > * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism > over levity of boxed objects (#17526) > > * Implementation of the `UnliftedDataTypes` extension, allowing users > to define types which do not admit lazy evaluation ([proposal]) > > * The new [-hi profiling] mechanism which provides significantly > improved insight into thunk leaks. > > * Support for the `ghc-debug` out-of-process heap inspection library > [ghc-debug] > > * Support for profiling of pinned objects with the cost-centre profiler > (#7275) > > * Introduction of Haddock documentation support in TemplateHaskell (#5467) > > Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake > pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous > contributors whose on-going financial and in-kind support has > facilitated GHC maintenance and release management over the years. > Moreover, this release would not have been possible without the hundreds > of open-source contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy testing, > > - Ben > > > [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html > [proposal]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst > [-hi > > profiling]: > https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ > [ghc-debug > ]: > http://ghc.gitlab.haskell.org/ghc-debug/ > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Aug 23 00:14:01 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Aug 2021 20:14:01 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: <87wnodm9dq.fsf@smart-cactus.org> References: <87wnodm9dq.fsf@smart-cactus.org> Message-ID: One more question: is Solo exported from Data.Tuple yet, or do we still have to depend on ghc-prim and import it from GHC.Magic? It would be really nice to have that fixed by release, and it's so tiny. On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > > Hi all, > > The GHC developers are very happy to announce the availability of the > release cadidate of the 9.2.1 release. Binary distributions, source > distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.2.1-rc1 > > GHC 9.2 will bring a number of exciting features including: > > * A native code generation backend for AArch64, significantly speeding > compilation time on ARM platforms like the Apple M1. > > * Many changes in the area of records, including the new > `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well > as Support for `DuplicateRecordFields` with `PatternSynonyms`. > > * Introduction of the new `GHC2021` language extension set, giving > users convenient access to a larger set of language extensions which > have been long considered stable. > > * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure > for source-to-source program rewriting out-of-the-box. > > * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism > over levity of boxed objects (#17526) > > * Implementation of the `UnliftedDataTypes` extension, allowing users > to define types which do not admit lazy evaluation ([proposal]) > > * The new [-hi profiling] mechanism which provides significantly > improved insight into thunk leaks. > > * Support for the `ghc-debug` out-of-process heap inspection library > [ghc-debug] > > * Support for profiling of pinned objects with the cost-centre profiler > (#7275) > > * Introduction of Haddock documentation support in TemplateHaskell (#5467) > > Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake > pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous > contributors whose on-going financial and in-kind support has > facilitated GHC maintenance and release management over the years. > Moreover, this release would not have been possible without the hundreds > of open-source contributors whose work comprise this release. > > As always, do give this release a try and open a [ticket] if you see > anything amiss. > > Happy testing, > > - Ben > > > [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html > [proposal]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst > [-hi > > profiling]: > https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ > [ghc-debug > ]: > http://ghc.gitlab.haskell.org/ghc-debug/ > [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Mon Aug 23 00:15:10 2021 From: david.feuer at gmail.com (David Feuer) Date: Sun, 22 Aug 2021 20:15:10 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.2.1-rc1 now available In-Reply-To: References: <87wnodm9dq.fsf@smart-cactus.org> Message-ID: I mean GHC.Tuple, of course. On Sun, Aug 22, 2021, 8:14 PM David Feuer wrote: > One more question: is Solo exported from Data.Tuple yet, or do we still > have to depend on ghc-prim and import it from GHC.Magic? It would be really > nice to have that fixed by release, and it's so tiny. > > On Sun, Aug 22, 2021, 6:01 PM Ben Gamari wrote: > >> >> Hi all, >> >> The GHC developers are very happy to announce the availability of the >> release cadidate of the 9.2.1 release. Binary distributions, source >> distributions, and documentation are available at >> >> https://downloads.haskell.org/ghc/9.2.1-rc1 >> >> GHC 9.2 will bring a number of exciting features including: >> >> * A native code generation backend for AArch64, significantly speeding >> compilation time on ARM platforms like the Apple M1. >> >> * Many changes in the area of records, including the new >> `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well >> as Support for `DuplicateRecordFields` with `PatternSynonyms`. >> >> * Introduction of the new `GHC2021` language extension set, giving >> users convenient access to a larger set of language extensions which >> have been long considered stable. >> >> * Merge of `ghc-exactprint` into the GHC tree, providing infrastructure >> for source-to-source program rewriting out-of-the-box. >> >> * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism >> over levity of boxed objects (#17526) >> >> * Implementation of the `UnliftedDataTypes` extension, allowing users >> to define types which do not admit lazy evaluation ([proposal]) >> >> * The new [-hi profiling] mechanism which provides significantly >> improved insight into thunk leaks. >> >> * Support for the `ghc-debug` out-of-process heap inspection library >> [ghc-debug] >> >> * Support for profiling of pinned objects with the cost-centre profiler >> (#7275) >> >> * Introduction of Haddock documentation support in TemplateHaskell >> (#5467) >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous >> contributors whose on-going financial and in-kind support has >> facilitated GHC maintenance and release management over the years. >> Moreover, this release would not have been possible without the hundreds >> of open-source contributors whose work comprise this release. >> >> As always, do give this release a try and open a [ticket] if you see >> anything amiss. >> >> Happy testing, >> >> - Ben >> >> >> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html >> [proposal]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst >> [-hi >> >> profiling]: >> https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ >> [ghc-debug >> ]: >> http://ghc.gitlab.haskell.org/ghc-debug/ >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jo at durchholz.org Mon Aug 23 04:12:20 2021 From: jo at durchholz.org (Joachim Durchholz) Date: Mon, 23 Aug 2021 06:12:20 +0200 Subject: [Haskell-cafe] Fwd: Unlock instructions In-Reply-To: <20210822103156.7acf934b@ccc-pc.confortihome.net> References: <3FE7AD8F-56D4-45E8-B689-94BE916F099F@gmail.com> <20210822085554.582def0f@ccc-pc.confortihome.net> <20210822103156.7acf934b@ccc-pc.confortihome.net> Message-ID: Am 22.08.21 um 16:31 schrieb Christopher Conforti: > I meant no disrespect, of course; Me neither. Please note I'm not part of the Haskell team, I'm just a sideline spectator. It's just that the topic is one of the things where I happen to be marginally competent. > forgive my ignorance. What worked for me in the past: Switch from WTF mode to "I want to ask questions to find out what I'm missing" mode. I often learn something of interest if I do it (and sometimes I fail to do it myself). Regards, Jo From godzbanebane at gmail.com Mon Aug 23 07:44:42 2021 From: godzbanebane at gmail.com (Georgi Lyubenov) Date: Mon, 23 Aug 2021 10:44:42 +0300 Subject: [Haskell-cafe] Some tooling questions In-Reply-To: References: Message-ID: ghcup is only used to install different toolings, I don't think you *have* to use anything related to cabal in order to use it - in particular, I also use stack 95% of the time, and I use it almost purely to install my HLS versions easily. Re your other point, HLS is indeed known to not fully support ghc9, and installing ormolu shouldn't help afaik, as it is as you noted - ormolu is compiled into HLS itself. Cheers, ======= Georgi -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Tue Aug 24 11:08:00 2021 From: leah at vuxu.org (Leah Neukirchen) Date: Tue, 24 Aug 2021 13:08:00 +0200 Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2021-08-26 @ 19:30 Message-ID: <87y28rcd7z.fsf@vuxu.org> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 26 on Jitsi at 19:30 CEST. **Due to bad weather for meetings outside this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Jitsi link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen https://leahneukirchen.org/ From ifl21.publicity at gmail.com Wed Aug 25 16:10:55 2021 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Wed, 25 Aug 2021 09:10:55 -0700 Subject: [Haskell-cafe] IFL'21 call for participation Message-ID: ================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl *Registration* Registration is free of charge, but required for participation! Use the below link to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8ofIqshfQFrf4jnvsA/viewform?usp=sf_link *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 2021 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. *Program* The program is now available at https://ifl21.cs.ru.nl/Program . *Organisation* IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands *PC* Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Hage at uu.nl Thu Aug 26 10:55:59 2021 From: J.Hage at uu.nl (Hage, J. (Jurriaan)) Date: Thu, 26 Aug 2021 10:55:59 +0000 Subject: [Haskell-cafe] Haskell Symposium starts right now! Message-ID: <41BC259A-1F3A-4A79-8F4D-3D76077A7E7A@uu.nl> Hi all at Haskell Cafe, Just in case you had not registered for ICFP and its workshops, you can still follow the talks of the Haskell Symposium in a live stream. These recordings are currently public, but that may not last for long. Here’s the link: https://www.youtube.com/watch?v=sVrlaF7sCU4 Best, Jur From anton.antich at gmail.com Thu Aug 26 15:54:44 2021 From: anton.antich at gmail.com (Anton Antich) Date: Thu, 26 Aug 2021 17:54:44 +0200 Subject: [Haskell-cafe] Magical Haskell book preview: Haskell and type theory in pictures and in a fun and accessible way Message-ID: Dear all, I started "Magical Haskell" 3 years ago with the goal to fill the void of explaining typed functional programming from the first principles, but in a fun and accessible way. Imperative patterns really mess with learning Haskell, while alternative top-down approaches are usually too technical and math-heavy, so that the beauty and elegance of the concepts involved is lost on many. So I tried to use the latter, but build it up gradually, from intuition and functional thinking, so that a high school student could understand. Now the book is about 50% ready as I came back to writing it after a sabbatical break, now covers the foundations, functional thinking, different types, typeclasses, and specific examples gently building up from Maybe and List through Monoid and up to Functor and Bifunctor. Applicative, Monad and real world programs via Monad Transformer Stacks are coming up. It is available here: https://leanpub.com/magicalhaskell - free to read online. Would very much appreciate your feedback - what is missing, what do you think of such a style, what is maybe too much, etc. Also, if anyone is ready to contribute a public testimonial - will gladly give a free copy of the ebook and all future updates in offline formats! Thank you very much! -------------- next part -------------- An HTML attachment was scrubbed... URL: From zubin at well-typed.com Thu Aug 26 22:13:15 2021 From: zubin at well-typed.com (Zubin Duggal) Date: Fri, 27 Aug 2021 03:43:15 +0530 Subject: [Haskell-cafe] [Haskell] [ANNOUNCE] GHC 8.10.7 released Message-ID: <20210826221315.tumzvm3q2p24qa4x@zubin-msi> The GHC team is very pleased to announce the availability of GHC 8.10.7. Source and binary distributions are available at the [usual place](https://downloads.haskell.org/ghc/8.10.7/). Download Page: https://www.haskell.org/ghc/download_ghc_8_10_7.html Blog Post: https://www.haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html This is a small bugfix release, fixing one linking portability issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64 macOS toolchains, which resulted in undefined symbol errors for `___darwin_check_fd_set_overflow`. Issue #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11). We claimed to have fixed this in GHC 8.10.6, but alas this wasn't the case. The fix was originally tested on the master branch, which uses a different build configuration from the 8.10 branch. We have now tested the fix on the GHC 8.10 branch and finally squashed the bug. We would like to thank Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. We would also like to thank the hundreds of open-source contributors whose work makes GHC possible. A complete list of bug fixes and improvements can be found in the [release notes](https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8. 10.7-notes.html). As always, feel free to report any issues you encounter via [gitlab.haskell.org](https://gitlab.haskell.org/ghc/ghc/-/issues/new). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From persiantiger at yandex.ru Fri Aug 27 07:28:59 2021 From: persiantiger at yandex.ru (Andrey Prokopenko) Date: Fri, 27 Aug 2021 09:28:59 +0200 Subject: [Haskell-cafe] Take-over request for: blaze-textual Message-ID: Hello, - Few months ago I opened PR in `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 - The package is either direct or transient dependency for `haskell-language-server`, `sqlite-simple` and few more packages. - While forks maintenance is a well-known practice it creates burden on maintainers. I would like to become a maintainer for `blaze-textual` package and keep it up-to-date at least for a next few years. Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package Best Regards, Andrey Prokopenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From J.Hage at uu.nl Fri Aug 27 10:55:10 2021 From: J.Hage at uu.nl (Hage, J. (Jurriaan)) Date: Fri, 27 Aug 2021 10:55:10 +0000 Subject: [Haskell-cafe] The second day of the 2021 Haskell Symposium is now streaming on YouTube Message-ID: Haskellers, Today is the 2nd day of the 2021 Haskell Symposium and it is being streamed on Youtube. If you want a taste of it join us while it is still public. After the invited talk of Mathieu Boespflug yesterday (we maxed out at about a 100 viewer on Youtube and some 74 people in Airmeet) we will have yet another invited talk on Linear Haskell today by Jean-Philippe Bernardy, and one of the five research talks will be on Linear Haskell as well. On top of that there are four more research talks on your favorite programming language. Here’s the link: https://youtu.be/6pJKIjn95eU Do not miss out, and no need to register for ICFP. Best, Jurriaan Hage Chair From hecate at glitchbra.in Fri Aug 27 19:46:07 2021 From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=) Date: Fri, 27 Aug 2021 21:46:07 +0200 Subject: [Haskell-cafe] [Call for reviewers] Switch `text`'s internal representation to UTF-8 Message-ID: Hello everyone, After tremendous efforts, the pull request to switch `text`'s internal representation to UTF-8 is here, and unsurprisingly this is a titan's work. It lives here: https://github.com/haskell/text/pull/365 We are sending out a call for reviewers, as this is a cornerstone of our ecosystem. The performance gains from this PR are huge and I would like to ensure we can have a multitude of eyes to take a look. I wish to express my thanks to all of you. This is definitely the kind of advances that will make Haskell a stronger language for the times to come. Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD From 8hjkl8 at gmail.com Sun Aug 29 11:42:54 2021 From: 8hjkl8 at gmail.com (Kim Chaegon) Date: Sun, 29 Aug 2021 14:42:54 +0300 Subject: [Haskell-cafe] Contents of Haskell-Cafe digest... Message-ID: Hello! I want read and learn continually haskell for mathematics. Please send me your text about haskell. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From persiantiger at yandex.ru Mon Aug 30 07:24:00 2021 From: persiantiger at yandex.ru (Andrey Prokopenko) Date: Mon, 30 Aug 2021 09:24:00 +0200 Subject: [Haskell-cafe] Take-over request for: blaze-textual In-Reply-To: References: Message-ID: <2D718316-12BB-4080-A19B-EDA65BDBDAE5@yandex.ru> Hello, Just want to inform you that take-over has been accomplished. Please consider this thread as solved. Thank you. Best Regards, Andrey Prokopenko > On 27 Aug 2021, at 09:28, Andrey Prokopenko wrote: > > Hello, > > - Few months ago I opened PR in `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 > - The package is either direct or transient dependency for `haskell-language-server`, `sqlite-simple` and few more packages. > - While forks maintenance is a well-known practice it creates burden on maintainers. > > I would like to become a maintainer for `blaze-textual` package and keep it up-to-date at least for a next few years. > > Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package > > Best Regards, > Andrey Prokopenko > > _______________________________________________ > 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 power.walross at gmail.com Mon Aug 30 10:49:51 2021 From: power.walross at gmail.com (Fendor) Date: Mon, 30 Aug 2021 12:49:51 +0200 Subject: [Haskell-cafe] Remove 'show-build-info' from lib:Cabal In-Reply-To: References: Message-ID: Hello everyone! The lib:Cabal (Setup.hs) command 'show-build-info' is going to be removed with the next Cabal version (3.8). It is being replaced by the build flag '--enable-build-info' that is added to 'build' directly. If you depend on 'show-build-info' in any way, please give us feedback on [1] or [2]. Details on the purpose and implementation of 'show-build-info' can be found here: [1] Best regards, Fendor [1]: https://github.com/haskell/cabal/issues/7489 [2]: https://github.com/haskell/cabal/pull/7498 From oleg.grenrus at iki.fi Mon Aug 30 12:11:09 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 30 Aug 2021 15:11:09 +0300 Subject: [Haskell-cafe] Take-over request for: blaze-textual In-Reply-To: <2D718316-12BB-4080-A19B-EDA65BDBDAE5@yandex.ru> References: <2D718316-12BB-4080-A19B-EDA65BDBDAE5@yandex.ru> Message-ID: <10fd1b63-b943-eef2-eddd-5122ee824875@iki.fi> Previously package takeovers where recorded on https://github.com/haskell-infra/hackage-trustees/issues?q=is%3Aissue+label%3A%22Package+Takeover%22+ Isn't that a case anymore. It would be great to have these recorded somewhere else then only on a mailing list. (searchable etc. c.f. discussion about CLC recent process changes!) - Oleg On 30.8.2021 10.24, Andrey Prokopenko wrote: > Hello, > > Just want to inform you that take-over has been accomplished. > Please consider this thread as solved. Thank you. > > Best Regards, > Andrey Prokopenko > >> On 27 Aug 2021, at 09:28, Andrey Prokopenko > > wrote: >> >> Hello, >> >> - Few months ago I opened PR in >> `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 >>   >> - The package is either direct or transient dependency for >> `haskell-language-server`, `sqlite-simple` and few more packages. >> - While forks maintenance is a well-known practice it creates burden >> on maintainers. >> >> I would like to become a maintainer for `blaze-textual` package and >> keep it up-to-date at least for a next few years. >> >> Please consider this message as a step 2 in take-over >> procedure: https://wiki.haskell.org/Taking_over_a_package >>   >> >> Best Regards, >> Andrey Prokopenko >> >> _______________________________________________ >> 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 persiantiger at yandex.ru Mon Aug 30 13:28:17 2021 From: persiantiger at yandex.ru (Andrey Prokopenko) Date: Mon, 30 Aug 2021 15:28:17 +0200 Subject: [Haskell-cafe] Take-over request for: blaze-textual In-Reply-To: <10fd1b63-b943-eef2-eddd-5122ee824875@iki.fi> References: <2D718316-12BB-4080-A19B-EDA65BDBDAE5@yandex.ru> <10fd1b63-b943-eef2-eddd-5122ee824875@iki.fi> Message-ID: <795DD8B1-0253-47AE-9D93-F12720434CE3@yandex.ru> Oleg, Who can I contact in order to update Haskell wiki page: https://wiki.haskell.org/Taking_over_a_package ? I followed the process described there. Therefore, it seems that page should be updated as well to reflect recent changes in the process I was not aware of. Best Regards, Andrey Prokopenko > On 30 Aug 2021, at 14:11, Oleg Grenrus wrote: > > Previously package takeovers where recorded on https://github.com/haskell-infra/hackage-trustees/issues?q=is%3Aissue+label%3A%22Package+Takeover%22+ > > Isn't that a case anymore. It would be great to have these recorded somewhere else then only on a mailing list. (searchable etc. c.f. discussion about CLC recent process changes!) > > - Oleg > > On 30.8.2021 10.24, Andrey Prokopenko wrote: >> Hello, >> >> Just want to inform you that take-over has been accomplished. >> Please consider this thread as solved. Thank you. >> >> Best Regards, >> Andrey Prokopenko >> >>> On 27 Aug 2021, at 09:28, Andrey Prokopenko > wrote: >>> >>> Hello, >>> >>> - Few months ago I opened PR in `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 >>> - The package is either direct or transient dependency for `haskell-language-server`, `sqlite-simple` and few more packages. >>> - While forks maintenance is a well-known practice it creates burden on maintainers. >>> >>> I would like to become a maintainer for `blaze-textual` package and keep it up-to-date at least for a next few years. >>> >>> Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package >>> >>> Best Regards, >>> Andrey Prokopenko >>> >>> _______________________________________________ >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Mon Aug 30 13:37:19 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 30 Aug 2021 16:37:19 +0300 Subject: [Haskell-cafe] Take-over request for: blaze-textual In-Reply-To: <795DD8B1-0253-47AE-9D93-F12720434CE3@yandex.ru> References: <2D718316-12BB-4080-A19B-EDA65BDBDAE5@yandex.ru> <10fd1b63-b943-eef2-eddd-5122ee824875@iki.fi> <795DD8B1-0253-47AE-9D93-F12720434CE3@yandex.ru> Message-ID: <6609a0c8-35e1-78d0-57e6-0980937fd4bb@iki.fi> Andrey, sorry I implied that you should have done something extra. As i commented on the hackage-infra issue you opened, I think it is hackage admins who should keep the (public) log of requested & executed package takeovers. ... or was you able to reach Bryan who migrated the repository? In that case sorry for all the confusion, I assumed it went directly to the Hackage admins as Bryan was not so easy to contact! - Oleg On 30.8.2021 16.28, Andrey Prokopenko wrote: > Oleg,  > > Who can I contact in order to update Haskell wiki > page: https://wiki.haskell.org/Taking_over_a_package >  ? > I followed the process described there. Therefore, it seems that page > should be updated as well to reflect recent changes in the process I > was not aware of. > > Best Regards, > Andrey Prokopenko > >> On 30 Aug 2021, at 14:11, Oleg Grenrus > > wrote: >> >> Previously package takeovers where recorded on >> https://github.com/haskell-infra/hackage-trustees/issues?q=is%3Aissue+label%3A%22Package+Takeover%22+ >> >> Isn't that a case anymore. It would be great to have these recorded >> somewhere else then only on a mailing list. (searchable etc. c.f. >> discussion about CLC recent process changes!) >> >> - Oleg >> >> On 30.8.2021 10.24, Andrey Prokopenko wrote: >>> Hello, >>> >>> Just want to inform you that take-over has been accomplished. >>> Please consider this thread as solved. Thank you. >>> >>> Best Regards, >>> Andrey Prokopenko >>> >>>> On 27 Aug 2021, at 09:28, Andrey Prokopenko >>> > wrote: >>>> >>>> Hello, >>>> >>>> - Few months ago I opened PR in >>>> `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 >>>>   >>>> - The package is either direct or transient dependency for >>>> `haskell-language-server`, `sqlite-simple` and few more packages. >>>> - While forks maintenance is a well-known practice it creates >>>> burden on maintainers. >>>> >>>> I would like to become a maintainer for `blaze-textual` package and >>>> keep it up-to-date at least for a next few years. >>>> >>>> Please consider this message as a step 2 in take-over >>>> procedure: https://wiki.haskell.org/Taking_over_a_package >>>>   >>>> >>>> Best Regards, >>>> Andrey Prokopenko >>>> >>>> _______________________________________________ >>>> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From persiantiger at yandex.ru Mon Aug 30 13:40:16 2021 From: persiantiger at yandex.ru (Andrey Prokopenko) Date: Mon, 30 Aug 2021 15:40:16 +0200 Subject: [Haskell-cafe] Take-over request for: blaze-textual In-Reply-To: <6609a0c8-35e1-78d0-57e6-0980937fd4bb@iki.fi> References: <2D718316-12BB-4080-A19B-EDA65BDBDAE5@yandex.ru> <10fd1b63-b943-eef2-eddd-5122ee824875@iki.fi> <795DD8B1-0253-47AE-9D93-F12720434CE3@yandex.ru> <6609a0c8-35e1-78d0-57e6-0980937fd4bb@iki.fi> Message-ID: <8F3A2C42-6B42-4E1D-A873-93CD4DAD7B20@yandex.ru> Oleg, Actually, it was Bryan. Next time I will be explicit about the migration and share all details to avoid confusion. Best Regards, Andrey Prokopenko > On 30 Aug 2021, at 15:37, Oleg Grenrus wrote: > > Andrey, > > sorry I implied that you should have done something extra. As i commented on the hackage-infra issue you opened, I think it is hackage admins who should keep the (public) log of requested & executed package takeovers. > > ... or was you able to reach Bryan who migrated the repository? In that case sorry for all the confusion, I assumed it went directly to the Hackage admins as Bryan was not so easy to contact! > > - Oleg > > On 30.8.2021 16.28, Andrey Prokopenko wrote: >> Oleg, >> >> Who can I contact in order to update Haskell wiki page: https://wiki.haskell.org/Taking_over_a_package ? >> I followed the process described there. Therefore, it seems that page should be updated as well to reflect recent changes in the process I was not aware of. >> >> Best Regards, >> Andrey Prokopenko >> >>> On 30 Aug 2021, at 14:11, Oleg Grenrus > wrote: >>> >>> Previously package takeovers where recorded on https://github.com/haskell-infra/hackage-trustees/issues?q=is%3Aissue+label%3A%22Package+Takeover%22+ >>> >>> Isn't that a case anymore. It would be great to have these recorded somewhere else then only on a mailing list. (searchable etc. c.f. discussion about CLC recent process changes!) >>> >>> - Oleg >>> >>> On 30.8.2021 10.24, Andrey Prokopenko wrote: >>>> Hello, >>>> >>>> Just want to inform you that take-over has been accomplished. >>>> Please consider this thread as solved. Thank you. >>>> >>>> Best Regards, >>>> Andrey Prokopenko >>>> >>>>> On 27 Aug 2021, at 09:28, Andrey Prokopenko > wrote: >>>>> >>>>> Hello, >>>>> >>>>> - Few months ago I opened PR in `blaze-textual`: https://github.com/bos/blaze-textual/pull/14 >>>>> - The package is either direct or transient dependency for `haskell-language-server`, `sqlite-simple` and few more packages. >>>>> - While forks maintenance is a well-known practice it creates burden on maintainers. >>>>> >>>>> I would like to become a maintainer for `blaze-textual` package and keep it up-to-date at least for a next few years. >>>>> >>>>> Please consider this message as a step 2 in take-over procedure: https://wiki.haskell.org/Taking_over_a_package >>>>> >>>>> Best Regards, >>>>> Andrey Prokopenko >>>>> >>>>> _______________________________________________ >>>>> 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. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ifl21.publicity at gmail.com Mon Aug 30 19:32:22 2021 From: ifl21.publicity at gmail.com (Pieter Koopman) Date: Mon, 30 Aug 2021 12:32:22 -0700 Subject: [Haskell-cafe] IFL'21 final call for participation Message-ID: ================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl *Registration* *Registration is **free of charge, but required for participation!* We will mail the zoom link only to registered participants. Use the below link to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8ofIqshfQFrf4jnvsA/viewform?usp=sf_link *Program* The program is now available at https://ifl21.cs.ru.nl/Program . *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 2021 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. *Organisation* IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands *PC* Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary [image: beacon] -------------- next part -------------- An HTML attachment was scrubbed... URL: From compl.yue at icloud.com Tue Aug 31 10:03:11 2021 From: compl.yue at icloud.com (YueCompl) Date: Tue, 31 Aug 2021 18:03:11 +0800 Subject: [Haskell-cafe] Examples of Continuation monad that impossible to understand and maintain? Message-ID: <6E7245AA-AC07-4B68-BFBE-A1B012A8303F@icloud.com> Dear Cafe, I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now: > Abuse of the Continuation monad can produce code that is impossible to understand and maintain. Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text=Abuse%20of%20the%20Continuation%20monad%20can%20produce%20code%20that%20is%20impossible%20to%20understand%20and%20maintain But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid. Please share what you know about it, many appreciations! Background of my CPS necessarity: Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context. Thanks, Compl -------------- next part -------------- An HTML attachment was scrubbed... URL: From ida.bzowska at gmail.com Tue Aug 31 13:01:17 2021 From: ida.bzowska at gmail.com (Ida Bzowska) Date: Tue, 31 Aug 2021 15:01:17 +0200 Subject: [Haskell-cafe] [conference announcement] Haskell Love Conference 2021 Message-ID: Hi Haskellers, Kindly reminder: https://haskell.love is taking place in 10 days. The conference is free to attend, held online, with the best schedule you can imagine (talks by: Simon Peyton-Jones as a keynote, Chris Penner, Dmitrii Kovanikov, Gergő Érdi, Ivan Gromakovskii, Jan Christopher Vogt, Jeremy Gibbons, Marcin Szamotulski, Mikael Tönnberg, Noon van der Silk, Rebecca Skinner, Ryan Orendorff, Stephanie Weirich, Thomas Tuegel, Gershom Bazerman, Joseph Morag, Veronika Romashkina). If you don't have a good excuse to skip the event then grab your ticket! λCheers, Ida Bzowska -------------- next part -------------- An HTML attachment was scrubbed... URL: From jclites at mac.com Tue Aug 31 14:46:11 2021 From: jclites at mac.com (Jeff Clites) Date: Tue, 31 Aug 2021 07:46:11 -0700 Subject: [Haskell-cafe] Examples of Continuation monad that impossible to understand and maintain? In-Reply-To: <6E7245AA-AC07-4B68-BFBE-A1B012A8303F@icloud.com> References: <6E7245AA-AC07-4B68-BFBE-A1B012A8303F@icloud.com> Message-ID: <40C9B7EE-3F6F-4A63-AEDA-E1B9B4E02C37@mac.com> Based on the preceding paragraph, I think that by “abuse” it means overuse, as in using CPS when you could have used straightforward code. I can imagine someone doing at the source code level the sort of things that would be done by a CPS-based compiler (converting everything possible to CPS), and ending up with a mess. For example, imagine you started with this code snippet: let x = f a y = g x in h x y If you fully convert that to CPS you’d end up with 3 continuations (I think) and it would be much harder to understand. And adding an additional let binding later might involve a bunch of restructuring. I assume it just means that sort of thing. When someone first learns about continuations and their generality, it can be tempting to go overboard. Jeff > On Aug 31, 2021, at 3:03 AM, YueCompl via Haskell-Cafe wrote: > > Dear Cafe, > > I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now: > > > Abuse of the Continuation monad can produce code that is impossible to understand and maintain. > > Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:text=Abuse%20of%20the%20Continuation%20monad%20can%20produce%20code%20that%20is%20impossible%20to%20understand%20and%20maintain > > But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid. > > Please share what you know about it, many appreciations! > > Background of my CPS necessarity: > > Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context. > > Thanks, > Compl > > _______________________________________________ > 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 sperber at deinprogramm.de Tue Aug 31 15:45:32 2021 From: sperber at deinprogramm.de (Michael Sperber) Date: Tue, 31 Aug 2021 17:45:32 +0200 Subject: [Haskell-cafe] Type synonym involing quantified constraint? Message-ID: I'm working on Conal's ConCat code, and keep putting quantified constraints like this in instance constraints: (okk ~ Ok k, forall x y. (okk x, okk y) => okk (Prod k x y)) (The okk ~ Ok k is necessary because Ok is an associated type.) Is there any way to define a type synonym for this? Like type OkProd k = (okk ~ Ok k, forall x y. (okk x, okk y) => okk (Prod k x y)) ghc (8.10.4) complains about an impredicative type. Help would be much appreciated! -- Regards, Mike From lists at richarde.dev Tue Aug 31 18:09:17 2021 From: lists at richarde.dev (Richard Eisenberg) Date: Tue, 31 Aug 2021 18:09:17 +0000 Subject: [Haskell-cafe] Type synonym involing quantified constraint? In-Reply-To: References: Message-ID: <010f017b9d66ad82-3e7746d7-e103-400f-92fb-f4edcabbd824-000000@us-east-2.amazonses.com> This looks like a bug, which I've now filed: https://gitlab.haskell.org/ghc/ghc/-/issues/20318 The workaround is to enable ImpredicativeTypes. Sadly, ImpredicativeTypes is really a bug in GHC 8.10, fixed to work properly in GHC 9.2. So if I were doing this, I would define the offending synonym in a module all by itself so that the scope of ImpredicativeTypes is as small as possible. Richard > On Aug 31, 2021, at 11:45 AM, Michael Sperber wrote: > > > I'm working on Conal's ConCat code, and keep putting quantified > constraints like this in instance constraints: > > (okk ~ Ok k, forall x y. (okk x, okk y) => okk (Prod k x y)) > > (The okk ~ Ok k is necessary because Ok is an associated type.) > > Is there any way to define a type synonym for this? Like > > type OkProd k = (okk ~ Ok k, forall x y. (okk x, okk y) => okk (Prod k x y)) > > ghc (8.10.4) complains about an impredicative type. > > Help would be much appreciated! > > -- > Regards, > Mike > > _______________________________________________ > 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.