From leiva.steven at gmail.com Sat May 1 14:01:21 2021 From: leiva.steven at gmail.com (Steven Leiva) Date: Sat, 1 May 2021 09:01:21 -0500 Subject: [Haskell-cafe] Free online intro/advanced Haskell courses [YouTube] In-Reply-To: References: Message-ID: <99982042-5d52-462f-be96-a96514d40899@Spark> A great book, and now some great videos. Thank you Professor Hutton! On Apr 30, 2021, 3:30 AM -0500, Graham Hutton , wrote: > Hi all, > > For the last few months, I've been preparing YouTube videos for > the introductory and advanced Haskell courses that I teach to > students at the University of Nottingham. The courses have now > finished, and the full sets of videos are now available: > > Intro course: http://www.tinyurl.com/haskell-notts > > Advanced course: http://www.tinyurl.com/haskell-notts2 > > There’s also a 25% discount for the textbook on which both of > the courses are based, Programming in Haskell: > > Discount link: http://tinyurl.com/25pct-off > > Best wishes, > > Graham > > — > Professor Graham Hutton > School of Computer Science > University of Nottingham, UK > http://www.cs.nott.ac.uk/~pszgmh > > > > > This message and any attachment are intended solely for the addressee > and may contain confidential information. If you have received this > message in error, please contact the sender and delete the email and > attachment. > > Any views or opinions expressed by the author of this email do not > necessarily reflect the views of the University of Nottingham. Email > communications with the University of Nottingham may be monitored > where permitted by law. > > > > > _______________________________________________ > 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 m at jaspervdj.be Sun May 2 18:33:00 2021 From: m at jaspervdj.be (Jasper Van der Jeugt) Date: Sun, 2 May 2021 20:33:00 +0200 Subject: [Haskell-cafe] [Announcement] ZuriHac 2021 (18-20 June) - Registration now open Message-ID: <20210502183300.GA405@taiyaki> Hey Haskell friends, We are happy to announce that you can now register for ZuriHac 2021. It will take place from Friday 18th to Sunday 20th of June. Like last year, we are holding the event online. While we are sad that we don't yet get to see each other in person, this also allowed ~1000 people to join in 2021, instead of the usual 400-500 in Zurich. We have a couple of exciting things lined up for you this year. Here is a peek preview, but you can always check out https://zurihac.com for up-to-date information. This year, we are honoured to have talks by: - Emily Pillmore - Gabriele Keller - John Hughes - Veronika Romashkina And we have a couple of tutorials and teaching tracks in the works, as well as one more talk. We put a special focus on covering the whole beginner, intermediate, advanced spectrum: - There will be an advanced track held by our friends at Well-Typed. - digitally induced will teach you IHP, a new batteries-included web framework that has been gaining a lot of traction. Check it out at https://ihp.digitallyinduced.com/. - There will be a workshop on Unison, an exciting programming language that shares a lot of Haskell's syntax and semantics. Have a look at https://unisonweb.org/. We are working on more talks and tutorials, so expect further details to be communicated in the coming weeks. Keep an eye on our website! Apart from this, there will be the usual stuff that makes ZuriHac so much fun. There will be projects to hack on with other people, and the possibility to bring your own. There will be plenty of socialising, some impromptu hallway tracks, friendly fellow Haskellers to help you out, and an overall welcoming vibe. A quick note on how the online event works: - The main hub for the event will be on our Discord server. It worked really well for us last year, since it provided a sense of togetherness. It's easy to use, and it has chats, voice, and video. You will get a link when you register. - The talks will be streamed (and recorded) on YouTube. Q&A will be held on Discord. Check out last year's excellent talks: https://youtube.com/playlist?list=PLiU7KJ5_df6aZbNfh_TUJt-6w9N3rYkTX Registration is free and open as of right now: https://zureg.zfoh.ch/register/ Looking forward to seeing you in June! The Zurich Friends of Haskell - https://zfoh.ch From oleg.grenrus at iki.fi Mon May 3 10:53:24 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 3 May 2021 13:53:24 +0300 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> Message-ID: <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> Removing inference: yes, IMO it would be better then current state of affairs. Please write a proposal. However, `default-extensions: Safe` wouldn't just work. Often some modules are just Trustworthy, or even plain out Unsafe (e.g. in bytestring)     {-# LANGUAGE Safe #-}     {-# LANGUAGE Trustworthy #-} file errors with      ghc: SH.hs:2:14-24: Incompatible Safe Haskell flags! (Safe, Trustworthy) (same if you ghc -XSafe TrustworthyModule.hs) We can argue back and forth whether we should be able to override Safe-Haskell status. - Overriding would make sense, as -XHaskell2010 -XGHC2021 -XHaskell2010 works. - OTOH, safety is peculiar, so there probably was a discussion justifying current behavior, which is to prohibit overriding. (Probably one argument is that if the extensions are in module, then sorting them shouldn't change the result! with Safe Haskell it's harder to spot - you have to write tests - than with mixing up Haskell98/2010/GHC2021). Yet, I'll be happy with any option. - Oleg On 28.4.2021 21.07, Richard Eisenberg wrote: > > >> On Apr 28, 2021, at 11:51 AM, Oleg Grenrus > > wrote: >> >> TL;DR Safe Haskell requires buy-in from every maintainer, but there are >> barely >> any users. For how much longer we need to run this "academic experiment"? > > This is a good way to put it. The reason I've swung around in favor of > keeping what we have is that I think *some* structure like Safe > Haskell is needed for proper security. The idea is that an author > should have to trust only a few packages (like `bytestring`), and > these packages can advertise their wide level of trust in a central > location, like Hackage. This trust system exists now, but it's not > widely advertised. If we were to remove Safe Haskell, this trust > system would disappear, only (likely) to be replaced by a very similar > trust system required by the successor to Safe Haskell. > > So, given the real costs associated with discussing how best to remove > the feature, then removing it, then having libraries remove it, seem > not quite worth it. > > On the other hand, perhaps you've implicitly suggested something: just > disable Safe-inference. That is, every module starts off Unsafe. This > could easily be overridden at the package level with > default-extensions: Safe in a cabal file. If we had no safe-inference, > would that solve the library-level problems? It would certainly remove > a good deal of the complexity within GHC! > > Richard From x at tomsmeding.com Mon May 3 11:40:50 2021 From: x at tomsmeding.com (Tom Smeding) Date: Mon, 03 May 2021 11:40:50 +0000 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> Message-ID: On 03/05/2021 12:53, Oleg Grenrus wrote: > ... > - OTOH, safety is peculiar, so there probably was a discussion > justifying current behavior, which is to prohibit overriding. (Probably > one argument is that if the extensions are in module, then sorting them > shouldn't change the result! with Safe Haskell it's harder to spot - you > have to write tests - than with mixing up Haskell98/2010/GHC2021). I'm just a user, but I would be quite surprised if sorting the list of language extension pragmas in a module changes the semantics -- particularly for something safety-related. I would accept this behaviour for the Haskell98/... flags because if you have multiple of those explicitly listed in a file, you're doing something wrong anyway. But perhaps I'm being ignorant of other existing cases where this already matters, and I've been living in an idealised world until now. - Tom From coot at coot.me Mon May 3 12:04:04 2021 From: coot at coot.me (coot at coot.me) Date: Mon, 03 May 2021 12:04:04 +0000 Subject: [Haskell-cafe] Promoted data types Message-ID: Hello, Currently with `DataKind` extension, Haskell allows to promote terms / types to types / kinds. Currently, one cannot write: ``` data K a where K0 :: forall (x :: a). x -> K a ``` Because `K0` is both a term and a type constructor, and as a term and one cannot represent `x` of kind `a`. Is there a proposal or an issue to allow such declaration and error at use sites of `K0` as a term, rather than at declaration site? Best regards, Marcin Szamotulski -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From kai.prott at hotmail.de Mon May 3 13:10:36 2021 From: kai.prott at hotmail.de (Kai-Oliver Prott) Date: Mon, 3 May 2021 15:10:36 +0200 Subject: [Haskell-cafe] Promoted data types In-Reply-To: References: Message-ID: Hi, I think I don't quite understand the question. The code you propose seems wrong to me for a different reason: The type constructor (->) for function values has Kind: * -> * -> * In fact, GHC will print this error when compiling the snippet with the corresponding extensions. Promoting a data type is done differently. Can you elaborate on what exactly it is you are proposing? Sincerely Kai Prott On 03.05.21 14:04, coot at coot.me wrote: > Hello, > > Currently with `DataKind` extension, Haskell allows to promote terms / types to types / kinds. Currently, one cannot write: > > ``` > data K a where > K0 :: forall (x :: a). x -> K a > ``` > > Because `K0` is both a term and a type constructor, and as a term and one cannot represent `x` of kind `a`. Is there a proposal or an issue to allow such declaration and error at use sites of `K0` as a term, rather than at declaration site? > > Best regards, > Marcin Szamotulski > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Mon May 3 14:11:07 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 3 May 2021 14:11:07 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: References: Message-ID: <010f017932918297-2924c9ac-80d9-4df8-b3ff-7d8078e103d5-000000@us-east-2.amazonses.com> Perhaps Marcin is looking for https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0402-gadt-syntax.rst , but that proposal would not accept the code in the original post, for the reasons Kai describes -- you just cannot have (x :: a) on one side of an arrow. Richard > On May 3, 2021, at 9:10 AM, Kai-Oliver Prott wrote: > > Hi, > > I think I don't quite understand the question. > The code you propose seems wrong to me for a different reason: > The type constructor (->) for function values has Kind: * -> * -> * > > In fact, GHC will print this error when compiling the snippet with the corresponding extensions. > > Promoting a data type is done differently. > Can you elaborate on what exactly it is you are proposing? > > Sincerely > Kai Prott > On 03.05.21 14:04, coot at coot.me wrote: >> Hello, >> >> Currently with `DataKind` extension, Haskell allows to promote terms / types to types / kinds. Currently, one cannot write: >> >> ``` >> data K a where >> K0 :: forall (x :: a). x -> K a >> ``` >> >> Because `K0` is both a term and a type constructor, and as a term and one cannot represent `x` of kind `a`. Is there a proposal or an issue to allow such declaration and error at use sites of `K0` as a term, rather than at declaration site? >> >> Best regards, >> Marcin Szamotulski >> >> >> >> >> _______________________________________________ >> 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 rae at richarde.dev Mon May 3 14:25:03 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 3 May 2021 14:25:03 +0000 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> Message-ID: <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> > On May 3, 2021, at 7:40 AM, Tom Smeding wrote: > > But perhaps I'm being ignorant of other existing cases where this > already matters, and I've been living in an idealised world until now. Sad to say it, but order does matter here. In the very simple case, if you have {-# LANGUAGE FlexibleContexts, NoFlexibleContexts #-}, that's different from {-# LANGUAGE NoFlexibleContexts, FlexibleContexts #-} -- later extensions override earlier ones. This problem becomes more confounding when we recognize that some extensions imply others. For example {-# LANGUAGE TypeFamilies, NoMonoLocalBinds #-} means something different from {-# LANGUAGE NoMonoLocalBinds, TypeFamilies #-} because TypeFamilies implies MonoLocalBinds. Perhaps even worse, {-# LANGUAGE CUSKs, StandaloneKindSignatures #-} differs from {-# LANGUAGE StandaloneKindSignatures, CUSKs #-} because StandaloneKindSignatures implies NoCUSKs. Returning to Safe Haskell: It's true that Safe cannot be overridden locally. This is implemented by the fact that NoSafe does not exist. To me, this design makes sense, because it means that compiling with `ghc -XSafe` is guaranteed to use Safe Haskell. So we would need something like a default-safety field in Cabal, that could be overridden locally. But, still, this may be easier than the status quo. Do we think this would work? Specifically: * Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} that changes the module-level default. This default names the safety level in effect for any module that declares none of Safe, Trustworthy, or Unsafe. * If -fdefault-safety is not specified at the command line, it is as if the user wrote -fdefault-safety=unsafe. And that's it. Consequence: Safe-inference would never take place, because every module would have a declared level of Safety. The Safe-inference code could thus be removed. Further work: Introduce default-safety in Cabal, but that's not really necessary to make the changes above. What do we think? Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From blamario at rogers.com Mon May 3 15:47:23 2021 From: blamario at rogers.com (Mario) Date: Mon, 3 May 2021 11:47:23 -0400 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> Message-ID: <96929b38-ca5c-fb9b-a839-9a2bf4c7320a@rogers.com> On 2021-05-03 10:25 a.m., Richard Eisenberg wrote: > It's true that Safe cannot be overridden locally. This is implemented > by the fact that NoSafe does not exist. To me, this design makes > sense, because it means that compiling with `ghc -XSafe` is guaranteed > to use Safe Haskell. So we would need something like a default-safety > field in Cabal, that could be overridden locally. > > But, still, this may be easier than the status quo. I don't see why this should be easier. I do understand how type checking is easier than type inference, but in this case the "type" of the module (and every declaration in it) is a single bit: Safe or Unsafe. How can checking whether a declaration is safe can be easier than inferring whether it is? I must be misunderstanding your proposal. > Do we think this would work? Specifically: > > * Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} that > changes the module-level default. This default names the safety level > in effect for any module that declares none of Safe, Trustworthy, or > Unsafe. > * If -fdefault-safety is not specified at the command line, it is as > if the user wrote -fdefault-safety=unsafe. > > And that's it. > > Consequence: Safe-inference would never take place, because every > module would have a declared level of Safety. The Safe-inference code > could thus be removed. > > Further work: Introduce default-safety in Cabal, but that's not really > necessary to make the changes above. > > What do we think? > > Richard > > _______________________________________________ > 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 coot at coot.me Mon May 3 16:44:48 2021 From: coot at coot.me (coot at coot.me) Date: Mon, 03 May 2021 16:44:48 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: <010f017932918297-2924c9ac-80d9-4df8-b3ff-7d8078e103d5-000000@us-east-2.amazonses.com> References: <010f017932918297-2924c9ac-80d9-4df8-b3ff-7d8078e103d5-000000@us-east-2.amazonses.com> Message-ID: Thanks Richard, indeed that proposal would not help.  The snippet I posted is a valid GADT syntax.  When it is compiled with `DataKinds`, `PolyKinds` and `KindSignatures` ghc is is quite explicit why it refuses it: Expected a type, but `x` has a kind `a`, which is exactly what you said. However, I think it would be quite reasonable to accept it. In general ghc would only need to generate code for the case `a ~ Type`, all other use cases at term level must be refused. It might be enough to add a type inference rule which injects `a ~ Type` for any such term. Another missing puzzle is that there's no way to specify that one only wants the promoted types / kinds without the term level part. This could be done by specifying an explicit kind signature: ``` type K0 :: a -> K a data K a where   K0 :: forall a (x :: a) -> K a ``` Now this is refused with `The standalone kind signature for 'K0' lacks an accompynying binding`. It's not the first time I stumbled upon this.  The latest incarnation is a gist in which I worked out how to encode pipelining using a type level queue / list in a session type framework which we use at work for developing protocols: https://gist.github.com/coot/b568ebc7bac2e4e31cb54bf3939419d8#file-pipelined-hs-L94 Richard, does it sound reasonable to you? If so, what would be the right process to propose / implement such a feature? I don't think it would require a new extension, rather modify how `DataKind` works in presence of `PolyKinds` and `StandaloneKindSignatures`. Maybe this is in scope of the dependent type Haskell workstream that you're doing? Best regards, Marcin ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, May 3rd, 2021 at 16:11, Richard Eisenberg wrote: > Perhaps Marcin is looking for https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0402-gadt-syntax.rst, but that proposal would not accept the code in the original post, for the reasons Kai describes -- you just cannot have (x :: a) on one side of an arrow. > > Richard > > > On May 3, 2021, at 9:10 AM, Kai-Oliver Prott wrote: > > > > Hi, > > > > I think I don't quite understand the question. > > > > The code you propose seems wrong to me for a different reason: > > > > The type constructor (->) for function values has Kind: * -> * -> * > > > > In fact, GHC will print this error when compiling the snippet with the corresponding extensions. > > > > Promoting a data type is done differently. > > > > Can you elaborate on what exactly it is you are proposing? > > > > Sincerely > > > > Kai Prott > > > > On 03.05.21 14:04, coot at coot.me wrote: > > > > > Hello, > > > > > > Currently with `DataKind` extension, Haskell allows to promote terms / types to types / kinds. Currently, one cannot write: > > > > > > ``` > > > data K a where > > > K0 :: forall (x :: a). x -> K a > > > ``` > > > > > > Because `K0` is both a term and a type constructor, and as a term and one cannot represent `x` of kind `a`. Is there a proposal or an issue to allow such declaration and error at use sites of `K0` as a term, rather than at declaration site? > > > > > > Best regards, > > > Marcin Szamotulski > > > > > > _______________________________________________ > > > 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: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From rae at richarde.dev Mon May 3 17:12:02 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 3 May 2021 17:12:02 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: References: <010f017932918297-2924c9ac-80d9-4df8-b3ff-7d8078e103d5-000000@us-east-2.amazonses.com> Message-ID: <010f0179333723f7-fb5705f8-b243-40c0-a40a-f93103666fbb-000000@us-east-2.amazonses.com> Hi Marcin, To understand your intent better, what do you think of this: > type K :: Bool -> Type > data K b where > MkK :: forall a (b :: a). K b Here, the issue isn't whether `a` is `Type`, but whether `a` is `Bool`. Do you think that should be accepted? And why restrict this only to GADT type signatures? What about > f :: forall a (b :: a). b -> b My personal opinion is that we should reject all of these, including your initial suggestion. You're right in that we could infer an extra equality constraint, but I think that would lead to a worse user experience: a definition is accepted only to be rejected at usage sites. It's almost like accepting > g x = not x : "hello" which could be accepted with an equality constraint (Bool ~ Char). I recognize this last one goes a step further into absurdity, but there is a balance between inferring equality constraints and issuing helpful errors. Put another way: Why not write your original datatype as > data K a where > K0 :: forall (x :: Type). x -> K Type ? That would be accepted and may have your intended meaning. > On May 3, 2021, at 12:44 PM, coot at coot.me wrote: > > Another missing puzzle is that there's no way to specify that one only wants the promoted types / kinds without the term level part. Aha. This one really has been proposed (and accepted!): https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0106-type-data.rst There is no one working on an implementation of it yet, though. I'd be happy to advise someone who wanted to dive in! Richard From coot at coot.me Mon May 3 19:59:05 2021 From: coot at coot.me (coot at coot.me) Date: Mon, 03 May 2021 19:59:05 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: <010f0179333723f7-fb5705f8-b243-40c0-a40a-f93103666fbb-000000@us-east-2.amazonses.com> References: <010f017932918297-2924c9ac-80d9-4df8-b3ff-7d8078e103d5-000000@us-east-2.amazonses.com> <010f0179333723f7-fb5705f8-b243-40c0-a40a-f93103666fbb-000000@us-east-2.amazonses.com> Message-ID: Hi Richard, > type K :: Bool -> Type > data K b where > MkK :: forall a (b :: a). K b This requests `b` to be of kind `a` for any `a`, and it constraint `b` to by of kind `Bool`, so this cannot be satisfied. > data K a where > K0 :: forall (x :: Type). x -> K Type There are two levels here: 1. `K a` is a perfectly defined type with a single constructor `K0`. This is not what I am looking for. 2. `K a` is a kind, `K0 x` for any `x :: Type` is a type of kind `K a`. This will work only for `x`-es which are of kind `Type`, am interested in `x`-es which are of other kind. So one can proceed with this: > data K a where > K0 :: forall x. x -> K a The problem here is that the promoted type `K0` is too broad, I'd like to express that I am only interested with `x`-es of kind `a`. > f :: forall a (b :: a). b -> b Let's get one step back. If I couldn't write this > f :: forall (b :: A). b -> b I would be forced to write this > f :: forall b. b -> b And these are very different (e.g. free theorems). The concrete 'A', in my case gets generalised and constraint by some type class. Hence the framework requires > f :: forall a (b :: a). b -> b though all the instances provide and use a concrete `a`. I see your point on error messages, maybe there's a way around it. Let's say that the author must provide an explicit kind signature, e.g. > type K0 :: a -> K a > data K a where > K0 :: x -> K a Such K0 can only be a type; When one would use it at a term level GHC should say: data constructor not in scope (and possibly explain that there is a type of the same name). Marcin ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, May 3rd, 2021 at 19:12, Richard Eisenberg wrote: > Hi Marcin, > > To understand your intent better, what do you think of this: > > > type K :: Bool -> Type > > > > data K b where > > > > MkK :: forall a (b :: a). K b > > Here, the issue isn't whether `a` is `Type`, but whether `a` is `Bool`. Do you think that should be accepted? > > And why restrict this only to GADT type signatures? What about > > > f :: forall a (b :: a). b -> b > > My personal opinion is that we should reject all of these, including your initial suggestion. You're right in that we could infer an extra equality constraint, but I think that would lead to a worse user experience: a definition is accepted only to be rejected at usage sites. It's almost like accepting > > > g x = not x : "hello" > > which could be accepted with an equality constraint (Bool ~ Char). I recognize this last one goes a step further into absurdity, but there is a balance between inferring equality constraints and issuing helpful errors. > > Put another way: Why not write your original datatype as > > > data K a where > > > > K0 :: forall (x :: Type). x -> K Type > > ? That would be accepted and may have your intended meaning. > > > On May 3, 2021, at 12:44 PM, coot at coot.me wrote: > > > > Another missing puzzle is that there's no way to specify that one only wants the promoted types / kinds without the term level part. > > Aha. This one really has been proposed (and accepted!): https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0106-type-data.rst > > There is no one working on an implementation of it yet, though. I'd be happy to advise someone who wanted to dive in! > > Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From david.feuer at gmail.com Mon May 3 20:44:55 2021 From: david.feuer at gmail.com (David Feuer) Date: Mon, 3 May 2021 16:44:55 -0400 Subject: [Haskell-cafe] Promoted data types In-Reply-To: References: Message-ID: On Mon, May 3, 2021, 8:04 AM wrote: > Currently with `DataKind` extension, Haskell allows to promote terms / > types to types / kinds. Currently, one cannot write: > > ``` > data K a where > K0 :: forall (x :: a). x -> K a > ``` > I feel like I'm missing something. Suppose `a` is not Type but rather, say, Bool. Then `x` has kind Bool. That is, x is 'True, 'False, or something exotic. K0 @Bool is then a function that takes anything of type 'True or type 'False and gives you something of type K Bool. What I think Richard is getting at is that there isn't anything of type 'True or type 'False, whether at the term level or the type level. These things only exist when `a` is Type (or TYPE rep for some rep :: RuntimeRep). So it's pretty hard to see what you're trying to do. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coot at coot.me Mon May 3 21:26:46 2021 From: coot at coot.me (coot at coot.me) Date: Mon, 03 May 2021 21:26:46 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: References: Message-ID: Hi David, My workaround is to use: > data K a where >   K0 :: forall a b. b -> K a The kind `K Bool` contains things like: > :kind! K0 'True (K0 'True) :: K Bool > :kind! K0 'False (K0 'True) :: K Bool But also > :kind! (K0 Int :: K Bool) (K0 Int :: K Bool) :: K Bool and I'd like to have a way to not allow to construct such a type. Oh!, what I just realised is that I can actually achieve what I want by simply declaring: > data K a where >   K0 :: forall a. a -> K a Now the type constructor of a type of kind `K Bool`, must is `K0 'True`, `K0 'False`, or `K0` of some exotic type of kind `Bool`. Thanks for making me realise that! Regards, Marcin ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Monday, May 3rd, 2021 at 22:44, David Feuer wrote: > On Mon, May 3, 2021, 8:04 AM wrote: > > > Currently with `DataKind` extension, Haskell allows to promote terms / types to types / kinds.  Currently, one cannot write: > > > > ``` > > > > data K a where > > > >   K0 :: forall (x :: a). x -> K a > > > > ``` > > I feel like I'm missing something. Suppose `a` is not Type but rather, say, Bool. Then `x` has kind Bool. That is, x is 'True, 'False, or something exotic. K0 @Bool is then a function that takes anything of type 'True or type 'False and gives you something of type K Bool. What I think Richard is getting at is that there isn't anything of type 'True or type 'False, whether at the term level or the type level. These things only exist when `a` is Type (or TYPE rep for some rep :: RuntimeRep). So it's pretty hard to see what you're trying to do. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From rae at richarde.dev Mon May 3 21:57:41 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Mon, 3 May 2021 21:57:41 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: References: Message-ID: <010f0179343ca9ef-e3e4128b-6fad-418f-bd4e-8b49d680d475-000000@us-east-2.amazonses.com> Sounds like you've figured this out, so I won't write a long response to your previous email -- but let me know if there are still outstanding questions there. Thanks, Richard > On May 3, 2021, at 5:26 PM, coot at coot.me wrote: > > Now the type constructor of a type of kind `K Bool`, must is `K0 'True`, `K0 'False`, or `K0` of some exotic type of kind `Bool`. > > Thanks for making me realise that! -------------- next part -------------- An HTML attachment was scrubbed... URL: From coot at coot.me Mon May 3 23:50:10 2021 From: coot at coot.me (coot at coot.me) Date: Mon, 03 May 2021 23:50:10 +0000 Subject: [Haskell-cafe] Promoted data types In-Reply-To: <010f0179343ca9ef-e3e4128b-6fad-418f-bd4e-8b49d680d475-000000@us-east-2.amazonses.com> References: <010f0179343ca9ef-e3e4128b-6fad-418f-bd4e-8b49d680d475-000000@us-east-2.amazonses.com> Message-ID: Thank you Richard, everything clear now. Sent from ProtonMail mobile \-------- Original Message -------- On 3 May 2021, 23:57, Richard Eisenberg < rae at richarde.dev> wrote: > > Sounds like you've figured this out, so I won't write a long response to your previous email -- but let me know if there are still outstanding questions there. > > > > > Thanks, > > Richard > > > > > > > On May 3, 2021, at 5:26 PM, [coot at coot.me][coot_coot.me] wrote: > > > > > > > > > > Now the type constructor of a type of kind \`K Bool\`, must is \`K0 'True\`, \`K0 'False\`, or \`K0\` of some exotic type of kind \`Bool\`. > > > > Thanks for making me realise that! > > > [coot_coot.me]: mailto:coot at coot.me -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 554 bytes Desc: OpenPGP digital signature URL: From Graham.Hutton at nottingham.ac.uk Tue May 4 09:31:25 2021 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Tue, 4 May 2021 09:31:25 +0000 Subject: [Haskell-cafe] Journal of Functional Programming - Call for PhD Abstracts Message-ID: <260B8465-C20E-4028-8315-05B6A5A44A3E@nottingham.ac.uk> Dear all, If you or one of your students recently completed a PhD in the area of functional programming, please submit the dissertation abstract for publication in JFP: simple process, no refereeing, open access, ~200 published to date, deadline 31st May 2021. Please share! Best wishes, Graham Hutton ============================================================ CALL FOR PHD ABSTRACTS Journal of Functional Programming Deadline: 31st May 2021 http://tinyurl.com/jfp-phd-abstracts ============================================================ PREAMBLE: Many students complete PhDs in functional programming each year. As a service to the community, twice per year the Journal of Functional Programming publishes the abstracts from PhD dissertations completed during the previous year. The abstracts are made freely available on the JFP website, i.e. not behind any paywall. They do not require any transfer of copyright, merely a license from the author. A dissertation is eligible for inclusion if parts of it have or could have appeared in JFP, that is, if it is in the general area of functional programming. The abstracts are not reviewed. Please submit dissertation abstracts according to the instructions below. We welcome submissions from both the PhD student and PhD advisor/supervisor although we encourage them to coordinate. ============================================================ SUBMISSION: Please submit the following information to Graham Hutton by 31st May 2021: o Dissertation title: (including any subtitle) o Student: (full name) o Awarding institution: (full name and country) o Date of PhD award: (month and year; depending on the institution, this may be the date of the viva, corrections being approved, graduation ceremony, or otherwise) o Advisor/supervisor: (full names) o Dissertation URL: (please provide a permanently accessible link to the dissertation if you have one, such as to an institutional repository or other public archive; links to personal web pages should be considered a last resort) o Dissertation abstract: (plain text, maximum 350 words; you may use \emph{...} for emphasis, but we prefer no other markup or formatting; if your original abstract exceeds the word limit, please submit an abridged version within the limit) Please do not submit a copy of the dissertation itself, as this is not required. JFP reserves the right to decline to publish abstracts that are not deemed appropriate. ============================================================ PHD ABSTRACT EDITOR: Graham Hutton School of Computer Science University of Nottingham Nottingham NG8 1BB United Kingdom ============================================================ 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 carter.schonwald at gmail.com Tue May 4 12:10:54 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 4 May 2021 08:10:54 -0400 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> Message-ID: Default safety isn’t quite what you want in normal packages, because that disables all user land rewrite rules! It may have other implications too, but short of augmenting ghc with a proof system for correctness of rewrite rules, default safehaskell is at odds with optimized builds. On Mon, May 3, 2021 at 10:28 AM Richard Eisenberg wrote: > > > On May 3, 2021, at 7:40 AM, Tom Smeding wrote: > > But perhaps I'm being ignorant of other existing cases where this > already matters, and I've been living in an idealised world until now. > > > Sad to say it, but order does matter here. > > In the very simple case, if you have {-# LANGUAGE FlexibleContexts, > NoFlexibleContexts #-}, that's different from {-# LANGUAGE > NoFlexibleContexts, FlexibleContexts #-} -- later extensions override > earlier ones. This problem becomes more confounding when we recognize that > some extensions imply others. For example {-# LANGUAGE TypeFamilies, > NoMonoLocalBinds #-} means something different from {-# LANGUAGE > NoMonoLocalBinds, TypeFamilies #-} because TypeFamilies implies > MonoLocalBinds. Perhaps even worse, {-# LANGUAGE CUSKs, > StandaloneKindSignatures #-} differs from {-# LANGUAGE > StandaloneKindSignatures, CUSKs #-} because StandaloneKindSignatures > implies NoCUSKs. > > Returning to Safe Haskell: > > It's true that Safe cannot be overridden locally. This is implemented by > the fact that NoSafe does not exist. To me, this design makes sense, > because it means that compiling with `ghc -XSafe` is guaranteed to use Safe > Haskell. So we would need something like a default-safety field in Cabal, > that could be overridden locally. > > But, still, this may be easier than the status quo. > > Do we think this would work? Specifically: > > * Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} that > changes the module-level default. This default names the safety level in > effect for any module that declares none of Safe, Trustworthy, or Unsafe. > * If -fdefault-safety is not specified at the command line, it is as if > the user wrote -fdefault-safety=unsafe. > > And that's it. > > Consequence: Safe-inference would never take place, because every module > would have a declared level of Safety. The Safe-inference code could thus > be removed. > > Further work: Introduce default-safety in Cabal, but that's not really > necessary to make the changes above. > > What do we think? > > Richard > _______________________________________________ > 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 Tue May 4 12:31:33 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 4 May 2021 15:31:33 +0300 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> Message-ID: <327cafc7-e21b-e07c-167c-d101fbe8ac9d@iki.fi> The GHC manual says [1] RULES — Rewrite rules defined in a module M compiled with Safe are dropped. Rules defined in Trustworthy modules that M imports are still valid and will fire as usual. So rules are still in use, and e.g. list fusion works. Library authors cannot define their own RULES in Safe modules, but they are (always, no need to -Wall) warned about the fact that these rules are ignored. I don't see a possibility for silent performance regressions. - Oleg [1]: https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/safe_haskell.html#building-secure-systems-restricted-io-monads On 4.5.2021 15.10, Carter Schonwald wrote: > Default safety isn’t quite what you want in normal packages, because > that disables all user land rewrite rules! It may have other > implications too, but short of augmenting ghc with a proof system for > correctness of rewrite rules, default safehaskell is at odds with > optimized builds.  > > On Mon, May 3, 2021 at 10:28 AM Richard Eisenberg > wrote: > > > >> On May 3, 2021, at 7:40 AM, Tom Smeding > > wrote: >> >> But perhaps I'm being ignorant of other existing cases where this >> already matters, and I've been living in an idealised world until >> now. > > Sad to say it, but order does matter here. > > In the very simple case, if you have {-# LANGUAGE > FlexibleContexts, NoFlexibleContexts #-}, that's different from > {-# LANGUAGE NoFlexibleContexts, FlexibleContexts #-} -- later > extensions override earlier ones. This problem becomes more > confounding when we recognize that some extensions imply others. > For example {-# LANGUAGE TypeFamilies, NoMonoLocalBinds #-} means > something different from {-# LANGUAGE NoMonoLocalBinds, > TypeFamilies #-} because TypeFamilies implies MonoLocalBinds. > Perhaps even worse, {-# LANGUAGE CUSKs, StandaloneKindSignatures > #-} differs from {-# LANGUAGE StandaloneKindSignatures, CUSKs #-} > because StandaloneKindSignatures implies NoCUSKs. > > Returning to Safe Haskell: > > It's true that Safe cannot be overridden locally. This is > implemented by the fact that NoSafe does not exist. To me, this > design makes sense, because it means that compiling with `ghc > -XSafe` is guaranteed to use Safe Haskell. So we would need > something like a default-safety field in Cabal, that could be > overridden locally. > > But, still, this may be easier than the status quo. > > Do we think this would work? Specifically: > > * Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} > that changes the module-level default. This default names the > safety level in effect for any module that declares none of Safe, > Trustworthy, or Unsafe. > * If -fdefault-safety is not specified at the command line, it is > as if the user wrote -fdefault-safety=unsafe. > > And that's it. > > Consequence: Safe-inference would never take place, because every > module would have a declared level of Safety. The Safe-inference > code could thus be removed. > > Further work: Introduce default-safety in Cabal, but that's not > really necessary to make the changes above. > > What do we think? > > Richard > _______________________________________________ > 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 carter.schonwald at gmail.com Tue May 4 18:38:43 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 4 May 2021 14:38:43 -0400 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: <327cafc7-e21b-e07c-167c-d101fbe8ac9d@iki.fi> References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> <327cafc7-e21b-e07c-167c-d101fbe8ac9d@iki.fi> Message-ID: Are you sure? It also says "The use of Safe to compile Danger restricts the features of Haskell that can be used to a safe subset. This includes disallowing unsafePerformIO, Template Haskell, pure FFI functions, RULES and restricting the operation of Overlapping Instances." On Tue, May 4, 2021 at 8:32 AM Oleg Grenrus wrote: > The GHC manual says [1] > > RULES — Rewrite rules defined in a module M compiled with Safe are > dropped. Rules defined in Trustworthy modules that M imports are still > valid and will fire as usual. > > So rules are still in use, and e.g. list fusion works. Library authors > cannot define their own RULES in Safe modules, but they are (always, no > need to -Wall) warned about the fact that these rules are ignored. I > don't see a possibility for silent performance regressions. > > - Oleg > > [1]: > > https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/safe_haskell.html#building-secure-systems-restricted-io-monads > > On 4.5.2021 15.10, Carter Schonwald wrote: > > > Default safety isn’t quite what you want in normal packages, because > > that disables all user land rewrite rules! It may have other > > implications too, but short of augmenting ghc with a proof system for > > correctness of rewrite rules, default safehaskell is at odds with > > optimized builds. > > > > On Mon, May 3, 2021 at 10:28 AM Richard Eisenberg > > wrote: > > > > > > > >> On May 3, 2021, at 7:40 AM, Tom Smeding >> > wrote: > >> > >> But perhaps I'm being ignorant of other existing cases where this > >> already matters, and I've been living in an idealised world until > >> now. > > > > Sad to say it, but order does matter here. > > > > In the very simple case, if you have {-# LANGUAGE > > FlexibleContexts, NoFlexibleContexts #-}, that's different from > > {-# LANGUAGE NoFlexibleContexts, FlexibleContexts #-} -- later > > extensions override earlier ones. This problem becomes more > > confounding when we recognize that some extensions imply others. > > For example {-# LANGUAGE TypeFamilies, NoMonoLocalBinds #-} means > > something different from {-# LANGUAGE NoMonoLocalBinds, > > TypeFamilies #-} because TypeFamilies implies MonoLocalBinds. > > Perhaps even worse, {-# LANGUAGE CUSKs, StandaloneKindSignatures > > #-} differs from {-# LANGUAGE StandaloneKindSignatures, CUSKs #-} > > because StandaloneKindSignatures implies NoCUSKs. > > > > Returning to Safe Haskell: > > > > It's true that Safe cannot be overridden locally. This is > > implemented by the fact that NoSafe does not exist. To me, this > > design makes sense, because it means that compiling with `ghc > > -XSafe` is guaranteed to use Safe Haskell. So we would need > > something like a default-safety field in Cabal, that could be > > overridden locally. > > > > But, still, this may be easier than the status quo. > > > > Do we think this would work? Specifically: > > > > * Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} > > that changes the module-level default. This default names the > > safety level in effect for any module that declares none of Safe, > > Trustworthy, or Unsafe. > > * If -fdefault-safety is not specified at the command line, it is > > as if the user wrote -fdefault-safety=unsafe. > > > > And that's it. > > > > Consequence: Safe-inference would never take place, because every > > module would have a declared level of Safety. The Safe-inference > > code could thus be removed. > > > > Further work: Introduce default-safety in Cabal, but that's not > > really necessary to make the changes above. > > > > What do we think? > > > > Richard > > _______________________________________________ > > 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 carter.schonwald at gmail.com Tue May 4 18:47:02 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 4 May 2021 14:47:02 -0400 Subject: [Haskell-cafe] Safe Haskell? In-Reply-To: References: <010f0178dc106f34-c2d5b25f-00ce-40bb-bb5c-684bcaa3a765-000000@us-east-2.amazonses.com> <010f017919aa12b1-e075ad42-3c3e-486a-97f7-e45a1e53d31d-000000@us-east-2.amazonses.com> <359f0390-9505-1a18-5b5f-0c7c847a0cbc@iki.fi> <010f0179329e42d8-34ac3251-d09e-4c54-b6bc-06cd02c15b71-000000@us-east-2.amazonses.com> <327cafc7-e21b-e07c-167c-d101fbe8ac9d@iki.fi> Message-ID: Hrmm “ - RULES — Rewrite rules defined in a module M compiled with Safe are dropped. Rules defined in Trustworthy modules that M imports are still valid and will fire as usual. ” Huh I suppose I’m wrong! I thought it was difference or more subtle than that On Tue, May 4, 2021 at 2:38 PM Carter Schonwald wrote: > Are you sure? > > It also says "The use of Safe to compile Danger restricts the features > of Haskell that can be used to a safe subset. This includes disallowing > unsafePerformIO, Template Haskell, pure FFI functions, RULES and > restricting the operation of Overlapping Instances." > > > On Tue, May 4, 2021 at 8:32 AM Oleg Grenrus wrote: > >> The GHC manual says [1] >> >> RULES — Rewrite rules defined in a module M compiled with Safe are >> dropped. Rules defined in Trustworthy modules that M imports are still >> valid and will fire as usual. >> >> So rules are still in use, and e.g. list fusion works. Library authors >> cannot define their own RULES in Safe modules, but they are (always, no >> need to -Wall) warned about the fact that these rules are ignored. I >> don't see a possibility for silent performance regressions. >> >> - Oleg >> >> [1]: >> >> https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/safe_haskell.html#building-secure-systems-restricted-io-monads >> >> On 4.5.2021 15.10, Carter Schonwald wrote: >> >> > Default safety isn’t quite what you want in normal packages, because >> > that disables all user land rewrite rules! It may have other >> > implications too, but short of augmenting ghc with a proof system for >> > correctness of rewrite rules, default safehaskell is at odds with >> > optimized builds. >> > >> > On Mon, May 3, 2021 at 10:28 AM Richard Eisenberg > > > wrote: >> > >> > >> > >> >> On May 3, 2021, at 7:40 AM, Tom Smeding > >> > wrote: >> >> >> >> But perhaps I'm being ignorant of other existing cases where this >> >> already matters, and I've been living in an idealised world until >> >> now. >> > >> > Sad to say it, but order does matter here. >> > >> > In the very simple case, if you have {-# LANGUAGE >> > FlexibleContexts, NoFlexibleContexts #-}, that's different from >> > {-# LANGUAGE NoFlexibleContexts, FlexibleContexts #-} -- later >> > extensions override earlier ones. This problem becomes more >> > confounding when we recognize that some extensions imply others. >> > For example {-# LANGUAGE TypeFamilies, NoMonoLocalBinds #-} means >> > something different from {-# LANGUAGE NoMonoLocalBinds, >> > TypeFamilies #-} because TypeFamilies implies MonoLocalBinds. >> > Perhaps even worse, {-# LANGUAGE CUSKs, StandaloneKindSignatures >> > #-} differs from {-# LANGUAGE StandaloneKindSignatures, CUSKs #-} >> > because StandaloneKindSignatures implies NoCUSKs. >> > >> > Returning to Safe Haskell: >> > >> > It's true that Safe cannot be overridden locally. This is >> > implemented by the fact that NoSafe does not exist. To me, this >> > design makes sense, because it means that compiling with `ghc >> > -XSafe` is guaranteed to use Safe Haskell. So we would need >> > something like a default-safety field in Cabal, that could be >> > overridden locally. >> > >> > But, still, this may be easier than the status quo. >> > >> > Do we think this would work? Specifically: >> > >> > * Introduce a new flag -fdefault-safety={safe,trustworthy,unsafe} >> > that changes the module-level default. This default names the >> > safety level in effect for any module that declares none of Safe, >> > Trustworthy, or Unsafe. >> > * If -fdefault-safety is not specified at the command line, it is >> > as if the user wrote -fdefault-safety=unsafe. >> > >> > And that's it. >> > >> > Consequence: Safe-inference would never take place, because every >> > module would have a declared level of Safety. The Safe-inference >> > code could thus be removed. >> > >> > Further work: Introduce default-safety in Cabal, but that's not >> > really necessary to make the changes above. >> > >> > What do we think? >> > >> > Richard >> > _______________________________________________ >> > 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 W.S.Swierstra at uu.nl Thu May 6 15:05:07 2021 From: W.S.Swierstra at uu.nl (Swierstra, W.S. (Wouter)) Date: Thu, 6 May 2021 15:05:07 +0000 Subject: [Haskell-cafe] (Online) Utrecht Summer School on Advanced functional programming Message-ID: <959d805c-b436-7357-4ba7-893788c394bb@uu.nl> SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Online - 05-9 July 2021 http://www.afp.school # Call for Participation ## About The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. This year the course will be offered *online only*. A typical day will consist a 2-3 hours of lectures, sandwiched between supervised lab sessions. Lectures will be held in the (European) afternoon, but recordings will be made available if attending live is problematic. The lectures will cover several more advanced topics regarding programming with types in Haskell, including topics such as: * monads and applicative functors; * lambda calculus; * generalized algebraic datatypes; * datatype generic programming * type families and type-level programming; ## Lecturers Utrecht staff: * Gabriele Keller * Trevor McDonell * Wouter Swierstra ## Prerequisites We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. Soft registration deadline: 1 June, 2021 School: 05-09 July, 2021 ## Costs 50 euro - Registration fee We ask ask participants to pay a small registration fee to cover some of our organizational expenses. If this is problematic for you *for whatever reason*, please let us know and we can waive your registration fee. ## Further information Further information, including instructions on how to register, is available on our website: http://www.afp.school From stu204767 at mail.uni-kiel.de Thu May 6 20:34:36 2021 From: stu204767 at mail.uni-kiel.de (=?UTF-8?Q?Leif-Erik_Kr=C3=BCger?=) Date: Thu, 06 May 2021 22:34:36 +0200 Subject: [Haskell-cafe] Repeating type variables in MultiParamTypeClasses instance heads Message-ID: <64bae47f4397f0e45d9a44390a50fd99@mail.uni-kiel.de> Hello Haskell-Cafe, I have a question regarding the rules on type class instances with the MultiParamTypeClasses extension. For single-parameter type classes, there is the restriction that an instance head must have the form `C (T a1 ... an)`, where `C` is a type class, `T` is a data type constructor and `a1 ... an` are distinct type variables ( https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/instances.html ). To my knowledge, this restriction ensures the impossibility of potential overlap between instances (except for the case where two instance heads are equivalent, but this case is caught by an error message). This restriction can be lifted with the FlexibleInstances extension, so that instances like `instance C (a, a, b)` and `instance C (a, b, b)` are allowed. As can be seen in this example, FlexibleInstances introduces the potential of overlap with single-parameter type classes. When using MultiParamTypeClasses without FlexibleInstances, the current restrictions on instance heads are similiar to those for single-parameter classes. For each parameter, the instance type must have the form `(T a1 ... an)` with `a1 ... an` being distinct from one another, but type variables can be shared between instance types. Therefore, instances like `instance D [a] [a] [b]` and `instance D [a] [b] [b]` are allowed and do cause potential overlap. If there was the restriction of all type variables in the instance head being different from one another however, I think there would be no potential for overlap, just like with single-parameter type classes. To me, these instances allowed by MultiParamTypeClasses seem similar to the single-parameter class instances that are only possible with FlexibleInstances. And just like FlexibleInstances for single-parameter class instances, they introduce potential overlap, so that the MultiParamTypeClasses extension by itself becomes less "safe" than it otherwise would be. Therefore, it seems reasonable to me to only allow these repeated type variables in instance heads with the FlexibleInstances extension. So, is there a good reason for the design choice of allowing these kinds of overlap without FlexibleInstances? Am I missing something here? Or are the current rules the way they are because of historic reasons? Best regards, Leif-Erik Krüger -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Thu May 6 20:51:32 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Thu, 6 May 2021 22:51:32 +0200 (CEST) Subject: [Haskell-cafe] Repeating type variables in MultiParamTypeClasses instance heads In-Reply-To: <64bae47f4397f0e45d9a44390a50fd99@mail.uni-kiel.de> References: <64bae47f4397f0e45d9a44390a50fd99@mail.uni-kiel.de> Message-ID: <4e52d9fa-b6d-9df0-4142-186669056c4@henning-thielemann.de> On Thu, 6 May 2021, Leif-Erik Krüger wrote: > So, is there a good reason for the design choice of allowing these kinds > of overlap without FlexibleInstances? Am I missing something here? I am surprised. I just tried it with different GHC versions, all of them accept those overlapping instances without enabling FlexibleInstances. {-# LANGUAGE MultiParamTypeClasses #-} module FlexibleInstance where class C a b c where instance C [a] [a] [b] where instance C [a] [b] [b] where From ietf-dane at dukhovni.org Thu May 6 21:05:04 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Thu, 6 May 2021 17:05:04 -0400 Subject: [Haskell-cafe] Repeating type variables in MultiParamTypeClasses instance heads In-Reply-To: <4e52d9fa-b6d-9df0-4142-186669056c4@henning-thielemann.de> References: <64bae47f4397f0e45d9a44390a50fd99@mail.uni-kiel.de> <4e52d9fa-b6d-9df0-4142-186669056c4@henning-thielemann.de> Message-ID: On Thu, May 06, 2021 at 10:51:32PM +0200, Henning Thielemann wrote: > {-# LANGUAGE MultiParamTypeClasses #-} > module FlexibleInstance where > > class C a b c where This class has an empty interface, it just builds triples of types that imply a constraint. No matter how many such triples one creates, there can't be any conflict between them. > instance C [a] [a] [b] where > instance C [a] [b] [b] where These don't conflict. -- Viktor. From olf at aatal-apotheke.de Thu May 6 21:17:42 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Thu, 06 May 2021 23:17:42 +0200 Subject: [Haskell-cafe] bootstrapping a monad via continuations Message-ID: <76140efba51b9ca9bc8db4c477865f3b936db9ef.camel@aatal-apotheke.de> Dear Café, I've been scratching my head over a monad instance. I wonder whether there is a deeper theory behind this. Suppose you have a functor T and you happen to find a special type r such that there is a natural embedding into the continuation monad Cont r. More precisely, if there are natural transformations trans :: forall x. T x -> Cont r x trans' :: forall x. Cont r x -> T x with trans' . trans = id and trans . trans' . return = return trans . trans' . (=<<) (trans . f) = (=<<) (trans . f) then you can define monad operations for T so that trans becomes a monad morphism. Once that T is a monad, one can invoke a theorem from a 1970 paper by Anders Kock and obtain Eilenberg-Moore T-algebra structure on r, and the entire monad structure of T can be recovered from this single T-algebra. Examples of this scheme in the mathematical literature are the Riesz representation theorem, which identifies measures on X with a subset of the space of real functionals (X -> R) -> R. Ultimately, the monad structure of the functor of measures is encoded in the operation that sends a measure on R to its mean. Anders Kock's theorem says: (1) There is a bijecitive correspondence between natural transformations T -> Cont r and functions T r -> r. (2) In particular if T is a monad, (1) restricts to a bijection between monad morphisms and Eilenberg-Moore algebra structures. (Incidentally, this is what underlies the continuation monad transformer: Apply to the structure join :: m (m r) -> m r.) It thus seems that my observation is a kind of converse to part (2), namely if a function T r -> r is an Eilenberg-Moore algebra structure, then T is a monad. The preceding sentence is self-referential though, because the property of being an Eilenberg-Moore algebra depends on monad structure already present. As usual I suspect the answer in one of Edward Kmett's packages, but my Category-Fu is not strong enough to identify the matching concept. Olaf From fte at informatik.uni-kiel.de Fri May 7 07:48:59 2021 From: fte at informatik.uni-kiel.de (Finn Teegen) Date: Fri, 7 May 2021 09:48:59 +0200 Subject: [Haskell-cafe] Repeating type variables in MultiParamTypeClasses instance heads In-Reply-To: References: <64bae47f4397f0e45d9a44390a50fd99@mail.uni-kiel.de> <4e52d9fa-b6d-9df0-4142-186669056c4@henning-thielemann.de> Message-ID: <8b52f95b-fddc-e3ee-bddb-f4a434c80a74@informatik.uni-kiel.de> Even without a method you can trigger the overlapping error. Consider the following program. class C a b c instance C [a] [a] [b] instance C [a] [b] [b] f :: C a b c => a -> b -> c -> Bool f _ _ _ = True g = f [True] [True] [True] The use of 'f' in 'g' produces the following message. Overlapping instances for D [Bool] [Bool] [Bool] arising from a use of ‘f’ Matching instances: instance D [a] [a] [b] instance D [a] [b] [b] • In the expression: f [True] [True] [True] Cheers, Finn On 06/05/2021 23:05, Viktor Dukhovni wrote: > On Thu, May 06, 2021 at 10:51:32PM +0200, Henning Thielemann wrote: > >> {-# LANGUAGE MultiParamTypeClasses #-} >> module FlexibleInstance where >> >> class C a b c where > > This class has an empty interface, it just builds triples of types that > imply a constraint. No matter how many such triples one creates, there > can't be any conflict between them. > >> instance C [a] [a] [b] where >> instance C [a] [b] [b] where > > These don't conflict. > From kyotsuya at iij-ii.co.jp Fri May 7 09:29:37 2021 From: kyotsuya at iij-ii.co.jp (Kenzo Yotsuya) Date: Fri, 7 May 2021 18:29:37 +0900 Subject: [Haskell-cafe] wai-middleware-validation Message-ID: <27C6A253-68B2-4CF9-B51F-F257CE066F76@iij-ii.co.jp> Dear Haskell-Cafe, I've uploaded a new package named wai-middleware-validation to Hackage. This is a WAI middleware to automate the validation of request and response bodies according to the schema defined in OpenAPI. I hope Web API developers using OpenAPI will give it a try. https://hackage.haskell.org/package/wai-middleware-validation https://iij-ii.github.io/wai-middleware-validation/ Thanks, Kenzo Yotsuya From olf at aatal-apotheke.de Fri May 7 15:38:04 2021 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Fri, 07 May 2021 17:38:04 +0200 Subject: [Haskell-cafe] (Online) Utrecht Summer School on Advanced functional programming Message-ID: <704f78efa4bed546231d3f79403c544fb3a0996d.camel@aatal-apotheke.de> > The lectures will cover several more advanced topics regarding > programming with types in Haskell, including topics such as: > > * monads and applicative functors; > * lambda calculus; > * generalized algebraic datatypes; > * datatype generic programming > * type families and type-level programming; Even if the schedule is yet to be finalized, a definitive list of topics covered would be nice. Thanks, Olaf From eborsboom at fpcomplete.com Fri May 7 20:46:48 2021 From: eborsboom at fpcomplete.com (Emanuel Borsboom) Date: Fri, 7 May 2021 20:46:48 +0000 Subject: [Haskell-cafe] ANN: stack-2.7.1 Message-ID: See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.5.1.1:** Behavior changes: * `stack repl` now always warns about GHCi problems with loading multiple packages. It also sets now proper working directory when invoked with one package. See [#5421](https://github.com/commercialhaskell/stack/issues/5421) * `custom-setup` dependencies are now properly initialized for `stack dist`. This makes `explicit-setup-deps` no longer required and that option was removed. See [#4006](https://github.com/commercialhaskell/stack/issues/4006) Other enhancements: * Nix integration now passes `ghcVersion` (in addition to existing `ghc`) to `shell-file` as an identifier that can be looked up in a compiler attribute set. * Nix integration now allows Nix integration if the user is ready in nix-shell. This gets rid of "In Nix shell but reExecL is False" error. * `stack list` is a new command to list package versions in a snapshot. See [#5431](https://github.com/commercialhaskell/stack/pull/5431) * Consider GHC 9.0 a tested compiler and remove warnings. * `custom-preprocessor-extensions` is a new configuration option for allowing stack to be aware of any custom preprocessors you have added to `Setup.hs`. See [#3491](https://github.com/commercialhaskell/stack/issues/3491) * Added `--candidate` flag to `upload` command to upload a package candidate rather than publishing the package. * Error output using `--no-interleaved-output` no longer prepends indentating whitespace. This allows emacs compilation-mode and vim quickfix to locate and track errors. See [#5523](https://github.com/commercialhaskell/stack/pull/5523) Bug fixes: * `stack new` now suppports branches other than `master` as default for GitHub repositories. See [#5422](https://github.com/commercialhaskell/stack/issues/5422) * Ignore all errors from `hi-file-parser`. See [#5445](https://github.com/commercialhaskell/stack/issues/5445) and [#5486](https://github.com/commercialhaskell/stack/issues/5486). * Support basic auth in package-indices. See [#5509](https://github.com/commercialhaskell/stack/issues/5509). * Add support for parsing `.hi`. files from GHC 8.10 and 9.0. See [hi-file-parser#2](https://github.com/commercialhaskell/hi-file-parser/pull/2). **Thanks to all our contributors for this release:** * Aaron Allen * Alexey Kuleshevich * Andreas Källberg * Domen Kožar * Emanuel Borsboom * Felix Yan * Jens Petersen * Kirill Zaborsky * Marcin Tolysz * Matt Audesse * Matthew Wraith * Michael Snoyman * Mike Pilgrem * Simon Michael From bruno.bernardo at tutanota.com Mon May 10 11:26:21 2021 From: bruno.bernardo at tutanota.com (Bruno Bernardo) Date: Mon, 10 May 2021 13:26:21 +0200 (CEST) Subject: [Haskell-cafe] FMBC 2021 - Final Call for Papers (Deadline extension) Message-ID: [ Please distribute, apologies for multiple postings. ] ======================================================================== 3rd International Workshop on Formal Methods for Blockchains (FMBC) - Final Call https://fmbc.gitlab.io/2021 July 18 or 19 (TBA), 2021, *online* Co-located with the 33nd International Conference on Computer-Aided Verification (CAV 2021) http://i-cav.org/2021/ ------------------------------------------------------------- IMPORTANT DATES -------------------------------- Abstract submission: May 16, 2021 (extended) Paper submission: May 23, 2021 (extended) Notification: June 30, 2021 (extended) Camera-ready: July 14, 2021 (extended) Workshop: July 18 or 19 (TBA), 2021 Deadlines are Anywhere on Earth: https://en.wikipedia.org/wiki/Anywhere_on_Earth -------------------------------- -------------------------------- TOPICS OF INTEREST -------------------------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the Blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the Blockchain. Thus, Smart Contracts can facilitate the economic activity of Blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of Blockchain software. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write Smart Contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for Blockchain technology. Topics include, but are not limited to: * Formal models of Blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for Blockchain-specific cryptographic primitives or protocols * Design and implementation of Smart Contract languages * Verification of Smart Contracts -------------------------------- -------------------------------- SUBMISSION -------------------------------- Submit original manuscripts (not published or considered elsewhere) with a page limit of 12 pages for full papers and 6 pages for short papers (excluding bibliography and short appendix of up to 5 additional pages). Alternatively you may also submit an extended abstract of up to 3 pages (including bibliography) summarizing your ongoing work in the area of formal methods and blockchain. Authors of selected extended-abstracts are invited to give a short lightning talk. Submission link: https://easychair.org/conferences/?conf=fmbc2021 Authors are encouraged to use LaTeX and prepare their submissions according to the instructions and styling guides for OASIcs provided by Dagstuhl. Instructions for authors: https://submission.dagstuhl.de/documentation/authors#oasics At least one author of an accepted paper is expected to present the paper at the workshop as a registered participant. -------------------------------- -------------------------------- PROCEEDINGS -------------------------------- All submissions will be peer-reviewed by at least three members of the program committee for quality and relevance. Accepted regular papers (full and short papers) will be included in the workshop proceedings, published as a volume of the OpenAccess Series in Informatics (OASIcs) by Dagstuhl. -------------------------------- -------------------------------- INVITED SPEAKER -------------------------------- David Dill, Lead Researcher, Blockchain, Novi/Facebook, USA https://research.fb.com/people/dill-david/ -------------------------------- -------------------------------- PROGRAM COMMITTEE -------------------------------- PC CO-CHAIRS * Bruno Bernardo (Nomadic Labs, France) (bruno at nomadic-labs.com) * Diego Marmsoler (University of Exeter, UK) (D.Marmsoler at exeter.ac.uk) PC MEMBERS * Wolfgang Ahrendt (Chalmers University of Technology, Sweden) * Lacramioara Astefanoei (Nomadic Labs, France) * Massimo Bartoletti (University of Cagliari, Italy) * Joachim Breitner (Dfinity Foundation, Germany) * Achim Brucker (University of Exeter, UK) * Zaynah Dargaye (Nomadic Labs, France) * Jérémie Decouchant (TU Delft, Netherlands) * Dana Drachsler Cohen (Technion, Israel) * Ansgar Fehnker (University of Twente, Netherlands) * Maurice Herlihy (Brown University, USA) * Lars Hupel (INNOQ, Germany) * Florian Kammueller (Middlesex University London, UK) * Igor Konnov (Informal Systems, Austria) * Andreas Lochbihler (Digital Asset, Switzerland) * Simão Melo de Sousa (Universidade da Beira Interior, Portugal) * Karl Palmskog (KTH, Sweden) * Maria Potop-Butucaru (Sorbonne Université, France) * Andreas Rossberg (Dfinity Foundation, Germany) * Albert Rubio (Complutense University of Madrid, Spain) * César Sanchez (Imdea, Spain) * Clara Schneidewind (TU Wien, Austria) * Ilya Sergey (Yale-NUS College/NUS, Singapore) * Mark Staples (CSIRO Data61, Australia) * Meng Sun (Peking University, China) * Simon Thompson (University of Kent, UK) * Josef Widder (Informal Systems, Austria) From winterland1989 at gmail.com Tue May 11 09:42:59 2021 From: winterland1989 at gmail.com (Dong Han) Date: Tue, 11 May 2021 17:42:59 +0800 Subject: [Haskell-cafe] [Ann] A new Haskell crypto lib: Z-Botan 0.1.1 Message-ID: Dear Haskellers: After hundreds of days working. I'm happy to announce that the very first version of [Z-Botan](http://hackage.haskell.org/package/Z-Botan) is published, It's a new crypto lib built around the versatile [botan]( http://botan.randombit.net/) C++ crypto lib. Currently, all crypto stuff exported by Botan FFI is implemented, i.e.: * Random number generators. * Block Cipher and symmetric cipher. * Hash. * MAC. * Key derivation functions. * Password hash. * Constant time multiple precision integers. * Public key creation, import and export. * Public key encryption/decryption * Diffie-Hellman key exchange. * Signature generation & signature verification. * X.509 certificates & X.509 certificate revocation lists. * One time password. * AES Key Wrapping * Format Preserving Encryption. We will continue to polish this work, e.g. build TLS upon it. If you have any crypto usage, please give it a try. as usual, we wish you happy hacking! Cheers~ Dong 2021.05.11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue May 11 22:01:45 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 11 May 2021 18:01:45 -0400 Subject: [Haskell-cafe] [Ann] A new Haskell crypto lib: Z-Botan 0.1.1 In-Reply-To: References: Message-ID: Very cool! Thx for sharing! On Tue, May 11, 2021 at 5:46 AM Dong Han wrote: > Dear Haskellers: > > After hundreds of days working. I'm happy to announce that the very first > version of [Z-Botan](http://hackage.haskell.org/package/Z-Botan) is > published, It's a new crypto lib built around the versatile [botan]( > http://botan.randombit.net/) C++ crypto lib. Currently, all crypto stuff > exported by Botan FFI is implemented, i.e.: > > * Random number generators. > * Block Cipher and symmetric cipher. > * Hash. > * MAC. > * Key derivation functions. > * Password hash. > * Constant time multiple precision integers. > * Public key creation, import and export. > * Public key encryption/decryption > * Diffie-Hellman key exchange. > * Signature generation & signature verification. > * X.509 certificates & X.509 certificate revocation lists. > * One time password. > * AES Key Wrapping > * Format Preserving Encryption. > > We will continue to polish this work, e.g. build TLS upon it. If you > have any crypto usage, please give it a try. as usual, we wish you happy > hacking! > > Cheers~ > Dong > 2021.05.11 > > > _______________________________________________ > 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 J.Hage at uu.nl Wed May 12 07:24:19 2021 From: J.Hage at uu.nl (Hage, J. (Jurriaan)) Date: Wed, 12 May 2021 07:24:19 +0000 Subject: [Haskell-cafe] Second call for the *regular* round of Papers for the Haskell Symposium 2021 Message-ID: <93B60ADC-4BB0-44A4-96DB-7B0CABF3C860@uu.nl> Dear all, First, some * BREAKING NEWS *: Jean-Philippe Bernardy has accepted the invitation to speak at the symposium. He will be talking about Linear Haskell. This is the second call for the *regular* round of papers for the upcoming Haskell Symposium. Please forward to anyone that you believe might be interested. The deadline for this round is May 21. Apologies for receiving multiple copies of this announcement. Best regards, Jurriaan Hage Chair ================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2021 ** virtual ** Thu 26 -- Fri 27 August, 2021 http://www.haskell.org/haskell-symposium/2021/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2021 will be co-located with the 2021 International Conference on Functional Programming (ICFP). Due to COVID-19 it will take place **virtually** this year. Like last year, we will be using a lightweight double-blind reviewing process. See further information below. Different from last year is that we offer a new submission category: the tutorial. Details can be found below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. A new submission category for this year's Haskell Symposium is the tutorial. Like with the experience report and the functional pearl, the key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2021 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Regular track and demos: Submission deadline: 21 May 2021 (Fri) Notification: 23 June 2021 (Wed) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/), and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism). Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell21.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html). Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available). Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Edwin Brady University of St Andrews Koen Claessen Chalmers University of Technology Dominique Devriese Vrije Universiteit Brussel Andy Gill University of Kansas Jurriaan Hage (chair) Universiteit Utrecht Zhenjiang Hu Peking University Ranjit Jhala University of California Patricia Johann Appalachian State University Yukiyoshi Kameyama University of Tsukuba George Karachalias Tweag Ralf Laemmel University of Koblenz-Landau Daan Leijen Microsoft Research Ben Lippmeier Ghost Locomotion Neil Mitchell Facebook Alberto Pardo Universidad de la Republica, Uruguay Matt Roberts Macquarie University Janis Voigtlaender University of Duisburg-Essen Nicolas Wu Imperial College London If you have questions, please contact the chair at: j.hage at uu.nl ================================================================================ From ryan.gl.scott at gmail.com Thu May 13 15:05:55 2021 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Thu, 13 May 2021 11:05:55 -0400 Subject: [Haskell-cafe] scotty: call for maintainers Message-ID: Hello, The scotty web framework [1] is looking for additional maintainers to help keep it a thriving project. The core functionality of scotty has been stable for a while, but there are a number of open issues [2] which concern the design of the framework. Although I have been keeping scotty compiling for a while (as I have code which transitively depends on it), I am not a web developer by trade, and as a result, I don't feel like I have the keenest sense for broad design changes. If you feel like you would be able to step up and fill this role, please let me know! Related issue: https://github.com/scotty-web/scotty/issues/274 [1] https://github.com/scotty-web/scotty [2] https://github.com/scotty-web/scotty/issues -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at richarde.dev Thu May 13 15:57:13 2021 From: rae at richarde.dev (Richard Eisenberg) Date: Thu, 13 May 2021 15:57:13 +0000 Subject: [Haskell-cafe] a repo to improve error messages Message-ID: <010f017966723cb1-e9c43c24-b87e-498b-aac5-1bfcdaf2f585-000000@us-east-2.amazonses.com> Hi all, Many folks here may be interested in https://discourse.haskell.org/t/proposal-an-issue-tracker-for-better-error-messages/2498 , a proposal I've just written up for a repo that could be used to improve our error messages. As someone who only occasionally reads Discourse myself, I thought cross-posting here would be helpful. It's probably best to keep the discussion concentrated on Discourse, though. Thanks! Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.gl.scott at gmail.com Fri May 14 11:22:50 2021 From: ryan.gl.scott at gmail.com (Ryan Scott) Date: Fri, 14 May 2021 07:22:50 -0400 Subject: [Haskell-cafe] scotty: call for maintainers Message-ID: Hello, I'm pleased to welcome Daniel Brice and Fumiaki Kinoshita as new scotty maintainers [1]. Thanks for stepping up to take up maintenance of this library! Ryan [1] https://github.com/scotty-web/scotty/issues/274#issuecomment-841181989 -------------- next part -------------- An HTML attachment was scrubbed... URL: From coot at coot.me Fri May 14 19:54:46 2021 From: coot at coot.me (coot at coot.me) Date: Fri, 14 May 2021 19:54:46 +0000 Subject: [Haskell-cafe] foldMap for semigroups Message-ID: Base has: * foldMap :: (Foldable t, Monoid a) => (x -> a) -> t x -> a * foldr1 :: (Foldable t) => (a -> a -> a) -> t x -> a Is there a good reason why it does not have: ``` foldMap1 :: (Foldable t, Semigroup a, Functor f) => (a -> a) -> t x -> a foldMap1 = fodlr1 (<>) . fmap f ``` Like `foldr1` it is partial for any foldable that can be empty. Best regards, Marcin Szamotulski Sent with ProtonMail Secure Email. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From oleg.grenrus at iki.fi Fri May 14 20:13:10 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 14 May 2021 23:13:10 +0300 Subject: [Haskell-cafe] foldMap for semigroups In-Reply-To: References: Message-ID: Is there a good reason why it does not have: A good question. See - (2017) https://gitlab.haskell.org/ghc/ghc/-/issues/13573 - (2017) https://www.reddit.com/r/haskell/comments/6d0vgt/could_we_have_foldable1_and_traversable1_in_base/ - (2019) https://mail.haskell.org/pipermail/libraries/2019-November/030059.html - (2020) https://mail.haskell.org/pipermail/libraries/2020-December/031003.html - (2021) https://twitter.com/kmett/status/1363774888603914242 For recent bits and bobs of the possible answers. - Oleg On 14.5.2021 22.54, coot at coot.me wrote: > Base has: > * foldMap :: (Foldable t, Monoid a) => (x -> a) -> t x -> a > * foldr1 :: (Foldable t) => (a -> a -> a) -> t x -> a > Is there a good reason why it does not have: > ``` > foldMap1 :: (Foldable t, Semigroup a, Functor f) => (a -> a) -> t x -> a > foldMap1 = fodlr1 (<>) . fmap f > ``` > Like `foldr1` it is partial for any foldable that can be empty. > > Best regards, > Marcin Szamotulski > > Sent with ProtonMail Secure Email. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Fri May 14 21:11:47 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Fri, 14 May 2021 23:11:47 +0200 (CEST) Subject: [Haskell-cafe] foldMap for semigroups In-Reply-To: References: Message-ID: <3e159ffc-c8c2-d45c-70f3-2237ac819f9@henning-thielemann.de> On Fri, 14 May 2021, coot at coot.me wrote: > Base has: > * foldMap :: (Foldable t, Monoid a) => (x -> a) -> t x -> a > * foldr1 :: (Foldable t) => (a -> a -> a) -> t x -> a > Is there a good reason why it does not have: > ``` > foldMap1 :: (Foldable t, Semigroup a, Functor f) => (a -> a) -> t x -> a > foldMap1 = fodlr1 (<>) . fmap f > ``` > Like `foldr1` it is partial for any foldable that can be empty. I do not think we should extend support for partial functions. foldMap1 should be restricted to non-empty Foldable (i.e. Foldable1). From frederic.bour at lakaban.net Sat May 15 00:16:25 2021 From: frederic.bour at lakaban.net (=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Bour?=) Date: Sat, 15 May 2021 09:16:25 +0900 Subject: [Haskell-cafe] OCaml Users and Developers Workshop 2021: call for presentations Message-ID: It is my pleasure to invite submissions to the OCaml Users and Developers Workshop 2021, which is again co-located with ICFP and will be held virtually this year. The OCaml Users and Developers Workshop brings together industrial users of OCaml with academics and hackers who are working on extending the language, type system, and tools. Previous editions have been co-located with ICFP 2012 in Copenhagen, ICFP 2013 in Boston, ICFP 2014 in Gothenburg, ICFP 2015 in Vancouver, ICFP 2016 in Nara, ICFP 2017 in Oxford, ICFP 2018 in St Louis, ICFP 2019 in Berlin, and was virtual for ICFP 2020, following the OCaml Meetings in Paris in 2010 and 2011. Please note that the deadline for abstract submission is set on May 20, a week from now. Don't wait to start preparing your submission :-). ## Important Links - workshop site: https://icfp21.sigplan.org/home/ocaml-2021 - submission site: https://ocaml2021.hotcrp.com ## Important dates * Thursday 20th May (any time zone): Abstract submission deadline * Friday 18th July: Author notification * Friday 27th August: OCaml Workshop ## Scope Presentations and discussions focus on the OCaml programming language and its community. We aim to solicit talks on all aspects related to improving the use or development of the language and its programming environment, including, for example (but not limited to): * compiler developments, new backends, runtime and architectures * practical type system improvements, such as GADTs, first-class modules, generic programming, or dependent types * new library or application releases, and their design rationales * tools and infrastructure services, and their enhancements * prominent industrial or experimental uses of OCaml, or deployments in unusual situations. ## Presentations Presentations will be held in the online format. Each presentation comprise a prerecorded presentation and an interactive live Q&A session after the talk. Each talk will be re-translated three times in different time zones. Session chairs and volunteers will assist the authors in preparing and casting the presentation. Each presentation will be made available through the ocaml.org website. ## Submission To submit a presentation, please register a description of the talk (about 2 pages long) at https://ocaml2021.hotcrp.com/ providing a clear statement of what will be provided by the presentation: the problems that are addressed, the solutions or methods that are proposed. LaTeX-produced PDFs are a common and welcome submission format. For accessibility purposes, we ask PDF submitters to also provide the sources of their submission in a textual format, such as .tex sources. Reviewers may read either the submitted PDF or the text version. ## Camera ready presentations A pre-recorded versions of accepted presentation shall be provided before August, 13th. Volunteers will provide technical assistance to authors as well as provide necessary feedback and ensure that all videos match our quality standards. ## ML family workshop The ML family workshop, held on the previous day, deals with general issues of the ML-style programming and type systems, focuses on more research-oriented work that is less specific to a language in particular. There is an overlap between the two workshops, and we have occasionally transferred presentations from one to the other in the past. Authors who feel their submission fits both workshops are encouraged to mention it at submission time and/or contact the Program Chairs. ## Program Commitee Frédéric Bour, Tarides, France Cristina Rosu, Janestreet, UK Hakjoo Oh, Korea University, Korea Hugo Heuzard, France Jeffrey A. Scofield, Formalsim, USA Jonathan Protzenko, MSR, USA Joris Giovanangeli, Ahrefs, Singapore Jun Furuse, Dailambda, Japan Kihong Heo, KAIST, Korea Kate Deplaix, OCaml Labs, UK Mehdi Bouaziz, Nomadic Labs, France Simon Castellan, INRIA, France Ryohei Tokuda, Idein, Japan Vaivaswatha Nagaraj, Zilliqa, India Youyou Cong, Tokyo Institute of Technology, Japan -------------- next part -------------- An HTML attachment was scrubbed... URL: From coot at coot.me Sat May 15 07:38:02 2021 From: coot at coot.me (coot at coot.me) Date: Sat, 15 May 2021 07:38:02 +0000 Subject: [Haskell-cafe] foldMap for semigroups In-Reply-To: <3e159ffc-c8c2-d45c-70f3-2237ac819f9@henning-thielemann.de> References: <3e159ffc-c8c2-d45c-70f3-2237ac819f9@henning-thielemann.de> Message-ID: Thanks Oleg, I would love to see `Foldable1` to be in base. This seems to be a topic that comes back again and again, so I am not sure why there's a lack of decision so far. There is a whole ecosystem of non empty data types: `nonempty-containers`, `nonempty-vector`, `nonempty-dlist`, `nonempty-lift` and the most funny one `Identity` from `base` - the nonempty `Maybe` ;). For all of them `Foldable1` instance are non partial. Isn't this a good enough argument to move `Foldable1` to base? Maybe this could go through HF to help facilitate the decision? My recent discovery why I'd like to have it is a last-to-finish synchronisation which is a semigroup: https://github.com/input-output-hk/ouroboros-network/blob/coot/last-to-finish-stm/ouroboros-network-framework/src/Data/Monoid/Synchronisation.hs#L85 There's also last-to-finish based on `Ap`. The `LastToFinish m a` does not require Monoid instance on `a`, unlike `Ap a`, so it is easier to use, but it requires `foldMap1` which is not in `base`. Cheers, Marcin Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, May 14th, 2021 at 23:11, Henning Thielemann wrote: > On Fri, 14 May 2021, coot at coot.me wrote: > > > Base has: > > > > - foldMap :: (Foldable t, Monoid a) => (x -> a) -> t x -> a > > - foldr1 :: (Foldable t) => (a -> a -> a) -> t x -> a > > > > Is there a good reason why it does not have: > > > > foldMap1 :: (Foldable t, Semigroup a, Functor f) => (a -> a) -> t x -> a > > foldMap1 = fodlr1 (<>) . fmap f > > > > > > Like `foldr1` it is partial for any foldable that can be empty. > > I do not think we should extend support for partial functions. > > foldMap1 should be restricted to non-empty Foldable (i.e. Foldable1). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 509 bytes Desc: OpenPGP digital signature URL: From xnningxie at gmail.com Sun May 16 22:43:06 2021 From: xnningxie at gmail.com (Ningning Xie) Date: Sun, 16 May 2021 18:43:06 -0400 Subject: [Haskell-cafe] Second Call for Talks: Haskell Implementors' Workshop @ ICFP'21 Message-ID: Call for 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: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 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. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. 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 Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins 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. 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. 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 clintonmead at gmail.com Mon May 17 01:50:14 2021 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 17 May 2021 11:50:14 +1000 Subject: [Haskell-cafe] Compile time checking of space leaks Message-ID: I've asked a question on stackoverflow, which is basically a typical question about folds and space leaks due to laziness, in this case complicated by a Maybe and foldM: https://stackoverflow.com/questions/67559724/constant-space-short-circuiting-foldm-over-maybe That's getting answered, but when I saw the answers, I noticed people are using a fairly mechanical process, basically going through how the code would be evaluated step by step, to determine whether there's a space leak or not. And that tends to be the case for most of these questions. It's complicated enough that it's hard to keep track of in my head, but I thought to myself, wouldn't a computer be able to check this much more quickly and reliably? There doesn't seem to be much human intuition required here, just a lot of pen and paper work to try to determine whether you've got an unevaluated thunk hanging around at the end of an iteration. I understand doing this analysis for the whole program may be impossible, but we can certainly do it for parts, because flesh and blood human beings can do it for stackoverflow answers. Is there anything I can get that helps me identify space leaks like this at compile time (that is, pre-runtime)? Either from GHC or from another tool? Or do we just have to rely on squishy humans to do this as compile time and our only automated tools have to be delayed til runtime? Thanks, Clinton -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Mon May 17 06:38:11 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Mon, 17 May 2021 08:38:11 +0200 (CEST) Subject: [Haskell-cafe] Compile time checking of space leaks In-Reply-To: References: Message-ID: <2089dfba-606f-7c6-2316-15a67ac6f95@henning-thielemann.de> On Mon, 17 May 2021, Clinton Mead wrote: > Is there anything I can get that helps me identify space leaks like this > at compile time (that is, pre-runtime)? Either from GHC or from another > tool? Or do we just have to rely on squishy humans to do this as compile > time and our only automated tools have to be delayed til runtime?  There are at least tools to visualize GHC's internal data structures at runtime: ghc-heap-view/ghc-vis. https://github.com/nomeata/haskell-bytes-bobkonf2021 From J.Hage at uu.nl Tue May 18 05:37:43 2021 From: J.Hage at uu.nl (Hage, J. (Jurriaan)) Date: Tue, 18 May 2021 05:37:43 +0000 Subject: [Haskell-cafe] Final call for the *regular* round of Papers for the Haskell Symposium 2021 Message-ID: <062000EF-333A-4CB2-9A61-7B6C1EDE6A57@uu.nl> Dear all, This is the final call for the *regular* round of papers for the upcoming Haskell Symposium. Please forward to anyone that you believe might be interested. The deadline for this round is May 21. Apologies for receiving multiple copies of this announcement. Best regards, Jurriaan Hage Chair ================================================================================ ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2021 ** virtual ** Thu 26 -- Fri 27 August, 2021 http://www.haskell.org/haskell-symposium/2021/ ================================================================================ The ACM SIGPLAN Haskell Symposium 2021 will be co-located with the 2021 International Conference on Functional Programming (ICFP). Due to COVID-19 it will take place **virtually** this year. Like last year, we will be using a lightweight double-blind reviewing process. See further information below. Different from last year is that we offer a new submission category: the tutorial. Details can be found below. The Haskell Symposium presents original research on Haskell, discusses practical experience and future development of the language, and promotes other forms of declarative programming. Topics of interest include: * Language design, with a focus on possible extensions and modifications of Haskell as well as critical discussions of the status quo; * Theory, such as formal semantics of the present language or future extensions, type systems, effects, metatheory, and foundations for program analysis and transformation; * Implementations, including program analysis and transformation, static and dynamic compilation for sequential, parallel, and distributed architectures, memory management, as well as foreign function and component interfaces; * Libraries, that demonstrate new ideas or techniques for functional programming in Haskell; * Tools, such as profilers, tracers, debuggers, preprocessors, and testing tools; * Applications, to scientific and symbolic computing, databases, multimedia, telecommunication, the web, and so forth; * Functional Pearls, being elegant and instructive programming examples; * Experience Reports, to document general practice and experience in education, industry, or other contexts; * Tutorials, to document how to use a particular language feature, programming technique, tool or library within the Haskell ecosystem; * System Demonstrations, based on running software rather than novel research results. Regular papers should explain their research contributions in both general and technical terms, identifying what has been accomplished, explaining why it is significant, and relating it to previous work, and to other languages where appropriate. Experience reports and functional pearls need not necessarily report original academic research results. For example, they may instead report reusable programming idioms, elegant ways to approach a problem, or practical experience that will be useful to other users, implementers, or researchers. The key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. It is not enough simply to describe a standard solution to a standard programming problem, or report on experience where you used Haskell in the standard way and achieved the result you were expecting. A new submission category for this year's Haskell Symposium is the tutorial. Like with the experience report and the functional pearl, the key criterion for such a paper is that it makes a contribution from which other Haskellers can benefit. What distinguishes a tutorial is that its focus is on explaining an aspect of the Haskell language and/or ecosystem in a way that is generally useful to a Haskell audience. Tutorials for many such topics can be found online; the distinction here is that by writing it up for formal review it will be vetted by experts and formally published. System demonstrations should summarize the system capabilities that would be demonstrated. The proposals will be judged on whether the ensuing session is likely to be important and interesting to the Haskell community at large, whether on grounds academic or industrial, theoretical or practical, technical, social or artistic. Please contact the program chair with any questions about the relevance of a proposal. If your contribution is not a research paper, please mark the title of your experience report, functional pearl, tutorial or system demonstration as such, by supplying a subtitle (Experience Report, Functional Pearl, Tutorial Paper, System Demonstration). Submission Details ================== Formatting ---------- Submitted papers should be in portable document format (PDF), formatted using the ACM SIGPLAN style guidelines. Authors should use the `acmart` format, with the `sigplan` sub-format for ACM proceedings. For details, see: http://www.sigplan.org/Resources/Author/#acmart-format It is recommended to use the `review` option when submitting a paper; this option enables line numbers for easy reference in reviews. Functional pearls, experience reports, tutorials and demo proposals should be labelled clearly as such. Lightweight Double-blind Reviewing ---------------------------------- Haskell Symposium 2021 will use a lightweight double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. Author names and institutions must be omitted, and 2. References to authors' own related work should be in the third person (e.g., not "We build on our previous work" but rather "We build on the work of "). The purpose of this process is to help the reviewers come to an initial judgment about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. A reviewer will learn the identity of the author(s) of a paper after a review is submitted. Page Limits ----------- The length of submissions should not exceed the following limits: Regular paper: 12 pages Functional pearl: 12 pages Tutorial: 12 pages Experience report: 6 pages Demo proposal: 2 pages There is no requirement that all pages are used. For example, a functional pearl may be much shorter than 12 pages. In all cases, the list of references is not counted against these page limits. Deadlines --------- Regular track and demos: Submission deadline: 21 May 2021 (Fri) Notification: 23 June 2021 (Wed) Deadlines are valid anywhere on Earth. Submission ---------- Submissions must adhere to SIGPLAN's republication policy (http://sigplan.org/Resources/Policies/Republication/), and authors should be aware of ACM's policies on plagiarism (https://www.acm.org/publications/policies/plagiarism). Program Committee members are allowed to submit papers, but their papers will be held to a higher standard. The paper submission deadline and length limitations are firm. There will be no extensions, and papers violating the length limitations will be summarily rejected. Papers should be submitted through HotCRP at: https://haskell21.hotcrp.com/ Improved versions of a paper may be submitted at any point before the submission deadline using the same web interface. Supplementary material: Authors have the option to attach supplementary material to a submission, on the understanding that reviewers may choose not to look at it. This supplementary material should not be submitted as part of the main document; instead, it should be uploaded as a separate PDF document or tarball. Supplementary material should be uploaded at submission time, not by providing a URL in the paper that points to an external repository. Authors can distinguish between anonymized and non-anonymized supplementary material. Anonymized supplementary material will be visible to reviewers immediately; non-anonymized supplementary material will be revealed to reviewers only after they have submitted their review of the paper and learned the identity of the author(s). Resubmitted Papers: authors who submit a revised version of a paper that has previously been rejected by another conference have the option to attach an annotated copy of the reviews of their previous submission(s), explaining how they have addressed these previous reviews in the present submission. If a reviewer identifies him/herself as a reviewer of this previous submission and wishes to see how his/her comments have been addressed, the conference chair will communicate to this reviewer the annotated copy of his/her previous review. Otherwise, no reviewer will read the annotated copies of the previous reviews. Proceedings =========== Accepted papers will be included in the ACM Digital Library. Their authors will be required to choose one of the following options: - Author retains copyright of the work and grants ACM a non-exclusive permission-to-publish license (and, optionally, licenses the work with a Creative Commons license); - Author retains copyright of the work and grants ACM an exclusive permission-to-publish license; - Author transfers copyright of the work to ACM. For more information, please see ACM Copyright Policy (http://www.acm.org/publications/policies/copyright-policy) and ACM Author Rights (http://authors.acm.org/main.html). Accepted proposals for system demonstrations will be posted on the symposium website but not formally published in the proceedings. Publication date: The official publication date of accepted papers is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of the conference. The official publication date affects the deadline for any patent filings related to published work. Artifacts ========= Authors of accepted papers are encouraged to make auxiliary material (artifacts like source code, test data, etc.) available with their paper. They can opt to have these artifacts published alongside their paper in the ACM Digital Library (copyright of artifacts remains with the authors). If an accepted paper's artifacts are made permanently available for retrieval in a publicly accessible archival repository like the ACM Digital Library, that paper qualifies for an Artifacts Available badge (https://www.acm.org/publications/policies/artifact-review-badging#available). Applications for such a badge can be made after paper acceptance and will be reviewed by the PC chair. Program Committee ================= Edwin Brady University of St Andrews Koen Claessen Chalmers University of Technology Dominique Devriese Vrije Universiteit Brussel Andy Gill University of Kansas Jurriaan Hage (chair) Universiteit Utrecht Zhenjiang Hu Peking University Ranjit Jhala University of California Patricia Johann Appalachian State University Yukiyoshi Kameyama University of Tsukuba George Karachalias Tweag Ralf Laemmel University of Koblenz-Landau Daan Leijen Microsoft Research Ben Lippmeier Ghost Locomotion Neil Mitchell Facebook Alberto Pardo Universidad de la Republica, Uruguay Matt Roberts Macquarie University Janis Voigtlaender University of Duisburg-Essen Nicolas Wu Imperial College London If you have questions, please contact the chair at: j.hage at uu.nl ================================================================================ From 4rgento at gmail.com Tue May 18 15:24:00 2021 From: 4rgento at gmail.com (Aner Lucero) Date: Tue, 18 May 2021 12:24:00 -0300 Subject: [Haskell-cafe] GSoC 2021, Pandoc Figures accepted proposal and introduction Message-ID: Hello, My name is Aner[0] and I'm happy to announce that my proposal for this year's pandoc project idea has been accepted. I've uploaded the current version of the proposal here [1] for those interested. Although we might make some changes. I hope I can meet the project's objectives with your help and I'll post updates as the project moves forwards. Best regards Aner [0] https://en.wiktionary.org/wiki/%E1%BC%80%CE%BD%CE%AE%CF%81 [1] https://github.com/argent0/gsoc-2021-proposal -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabricio.olivetti at gmail.com Wed May 19 14:50:22 2021 From: fabricio.olivetti at gmail.com (=?UTF-8?Q?Fabr=C3=ADcio_Olivetti_de_Fran=C3=A7a?=) Date: Wed, 19 May 2021 11:50:22 -0300 Subject: [Haskell-cafe] Default implementation of Floating (**) Message-ID: Hi, I was using Numeric.Interval in my code and found an issue with the (**) operator, if the interval contains negative values, it will return a wrong result (as reported in this open issue https://github.com/ekmett/intervals/issues/50). Investigating the source of this problem, I found that it uses the default implementation of (**) from base defined as x ** y = exp (log x * y). So I was wondering, is there any reason to have this (potentially dangerous) default implementation on base? Best, Fabricio Olivetti de França From lemming at henning-thielemann.de Wed May 19 14:58:38 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 19 May 2021 16:58:38 +0200 (CEST) Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: References: Message-ID: On Wed, 19 May 2021, Fabrício Olivetti de França wrote: > I was using Numeric.Interval in my code and found an issue with the > (**) operator, if the interval contains negative values, it will > return a wrong result (as reported in this open issue > https://github.com/ekmett/intervals/issues/50). If you need negative bases you must use (^^) instead of (**). > Investigating the source of this problem, I found that it uses the > default implementation of (**) from base defined as x ** y = exp (log > x * y). This default implementation is correct. Power (**) is only defined for positive reals like in mathematics. The example in the GitHub issue will not work if your interval is slightly larger than just the point 2. Think of the interval x=[-2.1,-1.9]. What should x**x be? In contrast to that x^^(-2) would be fine. From ietf-dane at dukhovni.org Wed May 19 15:13:30 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 19 May 2021 11:13:30 -0400 Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: References: Message-ID: On Wed, May 19, 2021 at 11:50:22AM -0300, Fabrício Olivetti de França wrote: > Investigating the source of this problem, I found that it uses the > default implementation of (**) from base defined as x ** y = exp (log > x * y). The type of (**) is: Floating a => a -> a -> a with the base and exponent having the same type. The only practical way to define pow(x, y) for a floating point y, is via the exp() and log() functions. > So I was wondering, is there any reason to have this (potentially > dangerous) default implementation on base? The behaviour for negative inputs seems to be correct: λ> log(-2) NaN λ> exp(log(-2)) NaN λ> exp(log(-2) * (-2)) NaN λ> log(0) -Infinity were you expecting these to check for non-positive inputs and to throw a floating point exception? When I compile and run: #include #include #include int main(int argc, char *argv[]) { char *arg = argv[1] ? argv[1] : "1.0"; double d = atof(arg); printf("log %s = %f\n", argv[1] ? arg, log(d)); return 0; } I get: $ ./log -2 log -2 = nan $ ./log 0 log 0 = -inf so it rather looks like GHC's `log` returns whatever the underlying floating point library returns... -- Viktor. From lemming at henning-thielemann.de Wed May 19 15:24:55 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 19 May 2021 17:24:55 +0200 (CEST) Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: References: Message-ID: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> On Wed, 19 May 2021, Viktor Dukhovni wrote: > On Wed, May 19, 2021 at 11:50:22AM -0300, Fabrício Olivetti de França wrote: > >> So I was wondering, is there any reason to have this (potentially >> dangerous) default implementation on base? > > The behaviour for negative inputs seems to be correct: > > λ> log(-2) > NaN > λ> exp(log(-2)) > NaN > λ> exp(log(-2) * (-2)) > NaN > λ> log(0) > -Infinity > > were you expecting these to check for non-positive inputs and to throw a > floating point exception? I guess he expects (-2)**(-2) = 1/4. But defined this way, (**) would be rather discontinuous. From fabricio.olivetti at gmail.com Wed May 19 15:32:55 2021 From: fabricio.olivetti at gmail.com (=?UTF-8?Q?Fabr=C3=ADcio_Olivetti_de_Fran=C3=A7a?=) Date: Wed, 19 May 2021 12:32:55 -0300 Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> References: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> Message-ID: nevermind, I was thinking of integer exponents. I should be using (^^) instead. Thank you all. Best, Fabricio Olivetti de França On Wed, May 19, 2021 at 12:29 PM Henning Thielemann wrote: > > > On Wed, 19 May 2021, Viktor Dukhovni wrote: > > > On Wed, May 19, 2021 at 11:50:22AM -0300, Fabrício Olivetti de França wrote: > > > >> So I was wondering, is there any reason to have this (potentially > >> dangerous) default implementation on base? > > > > The behaviour for negative inputs seems to be correct: > > > > λ> log(-2) > > NaN > > λ> exp(log(-2)) > > NaN > > λ> exp(log(-2) * (-2)) > > NaN > > λ> log(0) > > -Infinity > > > > were you expecting these to check for non-positive inputs and to throw a > > floating point exception? > > > I guess he expects (-2)**(-2) = 1/4. > > But defined this way, (**) would be rather discontinuous._______________________________________________ > 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 fabricio.olivetti at gmail.com Wed May 19 17:08:06 2021 From: fabricio.olivetti at gmail.com (=?UTF-8?Q?Fabr=C3=ADcio_Olivetti_de_Fran=C3=A7a?=) Date: Wed, 19 May 2021 14:08:06 -0300 Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> References: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> Message-ID: > > I guess he expects (-2)**(-2) = 1/4. > > But defined this way, (**) would be rather discontinuous indeed, that's what I was expecting. For Float and Double (-2)**(-2) = 1/4, but for the interval arithmetic library that uses the default implementation, it doesn't. From francesquini at gmail.com Wed May 19 17:19:22 2021 From: francesquini at gmail.com (Emilio Francesquini) Date: Wed, 19 May 2021 14:19:22 -0300 Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> References: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> Message-ID: The issue here, I guess, is that this behavior is inconsistent. While the default implementation for (**) would produce NaNs and such, the implementation for Float and Double overrides this behavior: > (-3 :: Float) ** (-5) -4.115226e-3 > (-3 :: Double) ** (-5) -4.11522633744856e-3 Which is in accordance to what other languages such as C and Python do (and also to what I would expect): C float b = -3.0; float e = -5.0; printf("%f\n", powf(b, e)); -0.004115 python >>> -3.0 ** -5.0 -0.00411522633744856 The Haskell Report is not clear (or at least I was not able to find a clearer explanation) about this: 6.4.3 Exponentiation and Logarithms The one-argument exponential function exp and the logarithm function log act on floating-point numbers and use base e. logBase a x returns the logarithm of x in base a. sqrt returns the principal square root of a floating-point number. There are three two-argument exponentiation operations: (^) raises any number to a nonnegative integer power, (^^) raises a fractional number to any integer power, and (⋆⋆)takes two floating-point arguments. The value of x^0 or x^^0 is 1 for any x, including zero; 0⋆⋆y is 1 if y is 1, and 0 otherwise. Regards, Emilio On Wed, May 19, 2021 at 12:29 PM Henning Thielemann < lemming at henning-thielemann.de> wrote: > > On Wed, 19 May 2021, Viktor Dukhovni wrote: > > > On Wed, May 19, 2021 at 11:50:22AM -0300, Fabrício Olivetti de França > wrote: > > > >> So I was wondering, is there any reason to have this (potentially > >> dangerous) default implementation on base? > > > > The behaviour for negative inputs seems to be correct: > > > > λ> log(-2) > > NaN > > λ> exp(log(-2)) > > NaN > > λ> exp(log(-2) * (-2)) > > NaN > > λ> log(0) > > -Infinity > > > > were you expecting these to check for non-positive inputs and to throw a > > floating point exception? > > > I guess he expects (-2)**(-2) = 1/4. > > But defined this way, (**) would be rather > discontinuous._______________________________________________ > 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 andrei.h.popescu at gmail.com Wed May 19 19:31:36 2021 From: andrei.h.popescu at gmail.com (Andrei Popescu) Date: Wed, 19 May 2021 20:31:36 +0100 Subject: [Haskell-cafe] Position of Lecturer or Senior Lecturer in Cybersecurity at University of Sheffield Message-ID: Greetings, The Department of Computer Science at University of Sheffield has an open position of Lecturer or Senior Lecturer in Cybersecurity. Details can be found here: https://www.jobs.ac.uk/job/CFN168/lecturer-senior-lecturer-in-cybersecurity Note that "formalisation and proof of system security properties" is listed as a topic of interest. Women are particularly encouraged to apply. All applicants will be given equal consideration. Best wishes, Andrei From ietf-dane at dukhovni.org Wed May 19 19:39:13 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 19 May 2021 15:39:13 -0400 Subject: [Haskell-cafe] Default implementation of Floating (**) In-Reply-To: References: <77167b72-9b71-cbcf-2047-3a72b4a2bce2@henning-thielemann.de> Message-ID: On Wed, May 19, 2021 at 02:08:06PM -0300, Fabrício Olivetti de França wrote: > > I guess he expects (-2)**(-2) = 1/4. > > > > But defined this way, (**) would be rather discontinuous > > Indeed, that's what I was expecting. For Float and Double (-2)**(-2) = > 1/4, but for the interval arithmetic library that uses the default > implementation, it doesn't. This shows the difference between the math library's pow(x, y) and exp(log(x)*y) Indeed pow(x, y) appears to attempt to detect integer-valued floating point exponents and take the interger-exponent code path in that case. -- Viktor. From johannes.waldmann at htwk-leipzig.de Wed May 19 20:28:06 2021 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Wed, 19 May 2021 22:28:06 +0200 Subject: [Haskell-cafe] faster faster faster but not uglier (how to make nice code AND nice core)? Message-ID: Dear Cafe, * how to un-uglify the following program? * and is it even ugly enough? The following is some artificial example but I think it illustrates some general questions - for which I don't have answers. Do you? I wanted a really fast implementation of a vector addition system where the "vector" contains small numbers only. and I want it packed into a machine word (and finally put these into Data.IntSet). I can write this in low-level Haskell (I did), and I could even use some low-level language (I also did) but I was hoping that I don't need to. https://gitlab.imn.htwk-leipzig.de/waldmann/tf/-/blob/master/TF4.hs#L108 * this is too low-level: This is for vectors of one fixed size - but I want the code to be more generic, and have the compiler do the specialization/unrolling. * and not low-level enough: How do I tell GHC to pack (coerce?) `data Pos` into `Word64`? (It's not https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#unpack-pragma ?) And would it help? Or is it even needed? If I have the data spread over several words, it could still be fine - as long as it's kept in registers? How can I then check that "it's fine"? Yes I know, just look at the core. (That seems to be the ultima ratio of https://ghc.gitlab.haskell.org/ghc/doc/users_guide/hints.html#faster-producing-a-program-that-runs-quicker) But is there/could there be some higher-level mechanism? Perhaps a (type?) annotation that guarantees or checks that core (locally) looks "good"? (does not allocate, ...) NB: For the concrete application (evaluation of positions in some game): 1. graph size is exponential, so a linear speed-up won't really help. 2. brute-force gameplay should be replaced by some symbolic evaluation and simplification. That is in fact my goal. But - as long as we don't have this, the program may be useful for generating conjectures. - J. From lemming at henning-thielemann.de Wed May 19 21:12:55 2021 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 19 May 2021 23:12:55 +0200 (CEST) Subject: [Haskell-cafe] faster faster faster but not uglier (how to make nice code AND nice core)? In-Reply-To: References: Message-ID: On Wed, 19 May 2021, Johannes Waldmann wrote: > I wanted a really fast implementation of a vector addition system > where the "vector" contains small numbers only. With integer elements? > and I want it packed into a machine word > (and finally put these into Data.IntSet). Why not using Integer? With a bit of bit tricks you can implement a vector add via Integer addition. https://en.wikipedia.org/wiki/SWAR E.g. like this vectorAdd x y = maskOddElements (maskOddElements x + maskOddElements y) + maskEvenElements (maskEvenElements x + maskEvenElements y) But I suspect that larger Integers are not hold in registers. Chances are better for a record of Word8's, Word16's ... Maybe if they are put in a compact region: http://hackage.haskell.org/package/ghc-compact Or you use the CPU vector types that GHC provides. http://hackage.haskell.org/package/ghc-prim-0.7.0/docs/GHC-Prim.html#g:35 There seem to be some packages for small vectors: https://hackage.haskell.org/package/compact-word-vectors https://hackage.haskell.org/package/smallarray From jo at durchholz.org Wed May 19 21:43:49 2021 From: jo at durchholz.org (Joachim Durchholz) Date: Wed, 19 May 2021 23:43:49 +0200 Subject: [Haskell-cafe] faster faster faster but not uglier (how to make nice code AND nice core)? In-Reply-To: References: Message-ID: > * and not low-level enough: How do I tell GHC to pack (coerce?) > `data Pos` into `Word64`? (It's not > https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/pragmas.html#unpack-pragma > ?) > > > And would it help? Or is it even needed? > If I have the data spread over several words, > it could still be fine - as long as it's kept in registers? Actually, as long as it is kept in a CPU cache line. Cf. Ulrich Drepper: What every programmer should know about memory, https://www.akkadia.org/drepper/cpumemory.pdf The paper tells me that data locality wrt. cache lines (i.e. keeping data accessed together in a single cache line) can have an order-of-magnitude effect. (It also talks about multithreading, which can have two orders of magnitude. It's not relevant to vector optimization though.) It's quite possible that the speedups from using a CPU's vector operations is mostly because of better cacheline locality since the vector operations enforce data locality - though vector operations probably give you a nice boost on top of that. Does ghc do memory locality analysis? It would need to find out what data items are going to be accessed roughly at the same time, and making sure they're close together in memory. Deforestation and such will help with locality as a nice side effect (because you get rid of list spines and such so the data stretches across less cache lines anyway), but is there any analysis on top of that? Regards, Jo From hjm0901 at gmail.com Thu May 20 01:59:33 2021 From: hjm0901 at gmail.com (Jaemin Hong) Date: Thu, 20 May 2021 10:59:33 +0900 Subject: [Haskell-cafe] ICFP 2021: First Call for Students Volunteers Message-ID: <6BC00738-D8F7-4A26-AC22-892C28269147@gmail.com> Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'21 FIRST CALL FOR STUDENT VOLUNTEERS ========================================= 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. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'21 will take place **virtually** from Sun 22 - Fri 27 August 2021. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2021 student volunteer, you will get more visibility and be able to interact closely with researchers, academics and practitioners from various disciplines and discuss with other students from around the world. While the exact structure of the conference is still being discussed, job assignments for student volunteers will probably include: 1- Assisting with technical sessions, workshops, tutorials, Q&A sessions, social activities, and panels. 2- Helping to get authors' videos prepped and ready for broadcast. 3- Managing channels on a virtual event platform. To be considered as a student volunteer for ICFP, please fill in the following application form. https://forms.gle/cEXE4GfXzm24f6mF6 The permanent link to this form can be found on the official conference website. https://icfp21.sigplan.org/track/icfp-2021-student-volunteers There are two rounds of calls with the following deadlines: * deadline for first round: June 11th, 2021 AoE (notification: June 15th) * deadline for second round: July 16th, 2021 AoE (notification: July 20th) From mlang at blind.guru Thu May 20 21:51:08 2021 From: mlang at blind.guru (Mario Lang) Date: Thu, 20 May 2021 23:51:08 +0200 Subject: [Haskell-cafe] faster faster faster but not uglier (how to make nice code AND nice core)? In-Reply-To: (Henning Thielemann's message of "Wed, 19 May 2021 23:12:55 +0200 (CEST)") References: Message-ID: <87o8d5oz03.fsf@blind.guru> Henning Thielemann writes: > Or you use the CPU vector types that GHC provides. > http://hackage.haskell.org/package/ghc-prim-0.7.0/docs/GHC-Prim.html#g:35 More operations would be nice, in particular, I'd love to get xorWord64X4. -- CYa, ⡍⠁⠗⠊⠕ From jonathan.protzenko at gmail.com Fri May 21 03:19:56 2021 From: jonathan.protzenko at gmail.com (Jonathan Protzenko) Date: Thu, 20 May 2021 20:19:56 -0700 Subject: [Haskell-cafe] ML Family Workshop 2021: final call for short abstracts and presentations Message-ID: <5549e63e-accf-c32c-60ff-06e11ca73151@gmail.com> (tl;dr) The ML family workshop is back, and the deadline is in a week. The workshop does not have proceedings, making it the perfect venue to run some ideas with the community or present some work in progress within a friendly environment. The PC has a broad expertise and submissions are 3 pages long: when in doubt, just submit! (long version) 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. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. ## Submission details Submissions must be at most three pages long; see the full call for papers for details. Submission site: https://ml21.hotcrp.com/ ## Important dates Thu, May 27th 2021 (AoE): submission deadline Thu, Jun 17th 2021 (AoE): author notification Thu, Aug 26th: workshop (time slots TBD) ## 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 ben.franksen at online.de Fri May 21 17:35:50 2021 From: ben.franksen at online.de (Ben Franksen) Date: Fri, 21 May 2021 19:35:50 +0200 Subject: [Haskell-cafe] [ANN] Darcs 2.16.4 release Message-ID: <4f89b0b4-809c-c78a-2a09-69afa6931844@online.de> On behalf of the Darcs team, I would like to announce the release of Darcs 2.16.4 [1]. Quoting from the release notes [2]: This release is mostly to fix http://bugs.darcs.net/issue2674 which can lead to repository corruption. This is not quite as bad as it sounds, since the broken changes that you could have recorded were consistently ignored when applying the patch. This bug has been in darcs for a very long time and even our own repos contain (ancient) patches with broken move changes, and so far it hasn't caused us any trouble. That said, there are certain patch commutations that will erroneously (and unexpectedly) fail when such a patch is involved. We therefore recommend to upgrade. You may also (after upgrading) run 'darcs check' on your repositories to see if you are affected, and 'darcs repair' them if that is the case. Fortunately, the broken move changes can be safely eliminated from existing patches, and the improved repair command now does exactly that. Thanks to Henning Thielemann for bringing this bug to our attention. [1] https://hackage.haskell.org/package/darcs-2.16.3 [2] https://hackage.haskell.org/package/darcs-2.16.3/changelog Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman From ben.franksen at online.de Fri May 21 21:59:53 2021 From: ben.franksen at online.de (Ben Franksen) Date: Fri, 21 May 2021 23:59:53 +0200 Subject: [Haskell-cafe] [ANN] Darcs 2.16.4 release In-Reply-To: <4f89b0b4-809c-c78a-2a09-69afa6931844@online.de> References: <4f89b0b4-809c-c78a-2a09-69afa6931844@online.de> Message-ID: <09a019ac-6712-64f0-f6f0-f4018054bbb9@online.de> I accidentally included links to version 2.16.3. Sorry for that. Here are the correct links: [1] https://hackage.haskell.org/package/darcs-2.16.4 [2] https://hackage.haskell.org/package/darcs-2.16.4/changelog From capn.freako at gmail.com Sat May 22 18:24:23 2021 From: capn.freako at gmail.com (David Banas) Date: Sat, 22 May 2021 11:24:23 -0700 Subject: [Haskell-cafe] Trouble compiling Data.PriorityQueue? Message-ID: Has anyone else bumped into this compilation error when trying to use Data.PriorityQueue? Building library for priority-queue-0.2.1.. [1 of 1] Compiling Data.PriorityQueue ( src/Data/PriorityQueue.hs, dist/build/Data/PriorityQueue.o ) src/Data/PriorityQueue.hs:120:50-54: error: Ambiguous occurrence ‘unzip’ It could refer to either ‘List.unzip’, imported from ‘Data.List’ at src/Data/PriorityQueue.hs:55:1-24 (and originally defined in ‘GHC.List’) or ‘Seq.unzip’, imported from ‘Data.Sequence’ at src/Data/PriorityQueue.hs:54:1-27 (and originally defined in ‘Data.Sequence.Internal’) | 120 | batches = map ((head *** fromList) . unzip) grouped | ^^^^^ cabal: Failed to build priority-queue-0.2.1 (which is required by exe:ex1 from haskarch-0.1.0.0). See the build log above for details. -db From jaro.reinders at gmail.com Sat May 22 18:38:15 2021 From: jaro.reinders at gmail.com (Jaro Reinders) Date: Sat, 22 May 2021 20:38:15 +0200 Subject: [Haskell-cafe] Trouble compiling Data.PriorityQueue? In-Reply-To: References: Message-ID: Note that priority-queue is a pretty old package last uploaded in 2010 without very strict version bounds, so it is understandable that it doesn't compile anymore. I expect that fixing it would not be much work, but I think you will be better off using another priority queue package. Going by number of downloads psqueues and pqueue seem like good libraries. On 22-05-2021 20:24, David Banas wrote: > Has anyone else bumped into this compilation error when trying to use Data.PriorityQueue? > > Building library for priority-queue-0.2.1.. > [1 of 1] Compiling Data.PriorityQueue ( src/Data/PriorityQueue.hs, dist/build/Data/PriorityQueue.o ) > > src/Data/PriorityQueue.hs:120:50-54: error: > Ambiguous occurrence ‘unzip’ > It could refer to either ‘List.unzip’, > imported from ‘Data.List’ at src/Data/PriorityQueue.hs:55:1-24 > (and originally defined in ‘GHC.List’) > or ‘Seq.unzip’, > imported from ‘Data.Sequence’ at src/Data/PriorityQueue.hs:54:1-27 > (and originally defined in ‘Data.Sequence.Internal’) > | > 120 | batches = map ((head *** fromList) . unzip) grouped > | ^^^^^ > cabal: Failed to build priority-queue-0.2.1 (which is required by exe:ex1 from > haskarch-0.1.0.0). See the build log above for details. > > -db > > _______________________________________________ > 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 michael.eugene.turner at gmail.com Sun May 23 01:17:52 2021 From: michael.eugene.turner at gmail.com (Michael Turner) Date: Sun, 23 May 2021 10:17:52 +0900 Subject: [Haskell-cafe] Request for Haskell wiki editing account Message-ID: I've been a contributor to Wikipedia for a long time https://en.wikipedia.org/wiki/Special:Contributions/Yakushima and I'm a Haskell newbie. As I run across problems in getting started, I'd like to improve the Haskell wiki so that others can avoid similar problems. Requested username for Haskell Wiki: Yakushima Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner at projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry From capn.freako at gmail.com Sun May 23 14:38:53 2021 From: capn.freako at gmail.com (David Banas) Date: Sun, 23 May 2021 07:38:53 -0700 Subject: [Haskell-cafe] Using field accessors both ways in the same block of code? Message-ID: Is it possible to use record field accessors both in their “normal” way and as values, via RecordWildCards and MyData{..}, in the same block of code? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Sun May 23 18:32:46 2021 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sun, 23 May 2021 14:32:46 -0400 Subject: [Haskell-cafe] Using field accessors both ways in the same block of code? In-Reply-To: References: Message-ID: On Sun, May 23, 2021 at 07:38:53AM -0700, David Banas wrote: > Is it possible to use record field accessors both in their “normal” > way and as values, via RecordWildCards and MyData{..}, in the same > block of code? {-# LANGUAGE RecordWildCards #-} module M where data X = X { a :: Int , b :: String } doubleTrouble :: X -> (Int, String) doubleTrouble rec at X{..} = (a + a, b <> M.b rec) -- Viktor. From safinaskar at mail.ru Sun May 23 23:56:32 2021 From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=) Date: Mon, 24 May 2021 02:56:32 +0300 Subject: [Haskell-cafe] =?utf-8?q?I_announce_my_library_for_checking_conte?= =?utf-8?q?xt-free_grammar_for_ambiguity_=28was=3A_How_to_do_reversible_pa?= =?utf-8?q?rsing=3F=29?= In-Reply-To: <2933bd03-6c59-495a-d464-149fff943dc0@htwk-leipzig.de> References: <2933bd03-6c59-495a-d464-149fff943dc0@htwk-leipzig.de> Message-ID: <1621814192.801978199@f493.i.mail.ru> Hi. In January I asked a question on parsing: https://mail.haskell.org/pipermail/haskell-cafe/2021-January/133275.html . I am currently writing a library, which will solve my problem. It is not finished, but so far I was able to finish and publish one component: checking grammar for ambiguity. Here it is: https://hackage.haskell.org/package/check-cfg-ambiguity . The code is possibly ugly (ST monad), but I'm happy with this code, and I don't plan to change it. It works. It was tested == Askar Safin From carter.schonwald at gmail.com Mon May 24 00:42:16 2021 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 23 May 2021 20:42:16 -0400 Subject: [Haskell-cafe] I announce my library for checking context-free grammar for ambiguity (was: How to do reversible parsing?) In-Reply-To: <1621814192.801978199@f493.i.mail.ru> References: <2933bd03-6c59-495a-d464-149fff943dc0@htwk-leipzig.de> <1621814192.801978199@f493.i.mail.ru> Message-ID: Very cool! How’s your checking alg work? Using st monad is never a bad thing, I think it’s underused! On Sun, May 23, 2021 at 8:00 PM Askar Safin via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > Hi. In January I asked a question on parsing: > https://mail.haskell.org/pipermail/haskell-cafe/2021-January/133275.html . > I am currently writing a library, which will solve my problem. It is not > finished, but so far I was able to finish and publish one component: > checking grammar > for ambiguity. Here it is: > https://hackage.haskell.org/package/check-cfg-ambiguity . The code is > possibly ugly (ST monad), but I'm happy with this code, > and I don't plan to change it. It works. It was tested > > == > Askar Safin > _______________________________________________ > 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 safinaskar at mail.ru Mon May 24 02:01:50 2021 From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=) Date: Mon, 24 May 2021 05:01:50 +0300 Subject: [Haskell-cafe] =?utf-8?q?I_announce_my_library_for_checking_conte?= =?utf-8?q?xt-free_grammar_for_ambiguity_=28was=3A_How_to_do_reversible_pa?= =?utf-8?q?rsing=3F=29?= In-Reply-To: References: <2933bd03-6c59-495a-d464-149fff943dc0@htwk-leipzig.de> <1621814192.801978199@f493.i.mail.ru> Message-ID: <1621821710.623556449@f114.i.mail.ru> > Very cool! How’s your checking alg work? I generate all strings of symbols, which can be reached from start symbol by replacing nonterminals with their productions no more than "count" times. If I get duplicate, then the grammar is ambiguous. This strings are strings of any symbols, not necessary terminals. And "count" means count of replacements, i. e. count of productions applications. This is simple brute force algorithm. It does not really checks grammar for ambiguity (this is impossible on Turing machine). I can give more details. Also you can read my January letter: https://mail.haskell.org/pipermail/haskell-cafe/2021-January/133275.html . In it I gave links to some checking algorithms, which actually work, but for particular sets of grammars (i. e. not for all of grammars) == Askar Safin From mikolaj at well-typed.com Mon May 24 10:57:40 2021 From: mikolaj at well-typed.com (Mikolaj Konarski) Date: Mon, 24 May 2021 12:57:40 +0200 Subject: [Haskell-cafe] Package takeover: int-cast Message-ID: To whom it may concern, I'd like to take over package https://hackage.haskell.org/package/int-cast (I'd maintain it privately, though I'm subscribed to this mailing list from a company address). People have trouble compiling the roguelike game I maintain, because int-cast is not updated to GHC 9.0.1: https://github.com/LambdaHack/LambdaHack/issues/250 Also the test suite QuickCheck dependency is outdated. I've tried contacting the author, but without success. I'm fine giving the package back once the maintainer re-appears, but I'd also be honoured to maintain it indefinitely --- it's a splendid package. I'd also love to share the maintenance burden, mostly to raise the bus factor, so if anybody would like to get the Hackage permissions together with me, please let me know. Cheers, Mikolaj From matteo at confscience.com Mon May 24 13:23:22 2021 From: matteo at confscience.com (matteo at confscience.com) Date: Mon, 24 May 2021 15:23:22 +0200 Subject: [Haskell-cafe] International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) Prague Message-ID: <01a801d7509f$f86a09c0$e93e1d40$@confscience.com> Call for papers ************************************************* International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) Prague- Czech Republic, October 14-15, 2021 https://confscience.com/irsh/ All papers accepted in IRSH 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: June 13, 2021 (extended) - Acceptance Notification: July 1, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The IRSH 2021 conference will be held in Conjunction with: International Conference on Applied Data Science and Intelligence (ADSI 2021) International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Interoperability and Data Integration - Confidentiality and Data Security - Data protection - Data Sharing - Security, Privacy, and Trust - Emergent healthcare standards - Emergent healthcare architectures - ICT, Ageing and Disability - Physiological and behavioural modelling - Pandemic and disease modeling - Usability and user experience of medical devices - Human behaviour - Clinical investigation regulatory frameworks - Integrated healthcare approaches - eHealth data standards and interoperability (e.g. HL7/FHIR) - Databases and data warehousing - Big Data and Open Data for healthcare - Design and Development of Methodologies for Healthcare - Emergent Communication Technologies - Real-time interaction theories - Emergent Technologies for Ambient Assisted Living - User Interface Design for healthcare - Sustainability - New approaches for accuracy and effectiveness - Data mining and bioinformatics - Enhanced living environments - Analysis and evaluation of healthcare systems INTELLIGENT HEALTHCARE - Pattern recognition and Machine - Learning for healthcare - Cognitive Informatics - Big Data in Healthcare - Wellbeing Informatics - Data Mining and Data Analytics - Data Visualization - Smart environments - Smart Ambient Assisted Living - Intelligent healthcare solutions - Agent-based solutions for healthcare - Collaboration systems - Intelligent Electronic Health Records - Internet of Things for healthcare - Cyber-Physical Systems for healthcare - Ambient Computing and Reasoning - Context Awareness - Smart devices for eldercare - Autonomy and active ageing - Emergent technologies for intelligent Computer Vision - Service production and delivery - Gamification - Multi-modal interaction - Computer-aided detection and diagnosis - Crowdsourcing for smarted healthcare SERVICES, SYSTEMS, AND INFRASTRUCTURES - Emergent healthcare services - Pervasive health systems and services - Remote healthcare management - Emergent healthcare infrastructure - Industry Revolution 4.0 for healthcare - eHealth - Electronic health records - Assistive technologies - Disease surveillance and patient monitoring systems - Prevention and detection systems - Home monitoring - Healthcare management systems - ICT-based therapeutic systems - ICT-based rehabilitation technologies - Wearable health informatics - Emergent technologies for data analytics - Ambient Assisted Leaving (AAL) - Decision Support Systems - Emergent Technologies for Remote AAL Monitoring - Emergent Technologies and Accessibility - 5G for healthcare - Healthcare supply chain and logistics - Wireless Body Networks - Telemedicine and mobile telemedicine - Mobile Systems - Software Defined infrastructures - Patient empowerment systems - Smart technology for remote patient visits - Biosensors - Medical devices APPLICATIONS - eHealth applications - Application of health informatics in clinical cases - Mobile technologies for healthcare applications - Software Systems in healthcare - Social networking and healthcare - Case Studies - Personalization and patient experience - AR and VR applications - Patient billing - Accounting systems - Personnel and payroll - Materials management - Voice recognition systems - Asset management solutions - Disease management - Feedback integration - Clinical software - Crowd-computing applications - Future directions - Drone-based solutions - Software Defined Networks for healthcare *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=irsh2021). All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/irsh/ *************************************************************************** CONTACT For more information, please send an email to info-irsh at confscience.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardyu042 at gmail.com Mon May 24 20:51:17 2021 From: richardyu042 at gmail.com (Richard Yu) Date: Mon, 24 May 2021 16:51:17 -0400 Subject: [Haskell-cafe] Generic Traversal of ASTs Message-ID: I have a question about generic traversal/transformation of nested data structures. From what I understand the main options available are SYB, Uniplate, GHC.Generics and Data.Lens (although I am under the impression this requires record types). The data structure I am attempting to traverse is similar to this simplified version: data SExpr = Expr | Const data Const = B bool | I int data Expr = Lambda String SExpr | If Expr ... I have attempted to use Uniplate and GHC.Generics to traverse the built AST and modify for example, the string of a Lambda type, but have not been able to figure out how to get any of the libraries to typecheck. The examples or docs I found were not quite enough. Does anyone know of examples that might help or explain how I should be using the generic libraries? In addition if I moved to writing the AST with GADTs, do some generic traversal strategies/libraries stop working? Many thanks, Richard -------------- next part -------------- An HTML attachment was scrubbed... URL: From S.J.Thompson at kent.ac.uk Tue May 25 08:48:46 2021 From: S.J.Thompson at kent.ac.uk (Simon Thompson) Date: Tue, 25 May 2021 08:48:46 +0000 Subject: [Haskell-cafe] Generic Traversal of ASTs In-Reply-To: References: Message-ID: Hi Richard - one thread of the history of work is in the “strategic programming” work of Stratego (untyped) and Strafunski (implemented in Haskell) by Eelco Visser and Ralf Lämmel (resp.). https://strategoxt.org/Stratego/StrategoLanguage.html https://link.springer.com/chapter/10.1007/978-3-540-25935-0_13 https://www.researchgate.net/publication/220802944_A_Strafunski_Application_Letter We explicitly used this approach in our first implementation of Wrangler (with Strafunski), and continue in other work to take this approach. For example “stop_top_down” is used heavily. HTH Simon On 24 May 2021, at 21:51, Richard Yu > wrote: CAUTION: This email originated from outside of the organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe. I have a question about generic traversal/transformation of nested data structures. From what I understand the main options available are SYB, Uniplate, GHC.Generics and Data.Lens (although I am under the impression this requires record types). The data structure I am attempting to traverse is similar to this simplified version: data SExpr = Expr | Const data Const = B bool | I int data Expr = Lambda String SExpr | If Expr ... I have attempted to use Uniplate and GHC.Generics to traverse the built AST and modify for example, the string of a Lambda type, but have not been able to figure out how to get any of the libraries to typecheck. The examples or docs I found were not quite enough. Does anyone know of examples that might help or explain how I should be using the generic libraries? In addition if I moved to writing the AST with GADTs, do some generic traversal strategies/libraries stop working? Many thanks, Richard _______________________________________________ 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. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt -------------- next part -------------- An HTML attachment was scrubbed... URL: From neto at netowork.me Tue May 25 15:29:20 2021 From: neto at netowork.me (Ernesto Rodriguez) Date: Tue, 25 May 2021 09:29:20 -0600 Subject: [Haskell-cafe] [Haskell] (Online) Utrecht Summer School on Advanced functional programming In-Reply-To: <959d805c-b436-7357-4ba7-893788c394bb@uu.nl> References: <959d805c-b436-7357-4ba7-893788c394bb@uu.nl> Message-ID: Hi, I just wanted to mention that I studied my MsC. degree at Utrecht University and Prof. Swiestra was my thesis supervisor. I cannot recommend this summer school enough. Not only are Prof. Swiestra's accomplishments extraordinary (you can look that up online) but he is also very gifted at teaching. I took many courses with him and were both interesting and entertaining. Prof. Swiestra is also very patient and dedicated and I am sure he will put a lot of care making sure his students thoroughly understand the topics and ensuring the summer school is well organized and structured. All other professors I had in Utrecht were excellent at teaching so I believe this is a great opportunity to "shift up gears" in the wonderful Haskell language. Best regards, Ernesto Rodriguez On Thu, May 6, 2021 at 9:11 AM Swierstra, W.S. (Wouter) via Haskell < haskell at haskell.org> wrote: > SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING > > Online - 05-9 July 2021 > > http://www.afp.school > > # Call for Participation > > ## About > > The Advanced Functional Programming summer school has been running for > more than ten years. We aim to educate aspiring Haskell programmers > beyond the basic material covered by many textbooks. > > This year the course will be offered *online only*. A typical day will > consist a 2-3 hours of lectures, sandwiched between supervised lab > sessions. Lectures will be held in the (European) afternoon, but > recordings will be made available if attending live is problematic. > > The lectures will cover several more advanced topics regarding > programming with types in Haskell, including topics such as: > > * monads and applicative functors; > * lambda calculus; > * generalized algebraic datatypes; > * datatype generic programming > * type families and type-level programming; > > ## Lecturers > > Utrecht staff: > * Gabriele Keller > * Trevor McDonell > * Wouter Swierstra > > ## Prerequisites > > We expect students to have a basic familiarity with Haskell > already. You should be able to write recursive functions over > algebraic data types, such as lists and trees. There is a great deal > of material readily available that covers this material. If you've > already started learning Haskell and are looking to take your > functional programming skills to the next level, this is the course > for you. > > Soft registration deadline: 1 June, 2021 > School: 05-09 July, 2021 > > ## Costs > > 50 euro - Registration fee > > We ask ask participants to pay a small registration fee to cover some > of our organizational expenses. If this is problematic for you *for > whatever reason*, please let us know and we can waive your > registration fee. > > ## Further information > > Further information, including instructions on how to register, is > available on our website: > > http://www.afp.school > > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > -- Ernesto Rodriguez Masters Student Computer Science Utrecht University www.netowork.me github.com/netogallo -------------- next part -------------- An HTML attachment was scrubbed... URL: From develop7 at develop7.info Tue May 25 16:13:04 2021 From: develop7 at develop7.info (Andrei Dziahel) Date: Tue, 25 May 2021 18:13:04 +0200 Subject: [Haskell-cafe] [Haskell-beginners] (Online) Utrecht Summer School on Advanced functional programming In-Reply-To: <959d805c-b436-7357-4ba7-893788c394bb@uu.nl> References: <959d805c-b436-7357-4ba7-893788c394bb@uu.nl> Message-ID: Exciting initiative, looking forward to attend it. The afp.school site doesn't seem to mention the link to the course page itself which you'll need along the course of the application, so here it goes for everyone's convenience — https://www.utrechtsummerschool.nl/courses/science/applied-functional-programming-in-haskell On Thu, May 6, 2021 at 5:14 PM Swierstra, W.S. (Wouter) wrote: > > SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING > > Online - 05-9 July 2021 > > http://www.afp.school > > # Call for Participation > > ## About > > The Advanced Functional Programming summer school has been running for > more than ten years. We aim to educate aspiring Haskell programmers > beyond the basic material covered by many textbooks. > > This year the course will be offered *online only*. A typical day will > consist a 2-3 hours of lectures, sandwiched between supervised lab > sessions. Lectures will be held in the (European) afternoon, but > recordings will be made available if attending live is problematic. > > The lectures will cover several more advanced topics regarding > programming with types in Haskell, including topics such as: > > * monads and applicative functors; > * lambda calculus; > * generalized algebraic datatypes; > * datatype generic programming > * type families and type-level programming; > > ## Lecturers > > Utrecht staff: > * Gabriele Keller > * Trevor McDonell > * Wouter Swierstra > > ## Prerequisites > > We expect students to have a basic familiarity with Haskell > already. You should be able to write recursive functions over > algebraic data types, such as lists and trees. There is a great deal > of material readily available that covers this material. If you've > already started learning Haskell and are looking to take your > functional programming skills to the next level, this is the course > for you. > > Soft registration deadline: 1 June, 2021 > School: 05-09 July, 2021 > > ## Costs > > 50 euro - Registration fee > > We ask ask participants to pay a small registration fee to cover some > of our organizational expenses. If this is problematic for you *for > whatever reason*, please let us know and we can waive your > registration fee. > > ## Further information > > Further information, including instructions on how to register, is > available on our website: > > http://www.afp.school > > > _______________________________________________ > Beginners mailing list > Beginners at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners -- Regards, Andrei Dziahel From andrei.h.popescu at gmail.com Wed May 26 13:15:12 2021 From: andrei.h.popescu at gmail.com (Andrei Popescu) Date: Wed, 26 May 2021 14:15:12 +0100 Subject: [Haskell-cafe] =?utf-8?q?PhD_position_on_the_formalization_of_log?= =?utf-8?q?ical_calculi_in_Saarbr=C3=BCcken?= Message-ID: A PhD position is open at the MPI for Informatics in Saarbrücken, supervised by Christoph Weidenbach, Jasmin Blanchette and Sophie Tourret. The project is about using Isabelle/HOL to formalize logical calculi. See https://www.cs.vu.nl/~jbe248/sb_job.html for more information. From safinaskar at mail.ru Thu May 27 13:07:39 2021 From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=) Date: Thu, 27 May 2021 16:07:39 +0300 Subject: [Haskell-cafe] =?utf-8?q?Is_there_some_tool_for_inferring_wide_de?= =?utf-8?q?pendency_ranges=3F?= Message-ID: <1622120859.458784828@f479.i.mail.ru> Hi. Is there some tool for inferring dependency ranges for my cabal packages? I know about "cabal gen-bounds", but this command gives too short ranges. I want to get as wide range as possible. I. e. I want tool, which tries to build and test my package on various versions of dependencies, and reports resulting range. Successful testing should mean that the version of dependency is compatible. That tool should work also on "base" package, this means that it should test various ghc versions, too. If there is no such tool, then at least I want some tool, which will check already specified dependency range. Such tool should do this: - Extract dependencies from cabal file - Install smallest versions of specified dependencies (this will include "base" and thus ghc) - Test on this versions - Install largest versions - Test on this versions I will put invocation of such tool to continuous integration. I hope there are a lot of package maintainers here. How do you manage dependencies? == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar From oleg.grenrus at iki.fi Thu May 27 17:30:08 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 27 May 2021 20:30:08 +0300 Subject: [Haskell-cafe] Is there some tool for inferring wide dependency ranges? In-Reply-To: <1622120859.458784828@f479.i.mail.ru> References: <1622120859.458784828@f479.i.mail.ru> Message-ID: I (kind of) have such tool, it's not feasible for continuous integration usage. For an example let consider lens-package. It has some dependencies, plenty for manual check to be infeasible, but not extremely many. My tool has a mode where it tries to find an /effective/ lower bound constrained by present `build-depends` constraints. And additional flag, to build-verify it.  I.e. this is not even a proper search. An algorithm is simple: foreach dependency   check which existing dependency versions are in range     splitting the set (with some heuristics considering major versions etc).     figure out the effective lower bound for each dependency. Note: the lower bound verification is "complete" in per-dependency approach, but full range verification is more expensive due combinatorical explosion. Another note: if yourr lower bound is wrong you have to figure out why by your own. Looking at the error and scanning through changelogs has often proven to be faster approach (humans are good at combining information). And still, this "O(dependecies x versions in average range)" algorithm is slow if we decide to build/verify the found bounds. I started with somewhat outdated cabal nix-style cache, i.e. I haven't run this command previously.  (When just working on stuff cabal picks ~latest versions, i.e. skewed dependency install plans as we need here are not present in the cache). After the run we get a nice output (for current `lens` master), which has colors in the terminal telling some information beyond just versions.                                    8.0.2     8.2.2     8.4.4     8.6.5     8.8.4     8.10.4    9.0.1     array                          0.5.1.1   0.5.2.0   0.5.2.0   0.5.3.0   0.5.4.0   0.5.4.0   0.5.4.0     assoc                          1.0.2     1.0.2     1.0.2     1.0.2     1.0.2     1.0.2     1.0.2     base                           4.9.1.0   4.10.1.0  4.11.1.0  4.12.0.0  4.13.0.0  4.14.1.0  4.15.0.0     base-orphans                   0.5.2     0.5.4     0.5.4     0.5.4     0.8.1     0.8.1     0.8.1     bifunctors                     5.5.7     5.5.7     5.5.7     5.5.7     5.5.7     5.5.7     5.5.8     bytestring                     0.10.6.0  0.10.6.0  0.10.8.0  0.10.8.0  0.10.8.1  0.10.8.1  0.10.9.0     call-stack                     0.1.0     0.1.0     0.1.0     0.1.0     0.1.0     0.1.0     0.1.0     comonad                        5.0.7     5.0.7     5.0.7     5.0.7     5.0.7     5.0.7     5.0.7     containers                     0.5.7.0   0.5.7.0   0.5.7.0   0.5.7.0   0.5.7.0   0.5.7.0   0.5.7.0     contravariant                  1.4       1.4       1.4       1.5       1.5       1.5       1.5     distributive                   0.5.1     0.5.2     0.5.3     0.5.3     0.5.3     0.5.3     0.5.3     exceptions                     0.8.2.1   0.8.3     0.8.3     0.10.0    0.10.2    0.10.4    0.10.4     filepath                       1.2.0.0   1.2.0.0   1.2.0.0   1.2.0.0   1.2.0.0   1.2.0.0   1.2.0.0     free                           5.1.5     5.1.5     5.1.5     5.1.5     5.1.5     5.1.5     5.1.5     ghc-prim                       0.5.0.0   0.5.1.1   0.5.2.0   0.5.3     0.5.3     0.6.1     0.7.0     hashable                       1.2.7.0   1.2.7.0   1.2.7.0   1.2.7.0   1.3.0.0   1.3.0.0   1.3.1.0     indexed-traversable            0.1.1     0.1.1     0.1.1     0.1.1     0.1.1     0.1.1     0.1.1     indexed-traversable-instances  0.1       0.1       0.1       0.1       0.1       0.1       0.1     kan-extensions                 5.1       5.1       5.1       5.1       5.1       5.1       5.1     mtl                            2.2.1     2.2.1     2.2.1     2.2.1     2.2.1     2.2.1     2.2.1     parallel                       3.2.1.0   3.2.1.1   3.2.1.1   3.2.2.0   3.2.2.0   3.2.2.0   3.2.2.0     profunctors                    5.5.2     5.5.2     5.5.2     5.5.2     5.5.2     5.5.2     5.6     reflection                     2.1       2.1       2.1.3     2.1.4     2.1.4     2.1.4     2.1.4     semigroupoids                  5.0.1     5.2       5.2.2     5.2.2     5.3.2     5.3.2     5.3.4     strict                         0.4       0.4       0.4       0.4       0.4       0.4       0.4     tagged                         0.8.6     0.8.6     0.8.6     0.8.6     0.8.6     0.8.6     0.8.6     template-haskell               2.11.1.0  2.12.0.0  2.13.0.0  2.14.0.0  2.15.0.0  2.16.0.0  2.17.0.0     text                           1.2.3.0   1.2.3.0   1.2.3.0   1.2.3.0   1.2.4.0   1.2.3.2   1.2.4.1     th-abstraction                 0.4.1.0   0.4.1.0   0.4.1.0   0.4.1.0   0.4.1.0   0.4.1.0   0.4.1.0     these                          1.1.1.1   1.1.1.1   1.1.1.1   1.1.1.1   1.1.1.1   1.1.1.1   1.1.1.1     transformers                   0.5.0.0   0.5.0.0   0.5.5.0   0.5.5.2   0.5.6.0   0.5.6.0   0.5.6.0     transformers-compat            0.5.0.4   0.5.0.4   0.5.0.4   0.5.0.4   0.5.0.4   0.5.0.4   0.5.0.4     unordered-containers           0.2.10.0  0.2.10.0  0.2.10.0  0.2.10.0  0.2.10.0  0.2.10.0  0.2.10.0     vector                         0.12.1.2  0.12.1.2  0.12.1.2  0.12.1.2  0.12.1.2  0.12.1.2  0.12.2.0 ... after two hours of wall time, or a day of CPU time.             dry        dep         build     counts  1147       238         237     q50     3.932s     84.624s     166.224s     q90     5.223s     251.763s    269.377s     total   4583.699s  25147.444s  43101.014s     usr: 80390.500s   sys: 6018.400s   cpu: 1204.249%   time: 7175.338s Note that solving alone takes hour and a half of CPU time, fortunately that is highly parallelisable task. Building dependencies takes plenty of time, there I have only single GHC building dependencies, to avoid rebuilding the same ones and avoding store corruption (which shouldn't happen, but happens). Finally the building of package itself in various combinations is again parallizable, as store is only read. For `lens` that has considerable cost on its own. (After all the package is built 7 times 30 times). --- Funny coincidence is that kan-extensions-5.1 had wrong upper bound on base/GHC, as it doesn't build with it. For that my tool has a differnt mode of operations for building multiple package versions at once, a bit like matrix.hackage.haskell.org, but locally. That's what I use to locally test that mass revision edits are ok. We get                       9.2.0.20210422  9.0.1  8.10.4  8.8.4  8.6.5  8.4.4  8.2.2  8.0.2  7.10.3  7.8.4  7.6.3  7.4.2  7.2.2  7.0.4 kan-extensions-5.2.2  NO-IP           OK     OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     NO-IP  NO-IP kan-extensions-5.2.1  NO-IP           OK     OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     NO-IP  NO-IP kan-extensions-5.2    NO-IP           NO-IP  OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     NO-IP  NO-IP kan-extensions-5.1    NO-IP           FAIL   OK      OK     OK     OK     OK     OK     OK      OK     OK     OK     NO-IP  NO-IP kan-extensions-5.0.2  NO-IP           NO-IP  NO-IP   NO-IP  NO-IP  NO-IP  OK     OK     OK      OK     OK     OK     NO-IP  NO-IP That operation **is fast**, as dependencies are reused well, so there is no cold cabal nix-style store cache issues.             dry       dep      build     counts  70        48       48     q50     0.707s    0.128s   0.632s     q90     4.844s    0.169s   14.290s     total   163.226s  31.414s  184.551s     usr: 342.020s   sys: 37.060s   cpu: 905.090%   time: 41.883s Under a minute of wall clock. That hopefully highlights why `matrix.hackage.haskell.org` is feasible, but "bounds check" isn't. The difference in need computational resources is huge. So after making a revision to turn FAIL into NO-IP (no install plan), using Hackage Trustees' super powers, and we can return to `lens`. The result is the same, except the minimum kan-extensions version on GHC-9.0 is 5.2.1 This time the run is significantly faster:              dry        dep      build      counts  1148       238      238      q50     6.278s     0.210s   1.000s      q90     7.225s     0.284s   1.268s      total   6937.215s  69.420s  389.536s      usr: 6825.120s   sys: 554.600s   cpu: 2163.272%   time: 341.137s but still two hours of CPU time.  (I hope solving could be a lot faster if cabal-install-solver were available as usable library, but we are quite far from that).  Also note that cpu usage is 2200%, it's a very good idea to have many cores for this kind of work. Here we benefit from local cache of dependencies, but also the local `dist-newstyle/` directories previous run left behind.  As you can see, build-step is quite fast.  The previous many hour work would need to be repeated, if we would make a change to `lens` itself (especially in a way such incremental build is not very fast). There is 11GB of build products i.e. these 7 x 30 versions of lens.  That is a thing ot be aware of too. In summary, if you try something like this on a GitHub-hosted GitHub Actions runner https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners     Hardware specification for Windows and Linux virtual machines:     2-core CPU     7 GB of RAM memory     14 GB of SSD disk space ... it just won't work. --- Do I have suggestions what to do instead? For example haskell-ci allows to specify constraint sets, and I have one for example in quickcheck-instances, https://github.com/haskellari/qc-instances/blob/master/cabal.haskell-ci That is a (rare) package where I do care about having as wide dependency range as possible, as I don't want to run into problems due it. That cost is just one additional build per CI run (note: also dependencies). Honestly, I don't remember how I found those versions, whether using my tool or by trial-an-error.  As you can see from the history of that file, I don't need to edit them often.  (last modification is August 2020). For ordinary packages, I'd just suggest using picking the current versions as lower bounds (e.g. what gen-bounds suggests), and sticking to them until there is a reason to not too.  Don't spend too much time pushing them down from what's currently possible, if there isn't real reason.  You may pick older Stackage LTS snapshot (for the oldest GHC you want to support) for some inspiration, though I often don't do that, as dependency versions tend to be quite old.  For example there is no value in allowing older QuickCheck versions in your test-suite, it's unluckily they will find you bugs that newer versions won't. - Oleg On 27.5.2021 16.07, Askar Safin via Haskell-Cafe wrote: > Hi. Is there some tool for inferring dependency ranges for my cabal packages? I know about "cabal gen-bounds", but this command gives too short ranges. I want to get as wide range as possible. I. e. I want tool, which tries to build and test my package on various versions of dependencies, and reports resulting range. Successful testing should mean that the version of dependency is compatible. That tool should work also on "base" package, this means that it should test various ghc versions, too. > > If there is no such tool, then at least I want some tool, which will check already specified dependency range. Such tool should do this: > - Extract dependencies from cabal file > - Install smallest versions of specified dependencies (this will include "base" and thus ghc) > - Test on this versions > - Install largest versions > - Test on this versions > > I will put invocation of such tool to continuous integration. > > I hope there are a lot of package maintainers here. How do you manage dependencies? > > == > Askar Safin > http://safinaskar.com > https://sr.ht/~safinaskar > https://github.com/safinaskar > _______________________________________________ > 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 twhitehead at gmail.com Thu May 27 18:31:43 2021 From: twhitehead at gmail.com (Tyson Whitehead) Date: Thu, 27 May 2021 14:31:43 -0400 Subject: [Haskell-cafe] Could optimize attoparsec if GHC would collapse `runParser (Parser parser)` to `parser` Message-ID: Hi. I'm hoping someone with some knowledge about GHC optimizations can weigh in and help out here. The attoparsec library has a `<|>` combinator for choice. Since attoparsec does arbitrary backtracking, you would expect that `recursiveLhs <|> rhs` would stack up a bunch of `rhs` alternatives to the depth of the recursion. Looking at the definitions though, would make you believe that so long as the `rhs` is constant as it usually is (e.g., `pure []` if you are collecting a list), inlining should result in it not stacking up a bunch of the `rhs` alternatives (intuitively the most recent one will always succeed so there is no reason to hold on to more than one). Unfortunately, it doesn't seem to work. The full details can be found in this bug report https://github.com/haskell/attoparsec/issues/186 but I believe it comes down to the fact that GHC is not collapsing a packing and immediate unpacking of the parser datatype ``` runParser (Parser parser) -> parser ``` which is resulting in the fact that the `rhs` always succeeds (i.e., doesn't use the failure continuation) not being exposed. I am hoping someone knowledgeable in these matters could weigh in. Thanks! -Tyson PS: The parser datatype is a wrapper on CPS style lambda ``` newtype Parser i a = Parser { runParser :: forall r. State i -> Pos -> More -> Failure i (State i) r -> Success i (State i) a r -> IResult i r } ``` where Failure and Success are type synonyms for the continuations ``` type Failure i t r = t -> Pos -> More -> [String] -> String -> IResult i r type Success i t a r = t -> Pos -> More -> a -> IResult i r ``` From ben.franksen at online.de Thu May 27 18:50:56 2021 From: ben.franksen at online.de (Ben Franksen) Date: Thu, 27 May 2021 20:50:56 +0200 Subject: [Haskell-cafe] International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) Prague In-Reply-To: <01a801d7509f$f86a09c0$e93e1d40$@confscience.com> References: <01a801d7509f$f86a09c0$e93e1d40$@confscience.com> Message-ID: Once again: Can the list admins please block this spammer? Thanks Ben Am 24.05.21 um 15:23 schrieb matteo at confscience.com: > Call for papers > > ************************************************* > > International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) > > Prague- Czech Republic, October 14-15, 2021 > > https://confscience.com/irsh/ > > All papers accepted in IRSH 2021 will be published in Springer CCIS (Communications in Computer and Information Science). > > CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) > > *************************************************************************** > > IMPORTANT DATES: > > - Paper Submission: June 13, 2021 (extended) > > - Acceptance Notification: July 1, 2021 > > - Final Manuscript Due: September 1, 2021 > > *************************************************************************** > > The IRSH 2021 conference will be held in Conjunction with: > > International Conference on Applied Data Science and Intelligence (ADSI 2021) > > International Conference on Recent Theories and Applications in Transportation and Mobility - (RTATM 2021) > > *************************************************************************** > > TOPICS: > > Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: > > FUNDAMENTALS AND THEORIES > > - Interoperability and Data Integration > > - Confidentiality and Data Security > > - Data protection > > - Data Sharing > > - Security, Privacy, and Trust > > - Emergent healthcare standards > > - Emergent healthcare architectures > > - ICT, Ageing and Disability > > - Physiological and behavioural modelling > > - Pandemic and disease modeling > > - Usability and user experience of medical devices > > - Human behaviour > > - Clinical investigation regulatory frameworks > > - Integrated healthcare approaches > > - eHealth data standards and interoperability (e.g. HL7/FHIR) > > - Databases and data warehousing > > - Big Data and Open Data for healthcare > > - Design and Development of Methodologies for Healthcare > > - Emergent Communication Technologies > > - Real-time interaction theories > > - Emergent Technologies for Ambient Assisted Living > > - User Interface Design for healthcare > > - Sustainability > > - New approaches for accuracy and effectiveness > > - Data mining and bioinformatics > > - Enhanced living environments > > - Analysis and evaluation of healthcare systems > > INTELLIGENT HEALTHCARE > > - Pattern recognition and Machine > > - Learning for healthcare > > - Cognitive Informatics > > - Big Data in Healthcare > > - Wellbeing Informatics > > - Data Mining and Data Analytics > > - Data Visualization > > - Smart environments > > - Smart Ambient Assisted Living > > - Intelligent healthcare solutions > > - Agent-based solutions for healthcare > > - Collaboration systems > > - Intelligent Electronic Health Records > > - Internet of Things for healthcare > > - Cyber-Physical Systems for healthcare > > - Ambient Computing and Reasoning > > - Context Awareness > > - Smart devices for eldercare > > - Autonomy and active ageing > > - Emergent technologies for intelligent Computer Vision > > - Service production and delivery > > - Gamification > > - Multi-modal interaction > > - Computer-aided detection and diagnosis > > - Crowdsourcing for smarted healthcare > > SERVICES, SYSTEMS, AND INFRASTRUCTURES > > - Emergent healthcare services > > - Pervasive health systems and services > > - Remote healthcare management > > - Emergent healthcare infrastructure > > - Industry Revolution 4.0 for healthcare > > - eHealth > > - Electronic health records > > - Assistive technologies > > - Disease surveillance and patient monitoring systems > > - Prevention and detection systems > > - Home monitoring > > - Healthcare management systems > > - ICT-based therapeutic systems > > - ICT-based rehabilitation technologies > > - Wearable health informatics > > - Emergent technologies for data analytics > > - Ambient Assisted Leaving (AAL) > > - Decision Support Systems > > - Emergent Technologies for Remote AAL Monitoring > > - Emergent Technologies and Accessibility > > - 5G for healthcare > > - Healthcare supply chain and logistics > > - Wireless Body Networks > > - Telemedicine and mobile telemedicine > > - Mobile Systems > > - Software Defined infrastructures > > - Patient empowerment systems > > - Smart technology for remote patient visits > > - Biosensors > > - Medical devices > > APPLICATIONS > > - eHealth applications > > - Application of health informatics in clinical cases > > - Mobile technologies for healthcare applications > > - Software Systems in healthcare > > - Social networking and healthcare > > - Case Studies > > - Personalization and patient experience > > - AR and VR applications > > - Patient billing > > - Accounting systems > > - Personnel and payroll > > - Materials management > > - Voice recognition systems > > - Asset management solutions > > - Disease management > > - Feedback integration > > - Clinical software > > - Crowd-computing applications > > - Future directions > > - Drone-based solutions > > - Software Defined Networks for healthcare > > > > *************************************************************************** > > OUTSTANDING PAPERS: > > Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. > > *************************************************************************** > > PAPER SUBMISSION: > > Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=irsh2021). > > All papers will be peer reviewed. > > Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) > > Length of Short papers: less than 12 pages > > For more information, please refer to the conference website: https://confscience.com/irsh/ > > > > *************************************************************************** > > CONTACT > > For more information, please send an email to info-irsh at confscience.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. > -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman From safinaskar at mail.ru Thu May 27 20:28:20 2021 From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=) Date: Thu, 27 May 2021 23:28:20 +0300 Subject: [Haskell-cafe] =?utf-8?q?Is_there_some_tool_for_inferring_wide_de?= =?utf-8?q?pendency_ranges=3F?= In-Reply-To: References: <1622120859.458784828@f479.i.mail.ru> Message-ID: <1622147300.463145792@f722.i.mail.ru> Oleg Grenrus, thanks a lot for big answer! Please, give a link to your tool. Ideally with some free software license. Let me repeat my needs. My packages are smaller than lens. Currently I have very small package https://hackage.haskell.org/package/check-cfg-ambiguity . It has two dependencies only: base and containers. And I plan to publish 1-2 packages more, they will be small, too. I use SourceHut as code hosting and continuous integration platform. CI config is specified in usual "shell script in YAML" form ( https://lobste.rs/s/v4crap/crustaceans_2021_will_be_year_technology#c_ker4jn ) in file ".build.yml". See https://git.sr.ht/~safinaskar/check-cfg-ambiguity/tree/a9fc453eb73250650f3458659344e1b902538027/item/.build.yml for an example. Ideally, I want two different tools. First tool should actually compute dependency ranges. It will rebuild my package a lot of times during this computation. I don't plan to run this tool often. I think I will run it one time before each release. So, it is not necessary to put it into continuous integration. The second tool should simply check that package is compatible with specified range. To do this, the tool should build package exactly two times: one with all specified lower bounds and one with all specified upper bounds. So, there is no any kind of combinatoric explosion. And it is perfectly okay to run such tool in continuous integration at every commit. Currently I have neither tool. The second tool is very simple. Well, in some sense I don't need such tool at all, because I can just put to my .build.yml shell commands for building my package with two version sets. But then I have to specify versions two times: one in *.cabal and one in .build.yml. I. e. we got DRY violation. So here is my question: is there some existing tool, which extracts bounds from *.cabal and run that two builds? > For example haskell-ci allows to specify constraint sets, > and I have one for example in quickcheck-instances, > https://github.com/haskellari/qc-instances/blob/master/cabal.haskell-ci As I can see both cabal.haskell-ci and quickcheck-instances.cabal specify versions, so you got that DRY violation, too. == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar From oleg.grenrus at iki.fi Thu May 27 22:25:39 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Fri, 28 May 2021 01:25:39 +0300 Subject: [Haskell-cafe] Is there some tool for inferring wide dependency ranges? In-Reply-To: <1622147300.463145792@f722.i.mail.ru> References: <1622120859.458784828@f479.i.mail.ru> <1622147300.463145792@f722.i.mail.ru> Message-ID: For small packages, which depend on boot libraries only (i.e. the ones which come with GHC), I suggest you take a look at https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-history (there is link to it from https://matrix.hackage.haskell.org/). Running `ghc-pkg- list` on command line also works. I'll use `containers` as an example of a boot library. It is wise to allow the version of containers which is bundled with the oldest GHC you plan to support, so people don't need to reinstall that dependency. Further, let us assume that GHC-8.0 is the oldest compiler version you want to support.  then you look at the table (or `ghc-pkg list` output) and figure out that the containers-0.5.7.1 is bundled with GHC-8.0.2.  Therefore `containers >=0.5.7.1` is the perfect lower bound. There is no good reason to allow older versions, using such configurations is most likely a mistake. For your second need, I'd suggest that you indeed just repeat yourself.     constraints: dependency-one ==0.0.1     constraints: dependency-two ==0.1.2     ... and rebuild. > As I can see both cabal.haskell-ci and quickcheck-instances.cabal specify > versions, so you got that DRY violation, too. I don't think so. They are redundant, but if I (or a contributor) bumps a lower bound in `quickcheck-instances.cabal` that will most likely result into a build failure. Also dependencies depend on each other, e.g. changing unordered-containers bounds most likely may require adjusting hashable bounds: I like to keep my lower bounds tight, so I'd need to rerun my tool to figure out. (unordered-containers and hashable is not a good example though as  unordered-containers lower bounds are very loose) I may forget, CI catches it. Here redundancy is not bad thing. Most importantly, lower bounds are quite static. Just repeat them. We should note that dependency solving solutions are not "convex", i.e. a package may have lower bounds bounds     pkg-a >=1.2,     pkg-b >=0.4 and while there are install plans with individual dependency at the lower bound, the `--constraint=pkg-a==1.2 --constraint=pkg-b==0.4` requirement is not satisifiable. Thus in general this problem is hard, and cannot be solved by just looking at `.cabal` file. Of course /you/ are free to make your lower bounds "convex", so such tool would work, but that is not general solution. Even figuring out the convex solution is hard. To make all lower bounds satisfiable simultaneously, that tool should somehow figure out find out e.g. `pkg-a ==1.2.3` and `pkg ==0.4.5` configuration. skipping few releases of both packages. Note: the same problem happens with the upper bounds, and there cabal solver makes an arbitrary choice (usually picking the later version of a dependency it considered first - an implementation detail). You may think that changing the solver to traverse the dependency tree in reverse order would work (favouring old versions), but when I tried that, the run times were miserable, solver starts to backtrack a lot more. As I said in my first email, just pick the current package versions you use as the lower bounds, and stick to them for a while. Do not overthink. I made that mistake myself, you end up doing work no-one benefitted from. Wider dependency ranges: YAGNI. One more important note is that to be 100% sure you must test the intermediate versions. This is especially true if the version range spans many major versions, e.g. `lens >=4.10 && <5.1`. Technically, you need to test 4.10, 4.11, 4.12, .. 4.19 and 5. Probably also lowest and highest point release. Luckily most maintainers are sane and don't do back-and-forth changes, but it did happen with aeson (0.9, 0.10, 0.11 IIRC, (.:?) behaviour was changed and reverted), so it can happen to anyone. (I also remember a case where 0.x.0.0 release accidentally removed some functionality, an accidental mistake happened while moving stuff around. That is fine as it was major release, but as the functionality was then restored in 0.x.1.0, having continuous version range allowing 0.x.0.0 point is incorrect). So you may want to test with multiple constraint sets, complete or not. One use case if your package has (manual) flags, there you'd have     constraints: my-package +a-flag or     constraints: my-package -a-flag I need a tool because I maintain dozens of packages, and my workflow is quite uniform, but also unique, so I automated parts of it.  I suggest some simple and flexible "DIY" solutions to you instead, figuring out how to configure and use my tool will take you more time. `cabal gen-bounds` using the oldest GHC you use, and then relaxing upper bounds is a simple way. - Oleg On 27.5.2021 23.28, Askar Safin wrote: > Oleg Grenrus, thanks a lot for big answer! Please, give a link to your tool. Ideally with some free software license. > > Let me repeat my needs. > > My packages are smaller than lens. Currently I have very small package https://hackage.haskell.org/package/check-cfg-ambiguity . It has two dependencies only: base and containers. And I plan to publish 1-2 packages more, they will be small, too. > > I use SourceHut as code hosting and continuous integration platform. CI config is specified in usual "shell script in YAML" form ( https://lobste.rs/s/v4crap/crustaceans_2021_will_be_year_technology#c_ker4jn ) in file ".build.yml". See https://git.sr.ht/~safinaskar/check-cfg-ambiguity/tree/a9fc453eb73250650f3458659344e1b902538027/item/.build.yml for an example. > > Ideally, I want two different tools. > > First tool should actually compute dependency ranges. It will rebuild my package a lot of times during this computation. I don't plan to run this tool often. I think I will run it one time before each release. So, it is not necessary to put it into continuous integration. > > The second tool should simply check that package is compatible with specified range. To do this, the tool should build package exactly two times: one with all specified lower bounds and one with all specified upper bounds. So, there is no any kind of combinatoric explosion. And it is perfectly okay to run such tool in continuous integration at every commit. > > Currently I have neither tool. > > The second tool is very simple. Well, in some sense I don't need such tool at all, because I can just put to my .build.yml shell commands for building my package with two version sets. But then I have to specify versions two times: one in *.cabal and one in .build.yml. I. e. we got DRY violation. So here is my question: is there some existing tool, which extracts bounds from *.cabal and run that two builds? > >> For example haskell-ci allows to specify constraint sets, >> and I have one for example in quickcheck-instances, >> https://github.com/haskellari/qc-instances/blob/master/cabal.haskell-ci > As I can see both cabal.haskell-ci and quickcheck-instances.cabal specify versions, so you got that DRY violation, too. > > == > Askar Safin > http://safinaskar.com > https://sr.ht/~safinaskar > https://github.com/safinaskar From safinaskar at mail.ru Thu May 27 23:27:26 2021 From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=) Date: Fri, 28 May 2021 02:27:26 +0300 Subject: [Haskell-cafe] =?utf-8?q?Is_there_some_tool_for_inferring_wide_de?= =?utf-8?q?pendency_ranges=3F?= In-Reply-To: References: <1622120859.458784828@f479.i.mail.ru> <1622147300.463145792@f722.i.mail.ru> Message-ID: <1622158046.98439665@f401.i.mail.ru> Oleg Grenrus, thanks a lot! == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar From david.nowak at univ-lille.fr Fri May 28 06:05:17 2021 From: david.nowak at univ-lille.fr (David Nowak) Date: Fri, 28 May 2021 08:05:17 +0200 Subject: [Haskell-cafe] PhD position on program verification in Coq Message-ID: <8D28C8D0-8EFB-4BB0-B62B-227EFA0579DF@univ-lille.fr> Dear all, We have an opening for a 3-year PhD position at University of Lille, France. The successful applicant will be funded -- including salary and (international) conference travel -- through a new French-German ANR-funded project. There will also be an opportunity to collaborate with a research team in Japan. Lille is at the heart of Europe: 45 minutes from Bruxelles, 1 hour from Paris, 1 hour and half from London. This is an important university hub that hosts the annual International Cybersecurity Forum (FIC). The start date is September 1st, but might possibly be postponed to October 1st. The PhD position is about the formal proof in Coq for shallow-embedded imperative programs and their compilation into C (more details below). Interested students should meet the following requirements: - Be interested by the topic of the PhD :-) - Have or be about to complete a Master in Computer Science or a related field (Logic, Mathematics, etc.). If you are interested in applying for this opportunity please begin by contacting us {gilles.grimaud,samuel.hym,david.nowak}@univ-lille.fr as soon as possible with the following information: - CV/Resume - A brief introduction of yourself, your scientific interests, and if you are familiar with any of the following topics: * formal proof / formal verification, * functional programming * monads * semantics ——————————————————————————————————— Summary: The topic of this PhD offer is the formal proof in Coq for shallow-embedded imperative programs and their compilation into C. More precisely, the objective is to conceive and develop formal tools to simplify code writing and proof of system software for low-end devices. Context: The Coq proof assistant [1] allows to prove properties of programs. Its language, called Gallina, is purely functional. In the Pip project [2], we have considered a monadic subset of C-like Gallina enough to formally write an OS kernel. Objectives: A first objective of this PhD is to extend the monadic subset in order to include further imperative features (such as loops, references or exceptions) that will simplify code writing and proof of system software for low-end devices. For security properties the monadic Hoare logic used for Pip will have to be extended to deal with the new imperative features. For functional properties, there are two possible directions: either use the monadic Hoare logic or monadic equational reasoning as developed in Monae [3]. The relation with FreeSpec [4] should also be investigated. A second objective is to automatically translate programs written in this monadic subset into an AST of the CompCert C verified compiler [5] and to prove formally that this translation is correct, in the sense that properties proved on the monadic subset are also true of the generated C code. [1] https://coq.inria.fr [2] http://pip.univ-lille1.fr [3] https://github.com/affeldt-aist/monae [4] https://github.com/lthms/FreeSpec [5] https://compcert.org ——————————————————————————————————— All the best, -- Gilles Grimaud, Samuel Hym, David Nowak -------------- next part -------------- An HTML attachment was scrubbed... URL: From leah at vuxu.org Fri May 28 17:37:22 2021 From: leah at vuxu.org (Leah Neukirchen) Date: Fri, 28 May 2021 19:37:22 +0200 Subject: [Haskell-cafe] Munich Virtual Haskell Meeting, 2021-05-31 @ 19:30 Message-ID: <87wnri7oa5.fsf@vuxu.org> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 31 on Google Meet at 19:30 CEST. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Google Meet 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 jonathan.protzenko at gmail.com Fri May 28 19:06:45 2021 From: jonathan.protzenko at gmail.com (Jonathan Protzenko) Date: Fri, 28 May 2021 12:06:45 -0700 Subject: [Haskell-cafe] ML Family Workshop 2021: deadline extension Message-ID: The deadline for the ML family workshop has been extended by a week. If you were on the fence, please submit! --- 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. The ML family workshop warmly welcomes submission touching on the programming languages traditionally seen as part of the "ML family" (Standard ML, OCaml, F#, CakeML, SML#, Manticore, MetaOCaml, etc.). The scope of the workshop includes all aspects of the design, semantics, theory, application, implementation, and teaching of the members of the ML family. We also encourage presentations from related languages (such as Haskell, Scala, Rust, Nemerle, Links, Koka, F*, Eff, ATS, etc), to exchange experience of further developing ML ideas. ## Submission details Submissions must be at most three pages long; see the full call for papers for details. Submission site: https://ml21.hotcrp.com/ ## Important dates Thu, Jun 3th 2021 (AoE): submission deadline Thu, Jun 24th 2021 (AoE): author notification Thu, Aug 26th: workshop (time slots TBD) ## 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 tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat May 29 10:09:13 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 29 May 2021 11:09:13 +0100 Subject: [Haskell-cafe] Request for Haskell wiki editing account In-Reply-To: References: Message-ID: <20210529100913.GE27384@cloudinit-builder> On Sun, May 23, 2021 at 10:17:52AM +0900, Michael Turner wrote: > I've been a contributor to Wikipedia for a long time > > https://en.wikipedia.org/wiki/Special:Contributions/Yakushima > > and I'm a Haskell newbie. As I run across problems in getting started, > I'd like to improve the Haskell wiki so that others can avoid similar > problems. > > Requested username for Haskell Wiki: Yakushima Hello Michael, did you get any response to this? If not then please let me know and I will try to chase it up for you. Tom From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Sat May 29 10:11:00 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 29 May 2021 11:11:00 +0100 Subject: [Haskell-cafe] Request for Haskell wiki editing account In-Reply-To: <20210529100913.GE27384@cloudinit-builder> References: <20210529100913.GE27384@cloudinit-builder> Message-ID: <20210529101100.GF27384@cloudinit-builder> On Sat, May 29, 2021 at 11:09:13AM +0100, Tom Ellis wrote: > On Sun, May 23, 2021 at 10:17:52AM +0900, Michael Turner wrote: > > I've been a contributor to Wikipedia for a long time > > > > https://en.wikipedia.org/wiki/Special:Contributions/Yakushima > > > > and I'm a Haskell newbie. As I run across problems in getting started, > > I'd like to improve the Haskell wiki so that others can avoid similar > > problems. > > > > Requested username for Haskell Wiki: Yakushima > > Hello Michael, did you get any response to this? If not then please > let me know and I will try to chase it up for you. Oh, and can you confirm that you have tried emailing the "wiki-account-request" address shown on https://wiki.haskell.org/Special:UserLogin (I guess you have, which is why you ended up here) From vamchale at gmail.com Sat May 29 13:08:16 2021 From: vamchale at gmail.com (Vanessa McHale) Date: Sat, 29 May 2021 09:08:16 -0400 Subject: [Haskell-cafe] Is there some tool for inferring wide dependency ranges? In-Reply-To: <1622158046.98439665@f401.i.mail.ru> References: <1622158046.98439665@f401.i.mail.ru> Message-ID: There’s the ‘cabal outdated’ command, which does some of what you might want? At least, it will notify you when new stuff comes out…. > On May 27, 2021, at 7:32 PM, Askar Safin via Haskell-Cafe wrote: > > Oleg Grenrus, thanks a lot! > > == > Askar Safin > http://safinaskar.com > https://sr.ht/~safinaskar > https://github.com/safinaskar > _______________________________________________ > 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 mlang at blind.guru Sat May 29 14:59:58 2021 From: mlang at blind.guru (Mario Lang) Date: Sat, 29 May 2021 16:59:58 +0200 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? Message-ID: <87y2bxoaa9.fsf@blind.guru> Hi. For my chessIO package, I wrote a module to communicate with UCI (Universal Chess Interface) speaking chess engines. This sort of thing is pretty new to me. I settled to use attoparsec for parsing and TChan to feed incoming data to the library users. This is the first thing that I found which looked like it could work... I would be thrilled if someone with more experience in this area would give my approach a review. Let me know if something is glaringly unidiomatic, I am sure you will find things. https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs This is for me to learn, and to avoid putting weird stuff on hackage... I actually prefer private mail, but a GitHub issue or even a PR are also highly welcome. Thanks. -- CYa, ⡍⠁⠗⠊⠕ From oleg.grenrus at iki.fi Sat May 29 15:21:29 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Sat, 29 May 2021 18:21:29 +0300 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <87y2bxoaa9.fsf@blind.guru> References: <87y2bxoaa9.fsf@blind.guru> Message-ID: I wrote https://github.com/phadej/cabal-extras/blob/master/cabal-docspec/src/System/Process/Interactive.hs learning from what doctest, hlint and few other tools do. They all (and you) seem to combine the process handling with the specific process, coupling things which don't need to be. That repository is under GPL, but if you find that module useful I can relicense it. - Oleg On 29.5.2021 17.59, Mario Lang wrote: > Hi. > > For my chessIO package, I wrote a module to communicate with > UCI (Universal Chess Interface) speaking chess engines. > > This sort of thing is pretty new to me. > I settled to use attoparsec for parsing and > TChan to feed incoming data to the library users. > This is the first thing that I found which looked like it could work... > > I would be thrilled if someone with more experience in this area would > give my approach a review. Let me know if something is glaringly > unidiomatic, I am sure you will find things. > > https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs > > This is for me to learn, and to avoid putting weird stuff on hackage... > I actually prefer private mail, but a GitHub issue or even a PR are also > highly welcome. > > Thanks. > From michael.eugene.turner at gmail.com Sun May 30 12:40:50 2021 From: michael.eugene.turner at gmail.com (Michael Turner) Date: Sun, 30 May 2021 21:40:50 +0900 Subject: [Haskell-cafe] Request for Haskell wiki editing account In-Reply-To: <20210529101100.GF27384@cloudinit-builder> References: <20210529100913.GE27384@cloudinit-builder> <20210529101100.GF27384@cloudinit-builder> Message-ID: I'm good here, thanks. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner at projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry On Sat, May 29, 2021 at 7:11 PM Tom Ellis wrote: > > On Sat, May 29, 2021 at 11:09:13AM +0100, Tom Ellis wrote: > > On Sun, May 23, 2021 at 10:17:52AM +0900, Michael Turner wrote: > > > I've been a contributor to Wikipedia for a long time > > > > > > https://en.wikipedia.org/wiki/Special:Contributions/Yakushima > > > > > > and I'm a Haskell newbie. As I run across problems in getting started, > > > I'd like to improve the Haskell wiki so that others can avoid similar > > > problems. > > > > > > Requested username for Haskell Wiki: Yakushima > > > > Hello Michael, did you get any response to this? If not then please > > let me know and I will try to chase it up for you. > > Oh, and can you confirm that you have tried emailing the > "wiki-account-request" address shown on https://wiki.haskell.org/Special:UserLogin > > (I guess you have, which is why you ended up here) From safinaskar at mail.ru Mon May 31 00:21:50 2021 From: safinaskar at mail.ru (=?UTF-8?B?QXNrYXIgU2FmaW4=?=) Date: Mon, 31 May 2021 03:21:50 +0300 Subject: [Haskell-cafe] =?utf-8?q?Is_there_some_tool_for_inferring_wide_de?= =?utf-8?q?pendency_ranges=3F?= In-Reply-To: References: <1622158046.98439665@f401.i.mail.ru> Message-ID: <1622420510.193934194@f423.i.mail.ru> Hi, Oleg Grenrus and everybody. I solved my problem. I. e. I wrote the second tool from this letter: https://mail.haskell.org/pipermail/haskell-cafe/2021-May/134018.html . Result is in commit https://git.sr.ht/~safinaskar/check-cfg-ambiguity/commit/2ef843a42e51848608fc7156b1b70b1b691fba3a (it is possible that I will break everything in future commits, so here I refer to this particular commit). Here is fragment of my check-cfg-ambiguity.cabal: ---------------- library exposed-modules: CheckCFGAmbiguity -- base 4.13 removed Monad.fail, so "before base 4.13 there was nothing" build-depends: -- CI-BOUNDS-BEGIN base >= 4.13.0.0 && <= 4.15.0.0, containers >= 0.6.2.1 && <= 0.6.4.1 -- CI-BOUNDS-END default-language: Haskell2010 ---------------- My CI script .build.yml parses this cabal file using ad-hoc regexes and sed (markers "CI-BOUNDS-BEGIN" and "CI-BOUNDS-END" help here; well, I have shell/sed addiction, and shell/sed [not haskell!] are still more convenient to me for such tasks) and extracts version info from this cabal file. Thus I don't have to repeat version numbers in CI script, i. e. I don't have DRY violation. Then CI script uses this info to build and test my package two times: for lower versions (with corresponding ghc version!) and for higher versions. Here is resulting CI log: https://builds.sr.ht/~safinaskar/job/516259 . Also: it was hard to find proper way to integrate cabal and doctest. Internet is full of misleading information. For example, https://hackage.haskell.org/package/cabal-doctest says that this package will become obsolete when command "cabal doctest" arrives and gives link https://github.com/haskell/cabal/issues/2327 to track progress. Link https://github.com/haskell/cabal/issues/2327 says that "cabal doctest" is implemented, so it seems that cabal-doctest is really deprecated and one should use "cabal doctest". But both https://hackage.haskell.org/package/cabal-doctest and https://github.com/haskell/cabal/issues/2327 don't say that "cabal doctest" not only ADDED, but also REMOVED: https://github.com/haskell/cabal/pull/7167/ . (Well, they didn't say this until today.) After lots of searching internet I chose current approach, see lots of comments about this in check-cfg-ambiguity.cabal . Of course, all my heroic efforts would be useless, if I did this for single package. I plan to publish more packages, and thus I did all this research == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar From compl.yue at icloud.com Mon May 31 08:22:42 2021 From: compl.yue at icloud.com (YueCompl) Date: Mon, 31 May 2021 16:22:42 +0800 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <87y2bxoaa9.fsf@blind.guru> References: <87y2bxoaa9.fsf@blind.guru> Message-ID: <52B438A6-2551-4964-9AD4-7120288B3BD0@icloud.com> I suggest https://github.com/haskell/lsp should be considered the "most idiomatic" way to bridge Haskell domain code with external programs. It speaks JSON-RPC based LSP (https://microsoft.github.io/language-server-protocol ) with VSCode and other IDEs. > On 2021-05-29, at 22:59, Mario Lang wrote: > > Hi. > > For my chessIO package, I wrote a module to communicate with > UCI (Universal Chess Interface) speaking chess engines. > > This sort of thing is pretty new to me. > I settled to use attoparsec for parsing and > TChan to feed incoming data to the library users. > This is the first thing that I found which looked like it could work... > > I would be thrilled if someone with more experience in this area would > give my approach a review. Let me know if something is glaringly > unidiomatic, I am sure you will find things. > > https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs > > This is for me to learn, and to avoid putting weird stuff on hackage... > I actually prefer private mail, but a GitHub issue or even a PR are also > highly welcome. > > Thanks. > > -- > CYa, > ⡍⠁⠗⠊⠕ > _______________________________________________ > 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 May 31 08:40:45 2021 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Mon, 31 May 2021 11:40:45 +0300 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <52B438A6-2551-4964-9AD4-7120288B3BD0@icloud.com> References: <87y2bxoaa9.fsf@blind.guru> <52B438A6-2551-4964-9AD4-7120288B3BD0@icloud.com> Message-ID: LSP is not applicable. Please read about UCI, https://en.wikipedia.org/wiki/Universal_Chess_Interface. I.e. change of protocol is not possible. If you want to draw an analogy, then Mario's chessIO package is the editor here, and various chess engines are "plugins", therefore I don't think that lsp package is much help as it implements different role. - Oleg On 31.5.2021 11.22, YueCompl via Haskell-Cafe wrote: > I suggest https://github.com/haskell/lsp should be considered the > "most idiomatic" way to bridge Haskell domain code with external > programs. It speaks JSON-RPC based LSP > (https://microsoft.github.io/language-server-protocol) with VSCode and > other IDEs. > >> On 2021-05-29, at 22:59, Mario Lang > > wrote: >> >> Hi. >> >> For my chessIO package, I wrote a module to communicate with >> UCI (Universal Chess Interface) speaking chess engines. >> >> This sort of thing is pretty new to me. >> I settled to use attoparsec for parsing and >> TChan to feed incoming data to the library users. >> This is the first thing that I found which looked like it could work... >> >> I would be thrilled if someone with more experience in this area would >> give my approach a review.  Let me know if something is glaringly >> unidiomatic, I am sure you will find things. >> >> https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs >> >> This is for me to learn, and to avoid putting weird stuff on hackage... >> I actually prefer private mail, but a GitHub issue or even a PR are also >> highly welcome. >> >> Thanks. >> >> -- >> CYa, >>  ⡍⠁⠗⠊⠕ >> _______________________________________________ >> 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 compl.yue at icloud.com Mon May 31 08:55:18 2021 From: compl.yue at icloud.com (YueCompl) Date: Mon, 31 May 2021 16:55:18 +0800 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: References: <87y2bxoaa9.fsf@blind.guru> <52B438A6-2551-4964-9AD4-7120288B3BD0@icloud.com> Message-ID: <69E49E95-E091-430F-AE62-7A72FDDCC9FD@icloud.com> Ah yes, their roles are flipped. > On 2021-05-31, at 16:40, Oleg Grenrus wrote: > > LSP is not applicable. Please read about UCI, https://en.wikipedia.org/wiki/Universal_Chess_Interface . I.e. change of protocol is not possible. > > If you want to draw an analogy, then Mario's chessIO package is the editor here, and various chess engines are "plugins", > therefore I don't think that lsp package is much help as it implements different role. > > - Oleg > > On 31.5.2021 11.22, YueCompl via Haskell-Cafe wrote: >> I suggest https://github.com/haskell/lsp should be considered the "most idiomatic" way to bridge Haskell domain code with external programs. It speaks JSON-RPC based LSP (https://microsoft.github.io/language-server-protocol ) with VSCode and other IDEs. >> >>> On 2021-05-29, at 22:59, Mario Lang > wrote: >>> >>> Hi. >>> >>> For my chessIO package, I wrote a module to communicate with >>> UCI (Universal Chess Interface) speaking chess engines. >>> >>> This sort of thing is pretty new to me. >>> I settled to use attoparsec for parsing and >>> TChan to feed incoming data to the library users. >>> This is the first thing that I found which looked like it could work... >>> >>> I would be thrilled if someone with more experience in this area would >>> give my approach a review. Let me know if something is glaringly >>> unidiomatic, I am sure you will find things. >>> >>> https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs >>> >>> This is for me to learn, and to avoid putting weird stuff on hackage... >>> I actually prefer private mail, but a GitHub issue or even a PR are also >>> highly welcome. >>> >>> Thanks. >>> >>> -- >>> CYa, >>> ⡍⠁⠗⠊⠕ >>> _______________________________________________ >>> 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 mlang at blind.guru Mon May 31 15:31:39 2021 From: mlang at blind.guru (Mario Lang) Date: Mon, 31 May 2021 17:31:39 +0200 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <87czt7vyvk.tristanC@fedora> (Tristan Cacqueray's message of "Mon, 31 May 2021 13:03:43 +0000") References: <87y2bxoaa9.fsf@blind.guru> <87czt7vyvk.tristanC@fedora> Message-ID: <87im2y7wdg.fsf@blind.guru> Tristan Cacqueray writes: > On Sat, May 29, 2021 at 16:59 Mario Lang wrote: >> Hi. >> >> For my chessIO package, I wrote a module to communicate with >> UCI (Universal Chess Interface) speaking chess engines. >> >> This sort of thing is pretty new to me. >> I settled to use attoparsec for parsing and >> TChan to feed incoming data to the library users. >> This is the first thing that I found which looked like it could work... >> >> I would be thrilled if someone with more experience in this area would >> give my approach a review. Let me know if something is glaringly >> unidiomatic, I am sure you will find things. >> >> https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs >> > > It seems like it would be safer to use withCreateProcess instead of > createProcess to ensure the process is not left unattended. Maybe I am unimaginative, but it seems to me I can not use withCreateProcess as I need to read/write the Handles outside of the initialisation phase. It seems to me withCreateProcess would kill my external process once my initialisation function is done. Or do I misunderstand bracket somehow? AIUI, withCreateProcess always calls cleanupProcess once the action is done, right? >> This is for me to learn, and to avoid putting weird stuff on hackage... >> I actually prefer private mail, but a GitHub issue or even a PR are also >> highly welcome. >> > > I had the same need for a matrix bot where the events come from a ssh > process stream. There is `streaming-commons` and `conduit-extra`, but I > am not familiar enough with conduit to make it work. > > In the end I used `turtle` to callback with each line output. > For what it worths, here is my current implementation: > > https://github.com/softwarefactory-project/gerritbot-matrix/blob/71644a21a9ac942bb5b2819208cc0b949e02b084/src/Gerritbot.hs#L24 Thanks. The output of my subprocess is also line-based, so I use ByteString.hGetLine and a call into attoparsec to make sense of the output I receive. Works so far. -- CYa, ⡍⠁⠗⠊⠕ From tdecacqu at redhat.com Mon May 31 15:56:03 2021 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 31 May 2021 15:56:03 +0000 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <87im2y7wdg.fsf@blind.guru> References: <87y2bxoaa9.fsf@blind.guru> <87czt7vyvk.tristanC@fedora> <87im2y7wdg.fsf@blind.guru> Message-ID: <877djex5gs.tristanC@fedora> On Mon, May 31, 2021 at 17:31 Mario Lang wrote: > Tristan Cacqueray writes: > >> On Sat, May 29, 2021 at 16:59 Mario Lang wrote: >>> Hi. >>> >>> For my chessIO package, I wrote a module to communicate with >>> UCI (Universal Chess Interface) speaking chess engines. >>> >>> This sort of thing is pretty new to me. >>> I settled to use attoparsec for parsing and >>> TChan to feed incoming data to the library users. >>> This is the first thing that I found which looked like it could work... >>> >>> I would be thrilled if someone with more experience in this area would >>> give my approach a review. Let me know if something is glaringly >>> unidiomatic, I am sure you will find things. >>> >>> https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs >>> >> >> It seems like it would be safer to use withCreateProcess instead of >> createProcess to ensure the process is not left unattended. > > Maybe I am unimaginative, but it seems to me I can not use > withCreateProcess as I need to read/write the Handles outside of the > initialisation phase. It seems to me withCreateProcess would kill my > external process once my initialisation function is done. > Or do I misunderstand bracket somehow? > AIUI, withCreateProcess always calls cleanupProcess once the action is > done, right? > I guess you would have to replace `start'` with something like: ```haskell withEngine :: Time unit -> ... -> (Engine -> IO ()) -> IO () ``` And let your user provide the `Engine -> IO ()` callback. Alternatively, perhaps the `managed` library can be used to get something closer to your existing `start'`, e.g.: http://hackage.haskell.org/package/managed-1.0.8/docs/Control-Monad-Managed.html >>> This is for me to learn, and to avoid putting weird stuff on hackage... >>> I actually prefer private mail, but a GitHub issue or even a PR are also >>> highly welcome. >>> >> >> I had the same need for a matrix bot where the events come from a ssh >> process stream. There is `streaming-commons` and `conduit-extra`, but I >> am not familiar enough with conduit to make it work. >> >> In the end I used `turtle` to callback with each line output. >> For what it worths, here is my current implementation: >> >> https://github.com/softwarefactory-project/gerritbot-matrix/blob/71644a21a9ac942bb5b2819208cc0b949e02b084/src/Gerritbot.hs#L24 > > Thanks. The output of my subprocess is also line-based, so I use > ByteString.hGetLine and a call into attoparsec to make sense of the > output I receive. Works so far. > You're welcome. Perhaps such line-based process wrapper could be a useful addition to the hackage registry? Note that I also tried to convert the Turtle.inproc Shell to a `pipes` or `streaming`, but without success. -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From borgauf at gmail.com Mon May 31 16:39:39 2021 From: borgauf at gmail.com (Galaxy Being) Date: Mon, 31 May 2021 11:39:39 -0500 Subject: [Haskell-cafe] bottom/unconditionally false in Haskell Message-ID: I just ran into this formula head = foldr (<<) ⊥ where x << y = x in Bird and Gibbons' *Algorithm Design with Haskell* and I understand it's a sort of pseudo-code. Intuitively, I understand that foldr will take "bottom" as its "starter seed", but I don't know how to convert the << into Haskell code. This works myHead = foldr choose1st undefined where choose1st x y = x but I can't get myHead2 = foldr (<<) undefined where << x y = x to work. How do you create a non-alphanumeric operator like < From allbery.b at gmail.com Mon May 31 16:42:46 2021 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 31 May 2021 12:42:46 -0400 Subject: [Haskell-cafe] bottom/unconditionally false in Haskell In-Reply-To: References: Message-ID: The way it was written (infix), or wrap the operator in parentheses. On Mon, May 31, 2021 at 12:40 PM Galaxy Being wrote: > I just ran into this formula > > head = foldr (<<) ⊥ where x << y = x > > in Bird and Gibbons' *Algorithm Design with Haskell* and I understand > it's a sort of pseudo-code. Intuitively, I understand that foldr will > take "bottom" as its "starter seed", but I don't know how to convert the << > into Haskell code. This works > > myHead = foldr choose1st undefined where choose1st x y = x > > but I can't get > > myHead2 = foldr (<<) undefined where << x y = x > > to work. How do you create a non-alphanumeric operator like < > -- > ⨽ > 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. -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk Mon May 31 16:43:52 2021 From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 31 May 2021 17:43:52 +0100 Subject: [Haskell-cafe] bottom/unconditionally false in Haskell In-Reply-To: References: Message-ID: <20210531164352.GI27384@cloudinit-builder> On Mon, May 31, 2021 at 11:39:39AM -0500, Galaxy Being wrote: > I just ran into this formula > > head = foldr (<<) ⊥ where x << y = x > > I understand it's a sort of pseudo-code It's less "pseudo" than you think! This works: head = foldr (<<) undefined where x << y = x From mlang at blind.guru Mon May 31 17:03:50 2021 From: mlang at blind.guru (Mario Lang) Date: Mon, 31 May 2021 19:03:50 +0200 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <877djex5gs.tristanC@fedora> (Tristan Cacqueray's message of "Mon, 31 May 2021 15:56:03 +0000") References: <87y2bxoaa9.fsf@blind.guru> <87czt7vyvk.tristanC@fedora> <87im2y7wdg.fsf@blind.guru> <877djex5gs.tristanC@fedora> Message-ID: <87czt67s3t.fsf@blind.guru> Tristan Cacqueray writes: > On Mon, May 31, 2021 at 17:31 Mario Lang wrote: >> Tristan Cacqueray writes: >>> >>> It seems like it would be safer to use withCreateProcess instead of >>> createProcess to ensure the process is not left unattended. >> >> Maybe I am unimaginative, but it seems to me I can not use >> withCreateProcess as I need to read/write the Handles outside of the >> initialisation phase. It seems to me withCreateProcess would kill my >> external process once my initialisation function is done. >> Or do I misunderstand bracket somehow? >> AIUI, withCreateProcess always calls cleanupProcess once the action is >> done, right? >> > > I guess you would have to replace `start'` with something like: > > ```haskell > withEngine :: Time unit -> ... -> (Engine -> IO ()) -> IO () > ``` > > And let your user provide the `Engine -> IO ()` callback. Ahh, of course, push the problem up the caller chain :-) And I guess if that caller needs a sort of handle, it would do it with a channel to communicate with its action? I know I was asking for idiomatic code, and I am thankful for the pointer. Exception safety is clearly a good goal. But, I wonder, is limiting the API in such a way worth the trouble? It looks like this change would trigger a complete rewrite of the current module and all its clients. I'd like to be confident this is the right thing to do before doing that. > Alternatively, perhaps the `managed` library can be used to get > something closer to your existing `start'`, e.g.: > http://hackage.haskell.org/package/managed-1.0.8/docs/Control-Monad-Managed.html Ahh, thanks again. I'll have to digest all of this. -- CYa, ⡍⠁⠗⠊⠕ From tdecacqu at redhat.com Mon May 31 13:03:43 2021 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 31 May 2021 13:03:43 +0000 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <87y2bxoaa9.fsf@blind.guru> References: <87y2bxoaa9.fsf@blind.guru> Message-ID: <87czt7vyvk.tristanC@fedora> On Sat, May 29, 2021 at 16:59 Mario Lang wrote: > Hi. > > For my chessIO package, I wrote a module to communicate with > UCI (Universal Chess Interface) speaking chess engines. > > This sort of thing is pretty new to me. > I settled to use attoparsec for parsing and > TChan to feed incoming data to the library users. > This is the first thing that I found which looked like it could work... > > I would be thrilled if someone with more experience in this area would > give my approach a review. Let me know if something is glaringly > unidiomatic, I am sure you will find things. > > https://github.com/mlang/chessIO/blob/master/src/Game/Chess/UCI.hs > It seems like it would be safer to use withCreateProcess instead of createProcess to ensure the process is not left unattended. > This is for me to learn, and to avoid putting weird stuff on hackage... > I actually prefer private mail, but a GitHub issue or even a PR are also > highly welcome. > I had the same need for a matrix bot where the events come from a ssh process stream. There is `streaming-commons` and `conduit-extra`, but I am not familiar enough with conduit to make it work. In the end I used `turtle` to callback with each line output. For what it worths, here is my current implementation: https://github.com/softwarefactory-project/gerritbot-matrix/blob/71644a21a9ac942bb5b2819208cc0b949e02b084/src/Gerritbot.hs#L24 -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: From tdecacqu at redhat.com Mon May 31 18:08:47 2021 From: tdecacqu at redhat.com (Tristan Cacqueray) Date: Mon, 31 May 2021 18:08:47 +0000 Subject: [Haskell-cafe] Wrapping external process communication in a nice API? In-Reply-To: <87czt67s3t.fsf@blind.guru> References: <87y2bxoaa9.fsf@blind.guru> <87czt7vyvk.tristanC@fedora> <87im2y7wdg.fsf@blind.guru> <877djex5gs.tristanC@fedora> <87czt67s3t.fsf@blind.guru> Message-ID: <871r9mn5cg.tristanC@fedora> On Mon, May 31, 2021 at 19:03 Mario Lang wrote: > Tristan Cacqueray writes: > >> On Mon, May 31, 2021 at 17:31 Mario Lang wrote: >>> Tristan Cacqueray writes: >>>> >>>> It seems like it would be safer to use withCreateProcess instead of >>>> createProcess to ensure the process is not left unattended. >>> >>> Maybe I am unimaginative, but it seems to me I can not use >>> withCreateProcess as I need to read/write the Handles outside of the >>> initialisation phase. It seems to me withCreateProcess would kill my >>> external process once my initialisation function is done. >>> Or do I misunderstand bracket somehow? >>> AIUI, withCreateProcess always calls cleanupProcess once the action is >>> done, right? >>> >> >> I guess you would have to replace `start'` with something like: >> >> ```haskell >> withEngine :: Time unit -> ... -> (Engine -> IO ()) -> IO () >> ``` >> >> And let your user provide the `Engine -> IO ()` callback. > > Ahh, of course, push the problem up the caller chain :-) > And I guess if that caller needs a sort of handle, it would do it with a > channel to communicate with its action? > I know I was asking for idiomatic code, and I am thankful for > the pointer. Exception safety is clearly a good goal. But, I wonder, is > limiting the API in such a way worth the trouble? > It looks like this change would trigger a complete rewrite of > the current module and all its clients. > I'd like to be confident this is the right thing to do before doing that. > Beware I'm in the same boat and I can't tell if this is the right thing to do :-) I like the with... idiom because it is straighforward and it should not limit the API, users just need to provide a callback instead of binding to get the resource. Though it is more tedious to use from a REPL, where you need to prefix each input with `withEngine ... $ \engine -> ...` >> Alternatively, perhaps the `managed` library can be used to get >> something closer to your existing `start'`, e.g.: >> http://hackage.haskell.org/package/managed-1.0.8/docs/Control-Monad-Managed.html > > Ahh, thanks again. I'll have to digest all of this. > Cheers, -Tristan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 515 bytes Desc: not available URL: