- Haskell-Cafe - Haskell.org

Different advice for type classes for end-user app and libraries?
by Ruben Astudillo 12 Aug '21

12 Aug '21

Hello list! Currently I am working a end user application. Through the years I had incorporated the advice from r/haskell that classes without laws were not desirable. Their lack meant that we didn't have a contract boundary that should be respected by the instances. They secretly could `throw exc` on their implementation and you wouldn't notice. But on the current app I am working on, I follow the advice from this blogpost [1] that I should use classes for domain modelling. This manifest on classes like class UserQueryCapability f where getUser :: Id -> f User for interacting with a DB. Functions can be written against the interface and I can mock up with QuickCheck some pretty broad cases. The classes usually don't have a superclass constrain on `Monad` as in `MonadReader` because I *cannot* establish a law relating the monadic behavior and `getUser`. The name has Capability in it and not Monad because I won't lie that way. Making sure that these effect classes are orthogonal is something I have to check by hand. But in the back of my head there is the concern about the lack of laws could bite me even on a end user-app. Is my intuition well founded that this case is OK? Thanks for your time! [1]: https://www.parsonsmatt.org/2018/03/22/three_layer_haskell_cake.html -- -- Rubén. pgp: 4EE9 28F7 932E F4AD

2 1

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by YueCompl 12 Aug '21

12 Aug '21

Thanks Michał, I feel less confused as I realized the non-halting possibility per bottoms, from your hint. I too think the signaling NaN is dreadful enough, so fortunately it's rarely seen nowadays. Actually what's on my mind was roughly something like "Maybe on steroids", I'm aware that NaN semantics breaks `Num` (or descendants) laws, as seen at https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs <https://gitlab.haskell.org/ghc/ghc/-/blob/master/libraries/base/GHC/Float.hs> > Note that due to the presence of @NaN@, not all elements of 'Float' have an additive inverse. > Also note that due to the presence of -0, Float's 'Num' instance doesn't have an additive identity > Note that due to the presence of @NaN@, not all elements of 'Float' have an multiplicative inverse. So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? No such family of `Num` classes exists to my aware by now, I just can't help wondering why. Cheers, Compl > On 2021-08-04, at 02:38, Michał J Gajda <mjgajda(a)gmail.com> wrote: > > Dear Yue, > > Bottom has much weaker semantics than an exception: it means You may never get a result and thus will never handle it! > > Another reason is convenience: it is frequently the case that giving NaN in a row of numbers is much more informative than crashing a program with an exception and never printing the result anyway. > > Finally IEEE special values have clear propagation semantics: they are basically Maybe on steroids. > > The problem with this approach is indeed a silent handling. > > But in order to fix this, it is better to add preconditions to specific algorithms that do not allow IEEE special value on input (`isFinite` or `isNotNaN`) and then track the origin of the special value with the methods like those described here: https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-i… <https://skillsmatter.com/skillscasts/14905-agile-functional-data-pipeline-i…> > > Never throw an error without telling exactly why it happened and exactly where to fix it :-). Using bottom is last resort; exceptions likewise. > -- > Cheers > Michał

4 10

Call for participation: ML Family Workshop 2021
by Jonathan Protzenko 11 Aug '21

11 Aug '21

We are happy to announce that the ML Family Workshop is back for its 2021 edition, which we will be held online on Thursday August 26th, in conjunction with ICFP 2021. We invite you to subscribe to, and attend the workshop, in addition to the main ICFP conference. We are thrilled to announce that Don Syme will give this year's keynote: "Narratives and Lessons from The Early History of F#". Please join us! The program features 14 exciting submissions, including 4 short talks. The workshop will be held online in the 6pm-3am time band (Seoul Time). Talks will be pre-recorded and uploaded online for those who cannot attend. * Program: https://icfp21.sigplan.org/home/mlfamilyworkshop-2021#program * Keynote: https://icfp21.sigplan.org/details/mlfamilyworkshop-2021-papers/15/Keynote-… * ICFP home: http://icfp21.sigplan.org/home ## Program committee Danel Ahman (University of Ljubljana) Robert Atkey (University of Strathclyde) Frédéric Bour (Tarides) Ezgi Çiçek (Facebook London) Youyou Cong (Tokyo Institute of Technology) Richard A. Eisenberg (Tweag I/O) Martin Elsman (University of Copenhagen, Denmark) Ohad Kammar (University of Edinburgh) Naoki Kobayashi (University of Tokyo, Japan) Benoît Montagu (Inria) Jonathan Protzenko (Microsoft Research) (Chair) Kristina Sojakova (INRIA Paris) Don Syme (Microsoft) Matías Toro (University of Chile) Katsuhiro Ueno (Tohoku University)

1 0

Re: [Haskell-cafe] Help on syntactic sugar for combining lazy & strict monads?
by Olaf Klinke 10 Aug '21

10 Aug '21

> However, a lazy interpreter causes problems when trying to introduce > *observation* statements (aka conditioning statements) into the monad > [3]. For example, > > run_lazy $ do > x <- normal 0 1 > y <- normal x 1 > z <- normal y 1 > 2.0 `observe_from` normal z 1 > return y > > In the above code fragment, y will be forced because it is returned, and > y will force x. However, the "observe_from" statement will never be > forced, because it does not produce a result that is demanded. I'm very confused. If the observe_from statement is never demanded, then what semantics should it have? What is the type of observe_from? It seems it is a -> m a -> m () for whatever monad m you are using. But conditioning usually is a function Observation a -> Dist a -> Dist a so you must use the result of the conditioning somehow. And isn't the principle of Monte Carlo to approximate the posterior by sampling from it? I tend to agree with your suggestion that observations and sampling can not be mixed (in the same do-notation) but the latter have to be collected in a prior, then conditioned by an observation. What is the semantic connection between your sample and obsersvation monad? What is the connection between both and the semantic probability distributions? I claim that once you have typed everything, it becomes clear where the problem is. Olaf P.S. It has always bugged me that probabilists use elements and events interchangingly, while this can only be done on discrete spaces. So above I would rather like to write (2.0==) `observe_from` (normal 0 1) which still is a non-sensical statement if (normal 0 1) is a continuous distribution where each point set has probability zero.

2 4

Re: [Haskell-cafe] Organizing your code files
by Johannes Waldmann 10 Aug '21

10 Aug '21

Hécate: > * Type variables are made explicit, and as such I annotate even the > simplest of them (with `:: Type`) This! I am moving towards that style. Especially in teaching (type abstraction, type application) where I want everything to be very much explicit - before discussing abbreviations and omissions (type inference). With current GHC, this is entirely possible but looks somewhat clumsy {-# language ExplicitForall, KindSignatures #-} import Data.Kind (Type) g :: forall (t :: Type) . t -> t ; g x = x {-# language TypeApplications #-} g @N Z yes I could hide these pragmas somewhere but that again feels wrong. But - good thing: after https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-… (I understand that GHC2021 is default-enabled in GHC-9.2) we no longer need to write these pragmas. Yay! Sadly, we still need the import. - J. NB: Haskell's implicit declaration of type variables by their starting with lowercase letters always reminds me of Fortran's implicit type specification for variables, going by the first letter (I .. N means integer). Fortran has "implicit none" though, so let's have "t :: Type"...

1 0

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by Olaf Klinke 09 Aug '21

09 Aug '21

> * libraries assume a naive equality works for all types. Holds in a world > of infinte precision and lossless operations, but never holds for > approximations. > > * our propagation of universal error values is incomplete, and usually > missing from complex algorithms. In other words `Either String` Monad does > not work: we want collections of error values just like we have collections > of inputs. > > Personally I will be overjoyed when our community finally gets the better > type class library for approximated types. > > Would You agree to review a teaser if I post it here? Yes, please. I'm curious whether there is a single abstraction that can describe both finite precision with variable errors as well as potentially infinite precision with known errors. Olaf

1 0

Re: [Haskell-cafe] Why not some subclass of Floating to model NaNs as some handleable bottom?
by Olaf Klinke 09 Aug '21

09 Aug '21

> So it should have been another family of `Num` classes, within which, various NaN related semantics can be legal, amongst which I'd think: > > * Silent propagation of NaN in arithmetics, like `Maybe` monad does, seems quite acceptable > * Identity test, namely `NaN` /= `NaN` - this lacks theoretical ground or not? > * Comparison, neither `NaN` > 1 nor `NaN` <= 1 - whether or not there's a theoretical framework for this to hold? Maybe `Boolean` type needs enhancement too to do it? > > No such family of `Num` classes exists to my aware by now, I just can't help wondering why. > > Cheers, > Compl > I like to think of NaN as a glimpse of interval arithmetic. NaN is the interval -infintity to infinity [*]. When ordering intervals by reverse inclusion, NaN is indeed the bottom of the domain. For a general (closed) interval [x,y], how would you answer the questions [x,y] < [1,1]? [x,y] /= [1,1]? There are several possibilities known, extending relations on points to relations on sets. See Smyth-, Hoare- and Egli-Milner lifting of relations. So a more descriptive type of Float-ordering may be (<) :: Float -> Float -> RelationLifting -> Bool For example, NaN /= NaN under all three relation liftings mentioned above, but also NaN == NaN, so a /= b = not (a == b) does not hold anymore. > If we take this into consideration, we notice that most interesting > computations occur on collections of values, and thus yield a > collection of results, not just a single output. Indeed, one route to real arithmetic is via limits of collections of approximants. For example, consider a dense set of rationals, excluding zero, where that all arithmetic operations are well-defined and total on the approximants. Then express a real number as (Dedekind-)cuts and see what cut operations like 0/0 result in. Each non-proper cut corresponds to a special Float value. Incidentally, this is how Conway constructed his surreal numbers that also contain values like infinity and -0. I'm in favour that there be two floating-point types: One IEEE- compliant that behaves just like in other languages, and one more lawful one (thereby with fewer class instances) that leverages the expressive power of Haskell. Ho matter how broken, the former should be the default unless we want to alienate numerically inclined Haskell adopters. Olaf [*] The mathematical function \(x,y) -> x/y attains every real value arbitrarily close to (0,0), whence NaN = 0/0 should be interpreted as the interval encompassing the real line. Likewise log(0) for complex 0.

2 7

Call for Workshops - FLoC 2022
by Victor Perez 06 Aug '21

06 Aug '21

Second Call for Workshops- FLoC 2022 — The 2022 Federated Logic Conference July 31 - August 12, 2022 Haifa, Israel http://www.floc2022.org/ CALL FOR WORKSHOPS The Eighth Federated Logic Conference (FLoC 2022) will host the following ten conferences and affiliated workshops. LICS (37th Annual ACM/IEEE Symposium on Logic in Computer Science) http://lics.rwth-aachen.de/ Workshop chair: Frederic Blanqui Frederic.Blanqui(a)inria.fr FSCD (7th International Conference on Formal Structures for Computation and Deduction) http://fscd-conference.org/ Workshop chair: Nachum Dershowitz nachumd(a)tau.ac.il ITP (13th International Conference on Interactive Theorem Proving) https://itp-conference.github.io/ Workshop chair: Cyril Cohen cyril.cohen(a)inria.fr IJCAR (International Joint Conference on Automated Reasoning) http://www.ijcar.org Workshop chairs: Simon Robillard simon.robillard(a)imt-atlantique.fr Sophie Tourret stourret(a)mpi-inf.mpg.de CSF (35th IEEE Computer Security Foundations Symposium) http://www.ieee-security.org/CSFWweb/ Workshop chair: Musard Balliu musard(a)kth.se CAV (34th International Conference on Computer Aided Verification) http://i-cav.org/ Workshop chair: TBD KR (19th International Conference on Principles of Knowledge Representation and Reasoning) http://www.kr.org/ Workshop chair: Stefan Borgwardt stefan.borgwardt(a)tu-dresden.de ICLP (38th International Conference on Logic Programming) https://www.cs.nmsu.edu/ALP/conferences/ Workshop chair: Daniela Inclezan inclezd(a)miamioh.edu SAT (25th International Conference on Theory and Applications of Satisfiability Testing) http://www.satisfiability.org Workshop chair: Alexander Nadel alexander.nadel(a)intel.com CP (25th International Conference on Principles and Practice of Constraint Programming) http://a4cp.org/events/cp-conference-series Workshop chair: TBD SUBMISSION OF WORKSHOP PROPOSALS Researchers and practitioners are invited to submit proposals for workshops on topics in the field of computer science, related to logic in the broad sense. Each workshop proposal must indicate one affiliated conference of FLoC 2022. It is strongly suggested that prospective workshop organizers contact the relevant conference workshop chair before submitting a proposal. Each proposal should consist of the following two parts. 1) A short scientific justification of the proposed topic, its significance, and the particular benefits of the workshop to the community, as well as a list of previous or related workshops (if relevant). 2) An organisational part including: - contact information for the workshop organizers; - proposed affiliated conference; - estimate of the number of workshop participants (please note that small workshops, i.e., of less than ~13 participants, will likely be cancelled or merged); - proposed format and agenda (e.g. paper presentations, tutorials, demo sessions, etc.); - potential invited speakers (note that expenses of workshop invited speakers are not covered by FLoC); - procedures for selecting papers and participants; - plans for dissemination, if any (e.g. a journal special issue); - duration (which may vary from one day to two days); - preferred period (pre or post FLoC); - virtual/hybrid backup plans (including platform preference). The FLoC Organizing Committee will determine the final list of accepted workshops based on the recommendations from the Workshop Chairs of the hosting conferences and availability of space and facilities. Proposals should be submitted through EasyChair: https://easychair.org/conferences/?conf=floc2022workshops Please see the Workshop Guidelines page: https://floc2022.org/workshops/ for further details and FAQ. IMPORTANT DATES Submission of workshop proposals deadline: September 27, 2021 (note extended deadline) Notification: November 1, 2021 Pre-FLoC workshops: Sunday & Monday, July 31–August 1, 2022 (note corrected dates) Post-FLoC workshops: Thursday & Friday, August 11-12, 2022 CONTACT INFORMATION Questions regarding proposals should be sent to the workshop chairs of the proposed affiliated conference. General questions should be sent to: shaull(a)technion.ac.il GuillermoAlberto.Perez(a)uantwerpen.be FLoC 2022 WORKSHOP CHAIRS Shaull Almagor Guillermo A. Perez

1 0

Call for Lightning Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 06 Aug '21

06 Aug '21

Call for Lightning Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ Important dates --------------- Deadline: Thursday, 19 Aug, 2021 (or when slots are full, whichever is sooner) Workshop: Sunday, 22 Aug, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. We will have a number of slots for lightning talks. Lightning talks will be ~7 minutes and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Lightning talks are proposed by submitting a title and an abstract. Submissions will not be part of the peer-review process. Notification of acceptance will be continuous until slots are full. Submissions should be made via Google form: https://forms.gle/BmUSyWWTXt1AMTec8 Accepted lightning talks will be posted on the workshop’s website. Scope and target audience ------------------------- The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Contact ------- * Ningning Xie <xnningxie(a)gmail.com>

1 0

Call for Participation: ICFP 2021
by Sam Tobin-Hochstadt 06 Aug '21

06 Aug '21

===================================================================== Call for Participation ICFP 2021 26th ACM SIGPLAN International Conference on Functional Programming and affiliated events August 22 - August 27, 2021 Online http://icfp21.sigplan.org/ Early Registration until August 7! ===================================================================== ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. This year, the conference will be a virtual event. All activities will take place online. The main conference will take place from August 23-25, 2021 during two time bands. The first band will be 4PM-11PM Seoul time, and will include both technical and social activities. The second band will repeat (with some variation) the technical program and social activities 12 hours later, 3PM-10PM New York, the following day. We’re excited to announce that ICFP 2021 will feature an invited talk from Ravi Chugh of the University of Chicago. Keynote sessions will take place at 10 PM Seoul/9 AM New York. ICFP has officially accepted 35 exciting papers, and (in its second year) there will also be presentations of 4 papers accepted recently to the Journal of Functional Programming. Co-located symposia and workshops will take place the day before and two days immediately after the main conference. Registration is now open. The early registration deadline is August 7th, 2021. Registration is not free, but is significantly lower than usual, including a $10 discounted registration option available to all. Students who are ACM or SIGPLAN members may register for FREE before the early deadline. https://regmaster.com/2021conf/ICFP21/register.php New this year: Attendees will be able to sign-up for the ICFP Mentoring Program (either to be a mentor, receive mentorship or both). * Overview and affiliated events: http://icfp21.sigplan.org/home * Accepted papers: http://icfp21.sigplan.org/track/icfp-2021-papers#event-overview * JFP Talks: https://icfp21.sigplan.org/track/icfp-2021-jfp-talks#event-overview * Registration is available via: https://regmaster.com/2021conf/ICFP21/register.php Early registration ends 8 August, 2021. * Programming contest: https://icfpcontest2021.github.io/ * Student Research Competition: https://icfp21.sigplan.org/track/icfp-2021-Student-Research-Competition * Follow us on Twitter for the latest news: http://twitter.com/icfp_conference This year, there are 10 events co-located with ICFP: * Erlang Workshop (8/26) * Haskell Implementors' Workshop (8/22) * Haskell Symposium (8/26-8/27) * Higher-Order Programming with Effects (8/22) * miniKanren Workshop (8/26) * ML Family Workshop (8/26) * OCaml Workshop (8/27) * Programming Languages Mentoring Workshop (8/22) * Scheme Workshop (8/27) * Type-Driven Development (8/22) ### ICFP Organizers General Chair: Sukyoung Ryu (KAIST, South Korea) Program Chair: Ron Garcia (UBC, Canada) Artifact Evaluation Co-Chairs: Brent Yorgey (Hendrix College, USA) Gabriel Scherer (INRIA Saclay, France) Industrial Relations Chair: Alan Jeffrey (Roblox, USA) Simon Marlow (Facebook, UK) Programming Contest Organizers: Alex Lang and Jasper Van der Jeugt Publicity and Web Chair: Sam Tobin-Hochstadt (Indiana University, USA) Student Research Competition Chair: Anders Miltner (University of Texas, USA) Workshops Co-Chairs: Zoe Paraskevopoulou (Northeastern University, USA) Leonidas Lampropoulos (University of Maryland, USA) Video Co-Chairs: Leif Andersen (Northeastern University, USA) Ben Chung (Northeastern University, USA) Student Volunteer Co-Chairs: Hanneli Tavante (McGill University, Canada) Jaemin Hong (KAIST, South Korea) Lily Bryant (UBC, Canada) Accessibility Co-Chairs: Lindsey Kuper (UCSC, USA) Kathrin Stark (Princeton, USA)

1 0