November 2020 - Haskell-Cafe

Reading Haddock sources on hackage no longer possible with simple browsers?
by Mario Lang 14 Nov '20

14 Nov '20

Hi. I have been using Lynx to read stuff on hacakge for a long time. I recently noticed that it is no longer possible to read the source of a module, because extra type information (which is likely hidden in a modern browser) is inline with the actual sources. This makes the go to source feature effectively useless. An example (from the ISBN package): deriving (Int -> ISBN -> ShowS [ISBN] -> ShowS ISBN -> String (Int -> ISBN -> ShowS) -> (ISBN -> String) -> ([ISBN] -> ShowS) -> Show ISBN forall a. (Int -> a -> ShowS) -> (a -> String) -> ([a] -> ShowS) -> Show a showList :: [ISBN] -> ShowS $cshowList :: [ISBN] -> ShowS show :: ISBN -> String $cshow :: ISBN -> String showsPrec :: Int -> ISBN -> ShowS $cshowsPrec :: Int -> ISBN -> ShowS Show, ISBN -> ISBN -> Bool (ISBN -> ISBN -> Bool) -> (ISBN -> ISBN -> Bool) -> Eq ISBN forall a. (a -> a -> Bool) -> (a -> a -> Bool) -> Eq a /= :: ISBN -> ISBN -> Bool $c/= :: ISBN -> ISBN -> Bool == :: ISBN -> ISBN -> Bool $c== :: ISBN -> ISBN -> Bool Eq) I know Haskell has a ton of extensions, but I am pretty sure nobody writes code like this :-) This is, frankly, pretty horrible. Can something be done to fix this? (I am aware that certain modernisations are unstoppable. However, this one looks like a bug.) -- CYa, ⡍⠁⠗⠊⠕

2 1

Generic Sorting
by Henry Laxen 14 Nov '20

14 Nov '20

Good evening Haskellers. I've done some searching but so far haven't found anything, which make me think this probably isn't possible. I am wondering if it is possible to do a "Generic Sort" on multilevel data structures. Suppose you have something like: data A = A Int [Int] data B = B Int [A] a1 = A 2 [2,1] a2 = A 1 [4,3] b = B 1 [a1,a2] genericSort b = B 1 [A 1 [3,4], A 2 [1,2]] note that not only are the A's sorted, but the list inside each A is sorted. It "sorted all the way down". Has Edward written such a thing yet? ;-) His "discrimination" library doesn't do this, in case you're wondering. Any ideas? Best wishes, Henry Laxen

3 3

support for ergonomic dependent types
by Richard Eisenberg 13 Nov '20

13 Nov '20

Hi all, The GHC Steering Committee has been struggling recently to decide on several related proposals. The struggle is all around whether we should favor making a design that is future-compatible with dependent types, or favor a design that is more cohesive with e.g. Haskell98. (Sometimes, we can have both. Those are good times.) This isn't about backward compatibility -- the design for dependent Haskell is fully backward compatible with Haskell98. It's more about how well the new features fit with the old ones. To clarify our thinking on it all, I've made a new proposal to discuss whether or not we want to favor keeping an avenue open to ergonomic dependent types in the future. If you have an opinion, please express it on the proposal. In particular, if you care about the possibility of ergonomic dependent types in Haskell, now is the time to show that support by thumbs-upping the proposal. The proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/378. Thanks! Richard

1 0

Re: [Haskell-cafe] What to call Occult Effects
by Olaf Klinke 13 Nov '20

13 Nov '20

> First, instead of `const id` I will use `const`, that is, we shall > prove > > const = liftM2 const :: M a -> M b -> M a > > which I believe should be equivalent to your property. My belief was wrong, which is evident when using do-notation. Kim-Ee stated do {_ <- b; x <- a; return x} = a while I examined do {x <- a; _ <- b; return x} = a Since do {x <- a; return x} = a holds for any monad, Kim-Ee's property can be reduced to do {_ <- b; a} = a or more concisely b >> a = a which I called Kleisli-const in my previous post. As we seemed to have settled for "occlusive" I suggest calling b >> a = a "right-occlusive" or "occlusive from the right" because the right action occludes the side-effects of the left action, and do {x <- a; _ <- b; return x} = a should be called "left-occlusive" or "occlusive from the left" because the left action hides the effect of the right action. Under commutativity, both are the same but in general these might be different properties. I do not have a distinguishing counterexample, though, because all monads I come up with are commutative. David Feuer hinted at the possibility to define occlusiveness more generally for Applicative functors. Commutativity might be stated for Applicatives as liftA2 f a b = liftA2 (flip f) b a So far I can only see two classes of occlusive monads: The reader-like (Identity ~ Reader ()) and the set-like monads. Olaf

3 4

Advent of Haskell is still waiting for ideas
by Ida Bzowska 13 Nov '20

13 Nov '20

Hi there, Advent of Haskell is an advent calendar filled with Haskell content, obviously :) The first confirmations to "Advent of Haskell" participants' have been sent this week, but there are still a lot of open spots to go, so do not hesitate to submit your idea. All the details are available here: https://adventofhaskell.com Happy haskelling everyone! λCheers, Ida

1 0

caching ~/.cabal with github actions on windows
by Ben Franksen 13 Nov '20

13 Nov '20

I can't get this to work. It works perfectly fine on Linux and MacOS but on Windows cabal always re-builds all the dependencies. The cache post-action on Windows tells me that the cache hasn't changed, which means cabal actually re-created the ~/.cabal directory exactly as it was in the cache! Is this a known bug in cabal on Windows? Does anyone have a work-around? Cheers Ben

3 6

What to call Occult Effects
by Kim-Ee Yeoh 12 Nov '20

12 Nov '20

By an occult effect I mean that under the type signature (M a -> M b -> M b) of a particular monad M, the two expressions (const id) and (liftM2 $ const id) are equivalent. Occult here refers to how the effect of the second parameter blocks the effect of the first one. In your opinion, is there a better word than occult to describe the property of such monads? -- -- Kim-Ee

5 6

Re: [Haskell-cafe] What to call Occult Effects
by Kim-Ee Yeoh 11 Nov '20

11 Nov '20

On Thu, Nov 12, 2020 at 12:17 AM Justin Bailey <jgbailey(a)gmail.com> wrote: > Looking up the definition "occult" on duckduckgo > (https://duckduckgo.com/?t=ffab&q=occult+definition&ia=definition) > gives this response: > > adj. Of, relating to, or dealing with supernatural or magical > influences, agencies, or occurrences. > adj. Available only to the initiate; secret or mysterious: synonym: > mysterious. > adj. Beyond the realm of human comprehension; inscrutable. > > Doesn't seem to really apply to your type signature. If you mean in > the sense of "occlusion" or "occludes", I'd be specific ("occluded > effects"). Hi Justin, Thank you for heads up, it's just the nudge I need that "occult" probably isn't the right word although I had the astronomical usage in mind. My go-to solution is now "occlusive effects" unless something even better comes along. > > On Tue, Nov 10, 2020 at 3:24 PM Kim-Ee Yeoh <ky3(a)atamo.com> wrote: > > > > By an occult effect I mean that under the type signature (M a -> M b -> > M b) of a particular monad M, the two expressions (const id) and (liftM2 $ > const id) are equivalent. > > > > Occult here refers to how the effect of the second parameter blocks the > effect of the first one. > > > > In your opinion, is there a better word than occult to describe the > property of such monads? > > -- > > -- Kim-Ee > > _______________________________________________ > > 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. > -- -- Kim-Ee

1 0

Re: [Haskell-cafe] What to call Occult Effects (Kim-Ee Yeoh)
by Olaf Klinke 11 Nov '20

11 Nov '20

> By an occult effect I mean that under the type signature (M a -> M b > -> M > b) of a particular monad M, the two expressions (const id) and > (liftM2 $ > const id) are equivalent. > > Occult here refers to how the effect of the second parameter blocks > the > effect of the first one. > > In your opinion, is there a better word than occult to describe the > property of such monads? Dear Kim-Ee, TL;DR: Why not the simpler do {y <- b; a} = a My name for your property would be "distribution-like" or "lazy" because of an old post of mine [1]. In that thread we discussed models of probability and I emphasized the property fmap.const = const.return :: a -> M b -> M a (Functor-const) which we will see is equivalent to your occultness. Categorically it can be re-phrased as: "M as a functor maps constant functions to constant functions." First, instead of `const id` I will use `const`, that is, we shall prove const = liftM2 const :: M a -> M b -> M a (occultness) which I believe should be equivalent to your property. For the proof it will be convenient to use the following. Lemma: liftM2 f a b = a >>= (\x -> fmap (f x) b) Proof: We de-sugar the do-notation in the source code for liftM2. liftM2 f a b = a >>= (\x -> b >>= (\y -> return (f x y))) Now use the equation fmap h b = b >>= (\y -> return (h y)) with h instantiated to `f x` to obtain the desired identity. q.e.d. Armed with the Lemma we instantiate f = const. liftM2 const a b = a >>= (\x -> fmap (const x) b) If we now assume my property (Functor-const) then we may re-write to liftM2 const a b = a >>= (\x -> const (return x) b) = a >>= (\x -> return x) = a We have shown (Functor-const) implies (occultness). For the reverse implication, we shall prove (Functor-const) holds with the arguments swapped, that is, we prove the equation \b -> \x -> fmap (const x) b = \b -> \x -> return x Starting with the left-hand side, we eta-expand using the law (k :: a -> M b) x = return x >>= k and obtain \b -> \x -> (return x >>= (\x -> fmap (const x) b)) Using the Lemma we identify the expression in the outermost parentheses as liftM2 const (return x) b which by assumption equals return x, whence we re-write the entire term to \b -> \x -> return x q.e.d. Next consider a law with the same type as (occultness): (=<<).const = const :: M a -> M b -> M a (Kleisli-const) do {y <- b; a} = a (same in do-notation) Any MonadPlus fails this due to the law k =<< mzero = mzero. Categorically it can be re-phrased as "The functor from the Kleisli category of M to Hask preserves constant arrows." I will prove that if M is commutative then (Kleisli-const) implies (occultness). liftM2 const a b = do {x <- a; y <- b; return (const x y)} = do {y <- b; x <- a; return (const x y)} (by commutative) = do {y <- b; x <- a; return x} = do {y <- b; a} = a (by Kleisli-const) Probability distributions have property (Functor-const) because it essentially says that if you map any distribution through a constant function, you will end up with all mass in one place. It is related to lazyness because a priori const a :: M b -> M a is lazy in its argument whereas \b -> a >>= (\x -> fmap (const x) b) is not lazy a priori, i.e. may examine its argument b and execute side- effects. Such lazyness was desired in [1] because inspecting an argument in that context meant computationally expensive sampling of a random distribution. Are there concrete Haskell monads with this property? NonEmpty lists have this property up to multiplicity and order, that is, non-empty finite sets are an example of an occult M. The Reader monad is easily seen to have this property. And that seems to be all. Observe that my two example monads above are indeed commutative and have the property (Kleisli-const). I'm curious whether (Kleisli-const) makes sense in your application. Olaf [1] https://mail.haskell.org/pipermail/haskell-cafe/2019-October/131605.html

1 0

Three new Teaching Assistant positions in Nottingham
by Graham Hutton 11 Nov '20

11 Nov '20

Dear all, As part of a strategic expansion, the School of Computer Science at the University of Nottingham is seeking to make three new permanent appointments at Teaching Assistant level: https://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI290020 Applicants with expertise in functional programming are strongly encouraged! The deadline for applications is 11th December 2020. 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.

1 0