July 2021 - Haskell-Cafe

Some Love for wxHaskell
by Tilmann 30 Jan '22

30 Jan '22

Hi cafe, I think wxHaskell needs some love :) Over the years I've written a small client for FICS (Free Internet Chess Server) and wxHaskell has served me really well. Also, wxWidgets seems solid and alive.. but today, wxHaskell is lagging behind updates and seems *sniff* dead. Is someone working on wxHaskell atm? I'd love to connect and help. If not, is there some interest to rejuvenate wxHaskell? Who is also depending on wxHaskell and wants to keep it going? Or, is it time to move on to gtk or reflex? Very much looking forward to your replies! Best, Tilmann

3 4

Do something about Cabal?
by Ignat Insarov 04 Jan '22

04 Jan '22

# Do something about Cabal? Hello. Cabal is the second most used tool in Haskell after GHC. It has many problems. It may be noticed that there is one and a half developers working on it. This is clearly not enough to address these problems. I propose that this is a good place to invest in. ### Problems I have in mind: * Poor communication, lack of open source development process. The whole Cabal–Stack schism appears to be an outcome of poor communication. One of the leading developers of Cabal is even banned from participation somewhere in Stack circles.[1] Personally, I reported several issues to Cabal and every single time it resulted in sadness. Observe a vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒ there are fewer contributors ⇒ core developers are overworked. I have no hard evidence but it appears that presently, more people that strive to improve the Haskell build experience are outside the Cabal cabal than are inside. * User experience is an afterthought. Cabal's user experience is horrifying. A collection of complaints is being compiled elsewhere.[2] There are also bugs being opened to Cabal because of this, requiring triage and therefore wasting the precious time of the few overworked developers. Stack is much more friendly — this shows by example that the user experience problem is not inherent and may be solved. It is ordinary to receive output like this: ``` % cabal run example-executable Warning: The package list for 'hackage.haskell.org' is 84 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: example-0.1.0.6 (user goal) [__1] next goal: opaleye (dependency of example) [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project config TODO requires ==0.6.7006.1) [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7) [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2, opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1, opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0, opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0, opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0, opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3, opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0, opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '^>=0.7' from example) [__1] fail (backjumping, conflict set: example, opaleye) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: opaleye, example ``` There are so many things that are wrong here. Even a sneaky _«to do»_ remark. If you wonder, in this case the solution is to remove and re-generate `cabal.project.freeze`. Even the name of the program — it is actually _«cabal-install»_ — is incomprehensible, it should be re-branded to Cabal, which is how everyone calls it anyway. * Features are not being introduced. There is no reason for two build tools to exist. The killer feature of Stack — snapshots — should be supported by Cabal. Possibly Cabal itself should be refactored and split so that there are separate tools for packaging, version resolution and human interaction — I do not know. But certainly the way things are presently is a waste of developer effort and a source of confusion for everyone. ### My proposition, in particular. * Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle. * Put in place a clear process for contributing and decision making, so that it does not come down to the privileged opinion of one of the core developers. * Make a model of user experience that Cabal should conform to, and make conformance a priority. Surely there are among us people that know a thing or two about user experience — call for them to step forward. Every issue that stems from misunderstanding, re-assign to the model instead of closing. * Merge the support of Stackage snapshots into Cabal. Ask the core developers of Stack to join the effort. Transition from Stack to Cabal should be one well discoverable command that just works. I realize that this letter is largely an opinion piece. You can also see it as an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the present. I do not insist that my vision is the best. But the present reality is not the best vision either. I propose, foremost, that we work and fight for a better future. [1]: https://github.com/commercialhaskell/stackage/issues/4472 [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

23 39

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

13 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

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

11 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

Sets, typeclasses and functional dependencies
by Stuart Hungerford 02 Aug '21

02 Aug '21

Hi Haskellers, After reading: https://stackoverflow.com/questions/34790721/where-is-the-set-type-class https://stackoverflow.com/questions/25191659/why-is-haskell-missing-obvious… https://stackoverflow.com/questions/11508642/haskell-how-can-i-define-a-typ… I can see why Haskell base does not provide typeclasses for sets. I'm wondering now though if I did create a Set typeclass what it would look like. There's several approaches using various language extensions and to me this approach using functional dependencies seems simpler than the other approaches: class Setish set a | set -> a where empty :: set singleton :: a -> set -- and so on. My question is how does the functional dependency in Setish interact with "extra" types needed for richer set operations like finding the powerset or taking a cartesian product? Something like: class Setish set a | set -> a where empty :: set singleton :: a -> set power_set :: set -> ?something product :: set -> ?something -> ?something -- and so on. TIA, Stu

4 5

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

31 Jul '21

On Thu, 29 Jul 2021, Benjamin Redelings wrote: > Hi Olaf, > > I think you need to look at two things: > > 1. The Giry monad, and how it deals with continuous spaces. I believe I understand the Giry monad well, and it is my measuring stick for functional probabilistic programming. Even more well-suited for programming ought to be the valuation monad, because that is a monad on domains, the [*] semantic spaces of the lambda calculus. Unfortunately, to my knowledge until now attempts were unsuccessful to find a cartesian closed category of domains which is also closed under this probabilistic powerdomain construction. [*] There are of course other semantics, domains being one option. > > 2. The paper "Practical Probabilistic Programming with Monads" - > https://doi.org/10.1145/2804302.2804317 Wasn't that what you linked to in your original post? As said above, measure spaces is the wrong target category, in my opinion. There is too much non constructive stuff in there. See the work of Culbertson and Sturtz, which is categorically nice but not very constructive. > > Also, observing 2.0 from a continuous distribution is not nonsensical. > > -BenRI Perhaps I am being too much of a point-free topologist here. Call me pedantic. Or I don't understand sampling at all. To me, a point is an idealised object, only open sets really exist and are observable. If the space is discrete, points are open sets. But on the real line you can not measure with infinite precision, so any observation must contain an interval. That aligns very nicely with functional programming, where only finite parts of infinite lazy structures are ever observable, and these finite parts are the open sets in the domain semantics. So please explain how observing 2.0 from a continuous distribution is not nonsensical. Olaf > > On 7/21/21 11:15 PM, Olaf Klinke wrote: >>> 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. >

1 0

Re. Looking for exemplars of "boring" or "simple" Haskell projects... (Rishiyur Nikhil)
by Stuart Hungerford 30 Jul '21

30 Jul '21

On Thu, Jul 29, 2021 at 10:07 PM <haskell-cafe-request(a)haskell.org> wrote: > [...] > A couple of years ago I wrote "Forvis", a "complete" semantics of the > RISC-V instruction set in "extremely elementary" Haskell. > > It's free and open-source, at: > https://github.com/rsnikhil/Forvis_RISCV-ISA-Spec > > "Extremely Elementary" Haskell: small subset of Haskell 98. No > type classes, no monads (except the top-level driver that uses > standard IO), no GHC extensions, nothing. Just vanilla function > definitions and vanilla algebraic types (a "Miranda" subset). > > Motivation: appeal to hardware designers, compiler writers, and others > who are keenly interested in a clearly readable and executable precise > spec of RISC-V semantics, but are not at all interested in learning > Haskell. Thanks for that, I'll have a look. Stu

1 0

Re. Looking for exemplars of "boring" or "simple" Haskell projects...
by Rishiyur Nikhil 29 Jul '21

29 Jul '21

A couple of years ago I wrote "Forvis", a "complete" semantics of the RISC-V instruction set in "extremely elementary" Haskell. It's free and open-source, at: https://github.com/rsnikhil/Forvis_RISCV-ISA-Spec "Extremely Elementary" Haskell: small subset of Haskell 98. No type classes, no monads (except the top-level driver that uses standard IO), no GHC extensions, nothing. Just vanilla function definitions and vanilla algebraic types (a "Miranda" subset). Motivation: appeal to hardware designers, compiler writers, and others who are keenly interested in a clearly readable and executable precise spec of RISC-V semantics, but are not at all interested in learning Haskell. It's about 12K-13K lines of Haskell, all in one 'src/' directory. Full "standard ISA" coverage: - Unprivileged ISA: - RV32I (32-bit) and RV64I (64-bit) basic Integer instructions - Standard ISA extensions M (Integer Mult/Div), A (Atomics), C (Compressed) and FD (Single- and Double-precision floating point) - Privileged ISA: Modes M (Machine), S (Supervisor) and U (User), including full complement of CSRs (Control and Status Registers). This includes full trap and interrupt handling, and RISC-V Virtual Memory schemes Sv32, Sv39 and Sv48. I've tested it on all the standard RISC-V ISA tests (pass), booted a Linux kernel (about 200 Million RISC-V Instructions), and the much smaller real-time OS FreeRTOS. I'm sure it'll work for any other RISC-V software as well. For this, the sources contain additional code to package the "CPU" into a small "system", by adding Haskell models of memory and a UART. I haven't looked at it since early 2020, but it should all still work fine. Nikhil

1 0

Looking for exemplars of "boring" or "simple" Haskell projects...
by Stuart Hungerford 28 Jul '21

28 Jul '21

Greetings Haskellers, I've been reading more about the ideas behind "simple" or "boring" Haskell and I am wondering if there are libraries or projects that exemplify the ideas behind these approaches? TIA, Stu

2 2

Munich Virtual Haskell Meeting, 2021-07-28 @ 19:30
by Leah Neukirchen 26 Jul '21

26 Jul '21

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, July 28 on Jitsi at 19:30 CEST. **Due to bad weather for meetings outside this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Jitsi 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 <leah(a)vuxu.org> https://leahneukirchen.org/

1 0