- Haskell-Cafe - Haskell.org

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