August 2021 - Haskell-Cafe

Re: [Haskell-cafe] Different advice for type classes for end-user app and libraries?
by Michal J Gajda 13 Aug '21

13 Aug '21

Dear Ruben, > Currently I am working a end user application. Through the years I had > incorporated the advice from r/haskell that classes without laws were not > desirable. Their lack meant that we didn't have a contract boundary that > should be respected by the instances. They secretly could `throw exc` on > their implementation and you wouldn't notice. Indeed you are right. This is especially pressing for the type classes that convey relations between multiple types. Luckily, diligent students of Haskell source code will find common patterns for the laws that occur -- see below. > But on the current app I am working on, I follow the advice from this > blogpost [1] that I should use classes for domain modelling. This manifest > on classes like > class UserQueryCapability f where > getUser :: Id -> f User Before we get to the laws, I would recommend that you use technique of "linguistic analysis" to find a better name for the class. If not, you may want to remove words that are implicit in the object. Class name of "UserQuery" may be better, because "capability" is implicit in the fact that it is a type class. See example here: https://olegchursin.medium.com/a-brief-introduction-to-domain-modeling-862a… > for interacting with a DB. Functions can be written against the interface > and I can mock up with QuickCheck some pretty broad cases. The classes > usually don't have a superclass constrain on `Monad` as in `MonadReader` > because I *cannot* establish a law relating the monadic behavior and > `getUser`. The name has Capability in it and not Monad because I won't lie > that way. First method is to recognize a common pattern: you have a function that reads a part of the state. That means it is similar to `lookup userId <$> ask`. `ask` follows certain laws, and you may apply these laws here: getUser u >> getUser u == ask -- idempotence getUser u >> return () == return () -- no effect of reading To get inspiration for other laws you may look at how this type class interacts with other type classes that deal with `User` objects here. There are several other techniques that apply in special cases. For example if you have multiple self-contained implementations of a type class, you may use `quickspec` to get equational laws for different implementations, and look for common laws between different implementations. https://hackage.haskell.org/package/quickspec These two ways seem to be most applicable from the example you have provided so far. > Making sure that these effect classes are orthogonal is something I have to > check by hand. But in the back of my head there is the concern about the > lack of laws could bite me even on a end user-app. Is my intuition well > founded that this case is OK? Lack of laws may mean one of the following: * type class is not an abstraction and thus does not allow you to tell anything abstract about it * you may have undocumented tacit knowledge about the type class that gets lost in the implementation * your users will find it harder to use type class as interface (as it is intended to be used). Advert: If the above description is insufficient, and the task is too challenging to fully solve within haskell-cafe mailing list, you may contact https://www.migamake.com for consulting on type class design and training. We do provide business analysis for Haskell projects too. -- All the best Michał

1 0

base64-bytestring memory corruption bug
by Fraser Tweedale 12 Aug '21

12 Aug '21

Hello, I want to bring to wider attention a memory bug present in base64-bytestring[1]. In summary, in some cases too few bytes are allocated for the output when performing base64url decoding. This can lead to memory corruption (which I have observed[2]), and possibly crashes (which I have not observed). I submitted a pull request[2] that fixes the issue some days ago, but did not receive a response from the maintainers yet. I understand that maintainers may be busy or unavailable, and that is fine. So I am posting here mainly to ensure that USERS are aware of the issue. To maintainers: let me know if I can provider further assistance to resolve this issue and release a fix. [1] https://github.com/haskell/base64-bytestring/issues/44 [2] https://github.com/frasertweedale/hs-jose/issues/102 [3] https://github.com/haskell/base64-bytestring/pull/45 Thanks, Fraser

3 4

Organizing your code files
by Christopher Conforti 12 Aug '21

12 Aug '21

Hi List, I'm a relatively new Haskeller. I've gotten the syntax of the language more or less down, and I'm slowly expanding my vocabulary. I've found in other languages that my coding style and how my code is organized affect both the quality of my code and how easy it is to understand. 'Coding style' refers to how code is organized within a block. For example: ``` foo bar baz bing = x + y * z ``` versus: ``` foo bar baz bing = x + y * z ``` Code organization refers both to how code is organized within a source file (i.e., how code blocks are arranged, how they're grouped, so on) and how source files themselves are organized. I've got the first part down--I've developed a code style that I'm satisfied with, I've tried to fine-tune my style to make maximum effective use of available space (limiting myself to 72 columns, and a block size of no more than 30 lines) so as to force myself to extract and abtract away unnecessary details. The second part is the one I'm having trouble with. There are so many ways to organize one's code that I don't even know where to begin developing a method that I like other than to ask other Haskellers how they do it and why they like doing it that way. So there you have it: How do you organize your code, and why? Cheers! -- Christopher Conforti

5 6

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