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 03 Jan '22

03 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 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

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 30 Jul '21

30 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 29 Jul '21

29 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 28 Jul '21

28 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

What would be the equivalent in Haskell of Knuth's Dancing Links method on a doubly linked circular list?
by Casey Hawthorne 24 Jul '21

24 Jul '21

Hi What would be the equivalent in Haskell of Knuth's Dancing Links method on a doubly linked circular list?

2 3

From Rabhi's & Lapalme's book 'Algorithms - A Functional Programming Approach' I'm getting a non-exhaustive pattern match
by Casey Hawthorne 22 Jul '21

22 Jul '21

>From Rabhi's & Lapalme's book 'Algorithms - A Functional Programming Approach' 1999, I'm getting a non-exhaustive pattern match weight x y g = w where (Just w) = g!(x,y) I can't figure out why

3 2

Re: [Haskell-cafe] Lazy Probabilistic Programming System in Haskell
by Olaf Klinke 21 Jul '21

21 Jul '21

> Hi, > > My program BAli-Phy implements probabilistic programming with models > written as Haskell programs. > > http://www.bali-phy.org/models.php Dear Benjamin, last time you announced BAli-Phy I pestered you with questions about semantics. In the meantime there was a discussion [1] on this list regarding desirable properties of probabilistic languages and monads in general. A desirable property of any probabilistic language is that when you define a distribution but map a constant function over it, then this has the same computational cost as returning the constant directly. Can you say anything about that? Cheers, Olaf [1] https://mail.haskell.org/pipermail/haskell-cafe/2020-November/132905.html

2 4

Fwd: Haskell program introspection tooling development.
by Csaba Hruska 21 Jul '21

21 Jul '21

Hello, I'm using the external STG interpreter <https://www.patreon.com/posts/external-stg-49857800> to introspect the runtime behaviour of Haskell programs. Lately I've added an initial call-graph construction feature that I plan to refine further. https://twitter.com/csaba_hruska/status/1417486380536582151 Is there anyone who has dynamic analysis related research ambitions and wants to study Haskell program runtime behaviour in detail? If so then it would be great to talk. Cheers, Csaba

1 0

Help on syntactic sugar for combining lazy & strict monads?
by Benjamin Redelings 20 Jul '21

20 Jul '21

Hi, I'm working on a probabilistic programming language with Haskell syntax [1]. I am trying to figure out how to intermingle lazy and strict monadic code without requiring ugly-looking markers on the lazy code. Does anybody have insights on this? 1. I'm taking a monadic approach that is similar to [2], but I'm using a lazy interpreter. This allows code such as the following, which would not terminate under a strict interpreter: run_lazy $ do xs <- sequence $ repeat $ normal 0 1 return $ take 10 xs Here "xs" is an infinite list of Normal(0,1) random variables, of which only 10 are returned. In a strict interpreter the line for "xs" never completes. But in a lazy interpreter, it works fine. 2. 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. 3. My current approach is to use TWO monads -- one for random sampling (Sample a), and one for observations (Observe a). The random sampling monad can be lazy, because for random samples there is no need to force a sampling event if the result is never used. The observation monad is strict, because all the observations must be forced. So this WORKS fine. However... the code looks ugly :-( Help? 4a. One idea is to nest the lazy code within the strict monad, using some kind of tag "sample :: Sample a -> Observe a". Then we could write something in the (Observe a) monad like: run_strict $ do w <- sample $ sequence $ repeat $ normal 0 1 x <- sample $ normal 0 1 2.0 `observe_from` normal x 1 y <- sample $ normal x 1 z <- sample $ normal y 1 2.0 `observe_from` normal z 1 return y When the "run_strict" interpreter encounters a statement of the form (sample $ _ ), it switches to the "run_lazy" interpreter for that statement. In this case, the `observe_from` statement IS forced because it is in the strict (Observe a) monad. Maybe somewhat surprisingly w, x, y, and z are forced (ugh!) -- by the outer strict interpreter, not the inner lazy interpreter. However, the internal components of w are NOT forced, so the program is able to terminate. QUESTION: Is there some way of doing this without manually writing "sample" in front of all the sampling operations? QUESTION: is there a way of doing this where the "sample $ _" lines do NOT have their result forced? 4b. In order to write "sample" less, it is possible to factor the sampling code into a separate function (here called "prior"): prior :: Sample ([Double], Double, Double, Double) prior = do w <- sequence $ repeat $ normal 0 1 x <- normal 0 1 y <- normal x 1 z <- normal y 1 return (w,x,y,z) model :: Observe Double model = do (w,x,y,z) <- sample $ prior 2.0 `observe_from` normal x 1 2.0 `observe_from` normal z 1 return y This does mean that you have to write "sample" only once... but it (i) splits the function in half and (ii) forces you to explicitly pass (w,x,y,z) between the two functions. That obfuscates the code for no benefit. Interestingly, the logical conclusion of this movement of code from (Observe a) to (Sample a) is to move EVERYTHING to the Sample monad: prior :: Sample (Observe (), Double) prior = do w <- sequence $ repeat $ normal 0 1 x <- normal 0 1 let observations1 = [2.0 `observe_from` normal x 1] y <- normal x 1 z <- normal y 1 let observations2 = [2.0 `observe_from` normal z 1]++observations1 return (observations2,y) model :: Observe Double model = do (observations, y) <- sample $ prior sequence_ observations return y Now, we have moved all the observations into the (Sample a) monad, but using horrible syntax! Ugh :-( Also, now the function "model" is basically the same for all models -- the entire model has been moved into the prior. QUESTION: is there some way to write a monadic function like "prior" while accumulating things observations in a list? Thanks for any insights! -BenRI [1] http://bali-phy.org/models.php [2] Practical probabilistic programming with monads, https://dl.acm.org/doi/10.1145/2804302.2804317 [3] https://github.com/tweag/monad-bayes/issues/32

1 0

ANN: stack-2.7.3
by Emanuel Borsboom 20 Jul '21

20 Jul '21

See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.7.1:** Other enhancements: * `stack upgrade` will download from `haskellstack.org` before trying `github.com`. See [#5288](https://github.com/commercialhaskell/stack/issues/5288) * `stack upgrade` makes less assumptions about archive format. See [#5288](https://github.com/commercialhaskell/stack/issues/5288) * Add a `--no-run` flag to the `script` command when compiling. Bug fixes: * GHC source builds work properly for recent GHC versions again. See [#5528](https://github.com/commercialhaskell/stack/issues/5528) * `stack setup` always looks for the unpacked directory name to support different tar file naming conventions. See [#5545](https://github.com/commercialhaskell/stack/issues/5545) * Bump `pantry` version for better OS support. See [pantry#33](https://github.com/commercialhaskell/pantry/issues/33) * When building the sanity check for a new GHC install, make sure to clear `GHC_PACKAGE_PATH`. * Specifying GHC RTS flags in the `stack.yaml` no longer fails with an error. [#5568](https://github.com/commercialhaskell/stack/pull/5568) * `stack setup` will look in sandboxed directories for executables, not relying on `findExecutables. See [GHC issue 20074](https://gitlab.haskell.org/ghc/ghc/-/issues/20074) * Track changes to `setup-config` properly to avoid reconfiguring on every change. See [#5578](https://github.com/commercialhaskell/stack/issues/5578) **Thanks to all our contributors for this release:** * Andreas Källberg * Artur Gajowy * Felix Yan * fwcd * Ketzacoatl * Matt Audesse * Michael Snoyman * milesfrain * parsonsmatt * skforg

1 0

lost the ability to provide haddocks for hackage
by Olaf Klinke 17 Jul '21

17 Jul '21

Dear Cafe, it seems I lost the ability to provide documentation for my hackage packages. While it is known that hackage sometimes fails to build documentation, the upload page [1] provides a guide to build and upload documentation. Stack does not have this ability yet [2] but it has the convenient option --no-haddock-deps that I can use as last resort when a dependency fails to build its Haddocks. I'd rather present documentation with broken links than no documentation at all. Cabal does not seem to provide such an option, while adding --keep-going and/or --enable-per-component to the suggested cabal command in [1] still aborts when one dependency fails to build. Is there something I've missed? If there is a way to build hackage-documentation in presence of haddock errors in dependencies, please someone update [1] and [3]. Can [4] be used to circumvent my problem? Perhaps add a guide to tweak the links generated by stack haddock to be hackage-compatible, as suggested in [2]? Strangely, the dependency package my cabal v2-haddock command fails on does have documentation on hackage. Would it be possible to pull these docs from hackage and use as a drop-in replacement? Thanks, Olaf [1] https://hackage.haskell.org/upload [2] https://github.com/commercialhaskell/stack/issues/737 [3] https://cabal.readthedocs.io/en/3.4/cabal-commands.html#cabal-v2-haddock [4] http://neilmitchell.blogspot.co.uk/2014/10/fixing-haddock-docs-on-hackage.h…

2 1

Compiled program running (extremely) slower than interpreted equivalent (no results produced)
by CASANOVA Juan 16 Jul '21

16 Jul '21

Hello, I have a (fairly complicated) Haskell program. The main aspect I believe is relevant about it is that it produces an infinite output (something like an infinite list evaluated lazily, except I use my own data structures with better properties). What I want is to see how fast the elements in the "list" are produced and check that they are correct, without reaching any particular point. Producing even just a couple elements of this list takes A LOT of computations. I normally run everything interpreted, and this works fine. However, it is a tad too slow and I wanted to profile it, for which I need to compile it. Here is my typical way to run it interpreted: * stack ghci +RTS -M500m -RTS * :load CESQResolverEval.hs * main This produces 4-5 outputs within a few seconds. When I try to compile it: * stack ghc --rts-options "-M500m" CESQResolverEval.hs * stack exec ./CESQResolverEval This dies. Moreover, if I run without the RTS options and/or let it run for a while, it completely kills my computer and I have to restart it. I initially thought it may be a thing with output flushing but: * I added a stdout flush after each individual element of the "list", and it changes nothing. * I even tried changing what main does so that it stops after the first result. This works when interpreted (takes less than a second), but still the program produces nothing and kills my CPU when compiled. Maybe relevant is that loading my program into GHCi takes about 30 seconds. The only thing I've been able to find online is this: https://www.reddit.com/r/haskell/comments/3hu3sd/how_is_it_possible_that_co… But that seems to be about complicated flags and their implications. As you can see, my flags are fairly simple. Anyone has any idea what this could be about, or how to avoid it? My purpose is to profile the program to see where most of the time is being spent, but I cannot do that without compiling it, and if the compiled code is running much slower than the interpreted code, then it seems absurd to even try to profile this (it must not be doing the same that the interpreted code is doing?). Thanks in advance, Juan. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

3 3

Lazy Probabilistic Programming System in Haskell
by Benjamin Redelings 16 Jul '21

16 Jul '21

Hi, My program BAli-Phy implements probabilistic programming with models written as Haskell programs. http://www.bali-phy.org/models.php Unlike [1], models are *lazy* in the sense that you can generate an infinite list of random variables, as long as you only access a finite number. I am also using MCMC for inference, not particle filters. BAli-Phy implements a Haskell interpreter in C++ that records execution traces of Haskell programs. When a random variable is modified (during MCMC), the parts of the execution trace that depend on the changed variables are invalidated and recomputed. This saves work by not recomputing the probability of the new state from scratch. Here's a example of a model written in Haskell: https://github.com/bredelings/BAli-Phy/blob/master/tests/prob_prog/regressi… WARNING: There are lots sharp edges. First and foremost, no type system! (yet) -BenRI [1] Practical probabilistic programming with monads, https://dl.acm.org/doi/10.1145/2804302.2804317

1 0

Haskell books index with RSS
by Travis Cardwell 14 Jul '21

14 Jul '21

Dear Café, I have often wished that I could subscribe to RSS feeds that notify me when new books are published about a certain topic or by a certain author. I recently implemented the idea in the article system of my personal website and created an index of Haskell books. https://www.extrema.is/articles/haskell-books The index provides a simple UI for browsing by tag, and each book page has basic information and links. By subscribing to the following RSS feed, you get a notification when a new book is added to the index. https://www.extrema.is/articles/tag/index:haskell-books.rss This is a humble first implementation, but I am posting here in case others find it useful. Regards, Travis

3 4

Re: [Haskell-cafe] Check a lack of a constraint?
by Olaf Klinke 13 Jul '21

13 Jul '21

> > Hello cafe, > > Is it possible in Haskell to check a lack of a certain constraint? > > For example, > > ``` > foo :: C => a > foo = undefined > > ``` > > Here `foo` can only be compiled if called with C satisfied. How do I write the > opposite, so that `foo` is only possible to use when C is not satisfied? > > With best regards. Indeed I found myself wanting this, too. Such a feature might reduce the amount of overlapping instances, but of course it bears the danger that others pointed out. For example, suppose you have a type T :: (* -> *) and the library author of T already defined an instance instance C a => C (T a). Now suppose you have a concrete type A which you know can never have a (lawful) C A instance, but you can define an instance C (T A). The latter would be formally overlapping with the former, even if you know that the former will never be implemented. Thus, instead of local non-satisfiability, a token for the proof that an instance can not exist might be more useful (and more safe). This would correspond to case 2 in Sylvain Henry's GHC proposal. I have no idea, however, how such a proof can be presented [*] in a way that can not be circumvented by a third author and lead to unsoundness. As a concrete example, I defined an instance MonadParsec (StateT String Maybe) which makes a wonderfully fast parser that you can swap in for a Megaparsec parser, but it is overlapping because of MonadParsec Maybe => MonadParsec (StateT s Maybe) although it is absurd to try to make Maybe an instance of MonadParsec. Another example: Think about why the mtl library has an instance MonadFoo m => MonadFoo (BarT m) for every pair (Foo,Bar) of transformers. (And there are quadratically many of these!) It is precisely because a catch-all instance like (MonadTrans t, MonadFoo m) => MonadFoo (t m) will be overlapping as long as we can't rule out MonadFoo (t m) by other means. Olaf [*] The logically natural way would be to have a Void constraint, so that we can say: MonadParsec Maybe => Void

1 0

Check a lack of a constraint?
by Lana Black 13 Jul '21

13 Jul '21

Hello cafe, Is it possible in Haskell to check a lack of a certain constraint? For example, ``` foo :: C => a foo = undefined ``` Here `foo` can only be compiled if called with C satisfied. How do I write the opposite, so that `foo` is only possible to use when C is not satisfied? With best regards.

5 9

What can I use for a weighted graph? I thought Data.Graph would work but I see no provision for edge weights?
by Casey Hawthorne 12 Jul '21

12 Jul '21

Hi What can I use for a weighted graph? I thought Data.Graph would work but I see no provision for edge weights?

2 3

Re: [Haskell-cafe] How to do reversible parsing?
by Johannes Waldmann 10 Jul '21

10 Jul '21

Rendell and Ostermann, Invertible syntax descriptions, Haskell Symposium '10 https://doi.org/10.1145/1863523.1863525 https://hackage.haskell.org/package/invertible-syntax For the general background, see, e.g., Grohne and Voigtländer 2017 Formalizing semantic bidirectionalization ... https://doi.org/10.1016/j.jlamp.2016.04.002 And there's a workshop series on Bidirectional Transformations (from 2012 onwards) - J.

3 9

Invitation: Virtual Haskell Cohack, July 10 (Saturday)
by Chris Smith 10 Jul '21

10 Jul '21

Hello everyone, I'd like to formally invite you to the Virtual Haskell Cohack, which will be running monthly beginning Saturday, July 10. Please review times and RSVP at https://www.meetup.com/NY-Haskell/events/279067287/ so that I know how many people are coming. I would need to upgrade my Zoom account if we exceed 100 people, but that would be amazing. Please make that happen! This is an event for the Haskell community to get together and work on collaborative projects. This could mean: - Teaching or learning Haskell - Writing code or docs on your favorite project and introducing it to others - Learning about other people's projects and getting some mentorship to contribute. - Pair programming on programming challenges like Advent of Code or Project Euler. - Just hanging out and geeking out talking category theory or GHC profiling techniques or whatever. The full agenda is listed at the link above, but it also includes lightning talks, which you can propose when you RSVP or just wait and volunteer to give one at the event. If you want to be sure you make it on the list, mention that you'd like to give a talk in your RSVP and you'll get priority on the signup list. Haskell-adjacent technologies are also welcome, so if you'd like to come hack in Elm, Idris, Agda, Coq, Ocaml, or whatever, you are welcome. The only rule we have is to be kind and welcoming to others. Thanks, and hope to see you there.

1 2

[ANN] parser-unbiased-choice-monad-embedding - the best parsing library; it is based on arrows (was: Pearl! I just proved theorem about impossibility of monad transformer for parsing with (1) unbiased choice and (2) ambiguity checking before running embedded monadic action (also, I THREAT I will create another parsing lib))
by Askar Safin 09 Jul '21

09 Jul '21

Hi. I announce my parsing library https://hackage.haskell.org/package/parser-unbiased-choice-monad-embedding . I think it is best parsing library, and you should always use it instead of other solutions. I will tell you why. You may check comparison table: https://paste.debian.net/1203863/ (if you don't understand the table, don't worry; come back to the table after reading this mail). My library is solution to problem described in this e-mail thread, so read it for motivation: https://mail.haskell.org/pipermail/haskell-cafe/2021-June/134094.html . Now let me describe my solution in detail. I will distinguish parser errors (i. e. "no parse" or "ambiguous parse") and semantic errors (i. e. "division by zero", "undefined identifier", "type mismatch", etc). So, now I will show you parser with unbiased choice, which allows monad embedding. As a very good introduction to arrows I recommend this: https://ocharles.org.uk/guest-posts/2014-12-21-arrows.html . We start from classic parser with this type: newtype ParserClassic t a = ParserClassic ([t] -> [(a, [t])]) You can make it be instance of Functor, Applicative, Monad and Alternative. This type is similar to ReadS from base ( https://hackage.haskell.org/package/base-4.15.0.0/docs/Text-ParserCombinato… ) and to "type Parser = StateT String []" from example here: https://hackage.haskell.org/package/transformers-0.5.5.0/docs/Control-Monad… . I will not give more information, feel free to find it in internet. Now let's replace "a" with Kleisli arrow "b -> m c". We will get this: newtype Parser1 t m b c = Parser1 ([t] -> [(b -> m c, [t])]) Here is resulting parsing library and example: https://godbolt.org/z/qsrdKefjT (backup: https://paste.debian.net/1203861/ ). We can use this parser in Applicative style. And when we need to lift something to embedded monad, we resort to Arrow style. I didn't test this code much. Parser1 cannot be Monad (I proved this in previous letters). At this point someone may ask: why we need arrows? Can we achieve same effect using Applicative only? Yes, we can. Here is result: https://godbolt.org/z/ocY3csWjs (backup: https://paste.debian.net/1203862/ ), I will call such method "anti-arrow". But we have two problems here: first, I think this method makes parser code uglier. Second, this method is limited, and I will show you why later. Okey, now back to arrows. Still, we have this problems (I'm about our arrow code): - Handling left-recursive grammars is tricky (it is possible, but not as simple as right-recursive ones) - Parsing errors (as opposed to semantic error messages) are not great. I. e. if there is no valid parses, we don't get any additional information, i. e. we don't know which token caused error - We don't track locations, so semantic errors are not great, too (i. e. we want to have location info to embed it into semantic error messages) - I suspect this parsing library will have very bad speed, possibly O(exp(input size)) So, let's combine our ideas with package Earley ( https://hackage.haskell.org/package/Earley ). Earley has type "Prod r e t a". Let's replace "a" with Kleisli arrow "b -> m c". Also let's wrap this Kleisli arrow to "L" from srcloc ( https://hackage.haskell.org/package/srcloc ) to get location info. Also, we wrap "t" to "L", too. Thus we get this type: newtype ArrowProd r e t m b c = ArrowProd (Prod r e (L t) (L (b -> m c))) Here is resulting library with example: https://hackage.haskell.org/package/parser-unbiased-choice-monad-embedding . (I didn't test much.) (I recommend to read docs to Earley first.) (My library is designed to be used with some external lexer, lexer-applicative is recommended.) The example also uses lexer-applicative, because lexer-applicative automatically wraps tokens into "L". So, what we got? We solved original goals, i. e.: - We have combinator parser with unbiased choice. Unfortunately, it is not monadic, but it is Applicative and Arrow - We can embed monad, for example, to handle semantic errors - We can test parsing errors before executing embedded monadic action Additionally we solved 4 remaining problems mentioned above, i. e.: - Handling left-recursive grammars is as simple as right-recursive ones (thanks to Earley's RecursiveDo) - Parsing errors are ok - We track locations and we can embed them into semantic errors - We have relatively good speed thanks to Earley What else? We can test grammar for ambiguity using https://hackage.haskell.org/package/Earley-0.13.0.1/docs/Text-Earley.html#v… (I didn't wrap this function, but this can easily be done). Personally I think that my parsing library is simply best. :) And that one should always use it instead of all others. Why I think this? Because: - We all know that CFG is better than PEG, i. e. unbiased choice is better that biased - I don't want to merely produce AST, I want to process information while I parse, and this processing will uncover some semantic errors - So I want unbiased choice with handling semantic errors - The only existing solution, which can do this is my library (and also "happy") - But "happy" doesn't automatically track locations (as well as I know it tracks lines, but not columns) - So the best parsing solution is my library :) My library has another advantage over happy: by extensive use of Alternative's "many" (and arrow banana brackets) you can write things, which are impossible to write in happy. Consider this artificial example (subset of Pascal): --- var a: integer; b: integer; begin a := b + c; end. --- This is its parser, which uses my library (completely untested): --- arrowRule (proc () -> do { sym TVar -< (); declated <- many (ident <* sym TColon <* sym TInteger <* sym TSemicolon) -< (); sym TBegin -< (); -- Banana brackets (|many (do { x <- ident -< (); lift -< when (x `notElem` declated) $ Left "Undeclated identifier"; sym TAssign -< (); -- My library doesn't have "sepBy", but it can be easily created (|sepBy (do { y <- ident -< (); lift -< when (y `notElem` declated) $ Left "Undeclated identifier"; returnA -< (); })|) [TPlus]; sym TSemicolon -< (); returnA -< (); |); sym TEnd -< (); sym TDot -< (); returnA -< (); }) --- This is impossible to write similar code using "happy" with similar ergonomics, because in happy we would not have access to "declared" inside production for sum. The only way we can access "declared" is using state monad (for example, StateT) and put this "declared" into this state monad. But in my library you don't have to use any StateT! Now let me say why mentioned "anti-arrow" style is not enough. Let's try to rewrite this Pascal example using anti-arrow style: --- antiArrowLift $ do { -- ApplicativeDo sym TVar; declated <- many (ident <* sym TColon <* sym TInteger <* sym TSemicolon); sym TBegin; many $ antiArrowLift $ do { x <- ident; sym TAssign; -- My library doesn't have "sepBy", but it can be easily created sepBy [TPlus] $ antiArrowLift $ do { y <- ident; pure $ when (y `notElem` declated) $ Left "Undeclated identifier"; -- Oops }; sym TSemicolon; pure $ when (x `notElem` declated) $ Left "Undeclated identifier"; -- Oops }; sym TEnd; sym TDot; pure (); } --- Looks good. But there is a huge problem here: look at lines marked as "Oops". They refer to "declared", but they cannot refer to it, because outer "do" is ApplicativeDo. So, yes, merely Applicative is not enough. Does my library have disadvantages? Of course, it has! - It is not monadic - It cannot statically check that grammar is element of LR(1) set (as well as I understand, happy can do this) - My library has relatively good speed asymptotic (same as Earley), but it is still not fastest - My library will freeze on infinitely ambiguous grammars. Attempting to check such grammar for ambiguity using Earley's "upTo" will cause freezing, too. See also: https://github.com/ollef/Earley/issues/54 - My library is based on unbiased choice and CFG (as opposed to biased choice and PEG). I consider this as advantage, but my library will not go if you want to parse language defined by some PEG My library is unfinished. The following things are needed: - We need combinator similar to Alternative's "many", but every item should have access to already parsed part of list. Such combinator should be made to be used by banana brackets - We need combinators similar to parsec's chainl and chainr (my library already supports left and right recursion thanks to Earley, but still such combinators would be useful) - Already mentioned "sepBy" - I didn't wrap all Earley functionality, for example, <?> is left unwrapped I don't have motivation for fix this things, because I decided to switch to Rust as my main language. Final notes - It is quite possible that I actually need attribute grammars or syntax-directed translation. I didn't explore this - I suspect that my parser is arrow transformer (whatever this means) Side note: I really want some pastebin for reproducible shell scripts (possibly dockerfiles), do you know such? Answer me if you have any questions. == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

2 3

Help understanding John Hughes' "The Design of a Pretty-printing Library"
by Galaxy Being 09 Jul '21

09 Jul '21

Getting stuck in *Real World Haskell*'s chapter on pretty printing (chap 5), I decided to take a look at one of the suggested sources, i.e., John Hughes' *The Design of a Pretty-printing Library <https://www.researchgate.net/publication/226525714_The_Design_of_a_Pretty-p…>*. Not that I fully got the first three section, still, let me skip ahead to section 4, *Designing a Sequence Type *where we're designing a supposedly generic sequence type, I'm guessing in the same universal, fundamental way that Peano's Axioms give a generic underpinning of the natural numbers. Good. I get it. This is why Haskell is unique. So he says we take the following *signature* as our starting point nil :: Seq a unit :: a -> Seq a cat :: Seq a -> Seq a -> Seq a list :: Seq a -> [a] where nil , unit , and cat give us ways to build sequences, and list is an *observation *[explained before]. The correspondence with the usual list operations is nil = [] unit x = [x] cat = (++) These operations are to satisfy the following laws: xs `cat` ( ys `cat` zs ) = ( xs `cat` ys ) `cat` zs nil `cat` xs = xs xs `cat` nil = xs list nil = [] list ( unit x `cat` xs ) = x : list xs My first question is why must we satisfy these laws? Where did these laws come from? Is this a universal truth thing? I've heard the word *monoid *and *semigroup* tossed around. Is this germane here? Next in *4.1 Term Representation* I'm immediately lost with the concept of *term. *On a hunch, I borrowed a book *Term Rewriting and All That *from Baader and Nipkow which I'm sure goes very deep into the concept of terms, but I'm not there yet. What is meant by *term*? As 4.1 continues, confusing is this passage The most direct way to represent values of [the?] sequence type is just as terms of the algebra [huh?], for example using data Seq a = Nil j Unit a j Seq a `Cat` Seq a But this trivial representation does not exploit the algebraic laws that we know to hold [huh?], and moreover the list observation will be a little tricky to de ne (ideally we would like to implement observations by very simple, non-recursive functions: the real work should be done in the implementations of the Seq operators themselves). Instead, we may choose a restricted subset of terms -- call them simplified forms -- into which every term can be put using the algebraic laws. Then we can represent sequences using a datatype that represents the syntax of simplified forms. In this case, there is an obvious candidate for simplified forms: terms of the form nil and unit x `cat` xs , where xs is also in simplified form. Simplified forms can be represented using the type data Seq a = Nil j a `UnitCat` Seq a with the interpretation Nil = nil x `UnitCat` xs = unit x `cat` xs All of this presupposes much math lore that I'm hereby asking someone on this mailing list to point me towards. I threw in a few [huh?] as specific points, but in general, I'm not there yet. Any explanations appreciated. ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

3 2

IFL'21 Third call for papers
by Pieter Koopman 09 Jul '21

09 Jul '21

================================================================================ IFL 2021 33rd Symposium on Implementation and Application of Functional Languages venue: online 1 - 3 September 2021 https://ifl21.cs.ru.nl <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> ================================================================================ News - Paper submission details. - Registration information added Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2021 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Industrial track and topics of interest This year's edition of IFL explicitly solicits original work concerning *applications* of functional programming in industry and academia. These contributions will be reviewed by experts with an industrial background. Topics of interest to IFL include, but are not limited to: * language concepts * type systems, type checking, type inferencing * compilation techniques * staged compilation * run-time function specialisation * run-time code generation * partial evaluation * (abstract) interpretation * meta-programming * generic programming * automatic program generation * array processing * concurrent/parallel programming * concurrent/parallel program execution * embedded systems * web applications * (embedded) domain-specific languages * security * novel memory management techniques * run-time profiling performance measurements * debugging and tracing * testing and proofing * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * applications of functional programming in the industry, including ** functional programming techniques for large applications ** successes of the application functional programming ** challenges for functional programming encountered ** any topic related to the application of functional programming that is interesting for the IFL community Post-symposium peer-review Following IFL tradition, IFL 2021 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chairs to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. Moreover, the proceedings will also be made publicly available as open access. Important dates Submission deadline of draft papers: 17 August 2021 Notification of acceptance for presentation: 19 August 2021 Registration deadline: 30 August 2021 IFL Symposium: 1-3 September 2021 Submission of papers for proceedings: 6 December 2021 Notification of acceptance: 3 February 2022 Camera-ready version: 15 March 2022 Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . (For LaTeX users, start your document with \documentclass[format=sigconf]{acmart}.) Note that this format has a rather long but limited list of packages that can be used. Please make sure that your document adheres to this list. The submission Web page for IFL21 is https://easychair.org/conferences/?conf=ifl21 <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> . Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Organisation IFL 2021 Chairs: Pieter Koopman and Peter Achten, Radboud University, The Netherlands IFL Publicity chair: Pieter Koopman, Radboud University, The Netherlands PC: Peter Achten (co-chair) - Radboud University, Netherlands Thomas van Binsbergen - University of Amsterdam, Netherlands Edwin Brady - University of St. Andrews, Scotland Laura Castro - University of A Coruña, Spain Youyou Cong - Tokyo Institute of Technology, Japan Olaf Chitil - University of Kent, England Andy Gill - University of Kansas, USA Clemens Grelck - University of Amsterdam, Netherlands John Hughes - Chalmers University, Sweden Pieter Koopman (co-chair) - Radboud University, Netherlands Cynthia Kop - Radboud University, Netherlands Jay McCarthey - University of Massachussetts Lowell, USA Neil Mitchell - Facebook, England Jan De Muijnck-Hughes - Glasgow University, Scotland Keiko Nakata - SAP Innovation Center Potsdam, Germany Jurriën Stutterheim - Standard Chartered, Singapore Simon Thompson - University of Kent, England Melinda Tóth - Eötvos Loránd University, Hungary Phil Trinder - Glasgow University, Scotland Meng Wang - University of Bristol, England Viktória Zsók - Eötvos Loránd University, Hungary Virtual symposium Because of the Covid-19 pandemic, this year IFL 2021 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. Registration Please use the below link to register for IFL 2021: https://docs.google.com/forms/d/e/1FAIpQLSdMFjo-GumKjk4i7szs7n4DhWqKt96t8of… <https://ifl21-publicity-dot-yamm-track.appspot.com/Redirect?ukey=1NdKhGOLpm…> Thanks to the sponsors and the support of the Radboud university registration is free of charge. [image: beacon]

1 0

Re: [Haskell-cafe] Where have the discussions moved to?
by Anthony Clayden 08 Jul '21

08 Jul '21

Yes I miss the free-and-easy atmosphere of the cafe. As of 9/10 years ago, we thought we'd nearly figured out how to fix the bogusness with FunDeps. And there were several ideas for better records. But no, GHC's FunDeps are just as bad as 2006; records have got a bit of lipstick. My take is that GHC has got so loaded with features, it's almost impossible to engineer in any 'tweaks'. So there has to be a bloated bureaucratic proposals process to make sure nothing gets broken. No free-wheeling what-if kind of discussion. Reddit I find almost impossible to follow. The Discourse site seems to be too much cut-and-dried. If you want to peek at what code people are cutting, StackOverflow gets some surprising material. But yeah. Haskell is different these days. In a way I don't like. It doesn't feel like 'popularity and community has expanded'. AntC

1 0

Re: [Haskell-cafe] Prolog-style list syntax?
by Anthony Clayden 08 Jul '21

08 Jul '21

Ok thank you for the feedback, I get the message not to re-purpose currently valid syntax. For that reason, this won't fly: I see no technical issues in allowing > something like `[ x, y || ys]` `||` is already an operator in the Prelude. > [x, y ,: ys ] -- ? not currently valid We could make list syntax work harder > [x, y ,:+ ys ] Means desugar the commas by applying constructor `:+` instead of `:`. That could be in general any constructor starting `:`. Or indeed could be a pattern synonym starting `:`, which is a 'smart constructor' to build the list maintaining some invariant.

3 4

FMCAD Student Forum CFP (Deadline Sat July 10)
by Mark Santolucito 08 Jul '21

08 Jul '21

# Student Forum Continuing the tradition of the previous years, FMCAD 2021 is hosting a Student Forum that provides a platform for students at any career stage (undergraduate or graduate) to introduce their research to the wider Formal Methods community, and solicit feedback. The Student Forum will be held in a hybrid format, online via video conferencing. ## Submissions Submissions must be short reports describing research ideas or ongoing work that the student is currently pursuing. Joint submissions from two students are allowed, provided the students contributed equally to the work - however, joint submissions must be presented by a single student. The topic of the reports must be within the scope of the FMCAD conference. These reports will NOT be published, thus we welcome reports based on already submitted/published papers. However, the novel aspects to be addressed in future work must be clearly described. Submissions should follow the same formatting guidelines as those for regular FMCAD conference submissions, except that the length is limited to 2 pages IEEE format, including all figures and references. ## Important Dates - Student forum submission: July 10, 2021 - Student forum notification: Aug 6, 2021 These deadlines are 11:59 pm AoE (Anywhere on Earth) More info here: https://fmcad.org/FMCAD21/student_forum/ ## Main Activities ### Student Forum Talks. Each student will give a lightning talk. In the case that a student is attending FMCAD physically, the talk will be given in-person at the conference. In the case that a student is attending FMCAD remotely, the talk will be given over Zoom. ### Discussion Groups. Students will have the opportunity to explain and discuss their work in small groups. More details to come on the logistics of discussion for remote participants. Submissions for the event must be short reports describing research ideas or ongoing work that the student is currently pursuing, and must be within the scope of FMCAD. Work, part of which has been previously published, will be considered; the novel aspect to be addressed in future work must be clearly described in such cases. All submissions will be reviewed by a subgroup of FMCAD committee members. ## Format The event will consist of short presentations by the student authors of each accepted submission, and of a virtual poster session. All participants of the conference are encouraged to attend the talks, ask questions and discuss with their fellow students in the virtual post sessions. Instructions for the preparation of the talks and poster sessions will be announced on notification of acceptance. ## Visibility Accepted submissions will be listed, with title and author name, in the event description in the conference proceedings. The authors will also have the option to upload their slide deck/poster/presentation to the FMCAD website. The report itself will not appear in the FMCAD proceedings; thus, the presentation at FMCAD should not interfere with potential future submissions of this research (to FMCAD or elsewhere). The best contributions (determined by public vote by attendees) will be given public recognition and a certificate at the event. ***Forum Chair*** Mark Santolucito (msantolu(a)barnard.edu) chairs the Student Forum. Feel free to send an email if you have questions about the event.

1 0

Hyrum's law (Was: [RFC] Support Unicode characters in instance Show String)
by Henning Thielemann 08 Jul '21

08 Jul '21

moving to Haskell Cafe On Thu, 8 Jul 2021, Bardur Arantsson wrote: > On 08/07/2021 17.53, Oleg Grenrus wrote: > > [--snip--] > >> >> 78 out of 2819 tests failed (35.88s) >> > > The use of Show in 'golden' test suites is interesting because Show > doesn't really guarantee any real form of stability in its output. > > I guess Hyrum's Law applies here too. > > Anyway... just an idle observation. Obviously, breaking loads of test > suites is going to be hard to swallow. I found this explanation: https://www.hyrumslaw.com/ Nice to have a name for this observation. I think the problem can be relaxed if there are multiple implementations for the same interface. But then you often find, that the implementations do not even adhere to the interface, thus people start guessing what the interface actually means. I hope that in the future we can describe interfaces more formally, such that a user knows what he can rely on.

3 2

Where have the discussions moved to?
by Carette, Jacques 08 Jul '21

08 Jul '21

Haskell Café used to be quite active. But in the last 2 years, at least, there have been much less traffic. In the same time frame, Haskell's popularity and community has expanded greatly. The logical conclusion is that discussions have moved elsewhere. I know that, for example, there are at times a large amount of discussion happening via github on the proposals [1] (in fact, so much so that I unsubscribed). I am aware that the community page [2] does mention quite a few places - too many. Is there one of those places where the kinds of discussions that used to happen here have moved to? Jacques [1] https://github.com/ghc-proposals/ghc-proposals [2] https://www.haskell.org/community/

3 2

[ANN] Copilot 3.4 - hard realtime C runtime verification
by Frank Dedden 08 Jul '21

08 Jul '21

Dear all, We are pleased to announce the release of Copilot 3.4, a stream-based DSL for writing and monitoring embedded C programs, with an emphasis on correctness and hard realtime requirements. Copilot is typically used as a high-level runtime verification framework, and supports temporal logic (LTL, PTLTL and MTL), clocks and voting algorithms. Among others, Copilot has been used at the Safety Critical Avionics Systems Branch of NASA Langley Research Center for monitoring test flights of drones. This release introduces a number of bug fixes and deprecates functions that have been superseded. The newest release is available on hackage [1]. For more information, including documentation, examples and links to the source code, please visit the webpage [2]. Current emphasis is on facilitating the use with other systems, and improving the codebase in terms of stability and test coverage. Users are encouraged to participate by opening issues and asking questions via our github repo [3]. Kind regards, The Copilot developers: - Frank Dedden - Alwyn Goodloe - Ivan Perez [1] https://hackage.haskell.org/package/copilot [2] https://copilot-language.github.io [3] https://github.com/Copilot-Language/copilot

1 0

How to debug SQL disconnect error
by Olaf Klinke 07 Jul '21

07 Jul '21

Dear Café, How can I go about examining an SQL error [1] when using persistent- odbc to access an MS SQL database? Set up a pristine MS SQL server 2012. Installed the driver on Debian using apt-get install msodbcsql17. Upon running either of persitent's printMigration or runMigration, the disconnect produces an error: *** Exception: SqlError {seState = "["25000"]", seNativeError = -1, seErrorMsg = "freeDbcIfNotAlready/SQLDisconnect: ["0: [Microsoft][ODBC Driver 17 for SQL Server]Invalid transaction state"]"} Running the printed SQL statements with isql executes allright, so it is not the particular migration at fault here. Presently I don't even know whether persistent or persistent-odbc or any false assumptions about the connection configuration is the cause. Thanks in advance Olaf [1] https://github.com/gbwey/persistent-odbc/issues/26

1 0

FMBC 2021 - Call for Participation
by Bruno Bernardo 05 Jul '21

05 Jul '21

[ Please distribute, apologies for multiple postings. ] ======================================================================== 3rd International Workshop on Formal Methods for Blockchains (FMBC) 2021 - Call for Participation https://fmbc.gitlab.io/2021 July 18 and 19, 2021, Online, 8AM-10AM PDT Co-located with the 33rd International Conference on Computer-Aided Verification (CAV 2021) http://i-cav.org/2021/ --------------------------------------------------------- The FMBC workshop is a forum to identify theoretical and practical approaches of formal methods for Blockchain technology. Topics include, but are not limited to: * Formal models of Blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for Blockchain-specific cryptographic primitives or protocols * Design and implementation of Smart Contract languages * Verification of Smart Contracts The list of lightning talks and conditionally accepted papers is available on the FMBC 2021 website: https://fmbc.gitlab.io/2021/program.html There will be one keynote by David Dill, Lead Researcher on Blockchain at Novi/Facebook and professor emeritus at Stanford University, USA. Registration Registration to FMBC 2021 is done through the CAV 2021 registration form: http://i-cav.org/2021/attending/ (*Early bird deadline is July 9.*)

1 0

ANN: hledger-1.22
by Simon Michael 04 Jul '21

04 Jul '21

I'm pleased to announce hledger 1.22 ! https://hledger.org/release-notes.html#hledger-1-22 describes the user-visible changes. Highlights include: - Optimisations: about 20% faster overall, with register about 2x faster and 4x more memory-efficient - Bugfixes, including fixes for several regressions. Thank you to the following release contributors this time around: Felix Yan, crocket, Eric Mertens, Damien Cassou, charukiewicz, Garret McGraw, and especially Stephen Morgan. hledger (https://hledger.org) is a dependable, cross-platform "plain text accounting" tool, with command-line, terminal and web interfaces. It is an actively maintained, largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track money, time, investments, cryptocurrencies, inventory and more. See also the Plain Text Accounting site (https://plaintextaccounting.org) https://hledger.org/download shows all the ways to install hledger on mac, windows or unix (stack, cabal, brew, nix, CI binaries, your package manager..). Or, run this bash script to install or upgrade to the latest release: $ curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… $ less hledger-install.sh # security review $ bash hledger-install.sh New users, check out https://hledger.org/quickstart or the tutorials (with pictures!) at hledger.org -> FIRST STEPS or the https://hledger.org/videos.html. To get help, see https://hledger.org#help, and join one of our chat rooms: - #hledger:matrix.org (http://matrix.hledger.org) - #hledger:libera.chat (http://irc.hledger.org) Beginners and experts, contributors, sponsors, and all feedback are most welcome! Wishing you health and prosperity, -Simon

1 0