- Haskell-Cafe - Haskell.org

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

14 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 12 Nov '20

12 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

Re: [Haskell-cafe] Occult effects...
by Michal J Gajda 11 Nov '20

11 Nov '20

It is easier to understand it if: 1. You give some examples of such monads 2. Describe how this property arises 3. Tell how whether the law is unique or part of a list of laws applicable Most of mathematics we do is not entirely disconnected from applications. If I tell you there is a class of monoids `m` over a set of objects `o` : class Monoid m => T m o where i :: o -> t c :: t -> o -> Bool Such that the following laws are satisfied: Forall x y z m n. c (i x) x =True c mempty x = False c m y = True => c (m <> n) y = True c n y = True => c (m <> n) y = True What does it tell you about the definitions? Can you tell if this set of laws is correctly stated or exhaustive? Whether it models what I intend to do? Without further examples could I claim that it may be universal model for some phenomena f and g? Or would you rather see some examples or descriptions of i and c operations? PS you may respond to haskell-cafe, sure. I did not think that my previous question deserved sharing, but this answer certainly does. -- Cheers Michał On Wed, Nov 11, 2020, 14:04 Kim-Ee Yeoh <ky3(a)atamo.com> wrote: > Hi Michal, > > How is it hermetic? I think I fully described the property whose name I am > opening to discussion. > > What is lacking in the definition? > > Also, do you mind having this discussion at the cafe itself? You are > probably not the only one with this query. > > On Wed, Nov 11, 2020 at 7:37 PM Michał J Gajda <mjgajda(a)gmail.com> wrote: > >> Hi, >> Your post to haskell-cafe is somewhat hermetic if you do not provide >> additional examples. >> What do you use these for? >> -- >> Cheers >> Michał >> > -- > -- Kim-Ee >

1 0

Last Call for Contributions: BOB 2021 [Feb 26, Deadline Nov 13]
by Stefan Wehr 10 Nov '20

10 Nov '20

BOB Conference 2021 "What happens when we use what's best for a change?" http://bobkonf.de/2021/cfc.html Berlin, February 26 Call for Contributions Deadline: November 13, 2020 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Online or Onsite We do know yet whether BOB will happen onsite in Berlin or as an online event. Should BOB happen online, we will likely ask for pre-recorded talks to make room for questions and social interactions during the actual conference day. (Of course, we'll provide assistance making those recordings.) Tutorials will likely happen as a live-session. Speaker Grants -------------- BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers, speakers of color, and speakers who are not be able to attend the conference for financial reasons. Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions. Specifically: - advice on structure and presentation - review of talk slides - assistance with recording - review of recording, if applicable Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and databases - event-based modelling and architecture - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - … everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------ We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) - Don't be confused: The system calls a submission event. Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 13, 2020 - Notification: November 27, 2020 - Program: December 6, 2020 Submit here: https://bobcfc.active-group.de/en/bob2021/cfp Program Committee ----------------- (more information here: https://bobkonf.de/2020/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, Hochschule Offenburg Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0