- Haskell-Cafe - Haskell.org

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

14 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 11 Jul '21

11 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 10 Jul '21

10 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 09 Jul '21

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

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

09 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

Spam Control
by Gershom B 30 Jun '21

30 Jun '21

On Jun 29, 2021, 4:57 AM -0400, Ivan Perez <ivanperezdominguez(a)gmail.com>, wrote: > Can we please permanently ban this person and everyone from the confscience.com domain? > > Thanks, > > Ivan Done. —Gershom

1 0

Using Data.String.Conversions
by Galaxy Being 30 Jun '21

30 Jun '21

I would simply like to use Data.String.Conversions, specifically the cs function while I'm in my global ghci REPL. Here's the code I'm working on (from here <https://zacwood.me/posts/2020-12-29-dates-ihp/>) parseDay' :: String -> Maybe Day parseDay' = parseTimeM True defaultTimeLocale "%Y-%m-%d" then mydate = getCurrentTime (Data.Time imported just fine.) parseDay' $ takeWhile ('T' /=) (cs mydate) My problem is I can import and expose Data.Time, but Data.String.Conversions will not import to my global REPL. Any tips on doing this project-based would be enlightening too. ⨽ Lawrence Bottorff Grand Marais, MN, USA borgauf(a)gmail.com

3 5

Re: [Haskell-cafe] Prolog-style list syntax?
by Johannes Waldmann 29 Jun '21

29 Jun '21

> `[ x, y, z | zs ]` is also valid; [...] > That structure is particularly ugly in Haskell syntax. how so? `x : y : z : zs` Prolog list syntax is ugly here because the "cons" operator (|) needs special parentheses. Well, a similar thing in Haskell ist the ".." (enumFromTo) operator. For syntactic generality, you could go full Agda https://agda.readthedocs.io/en/v2.6.0.1/language/mixfix-operators.html but I'm not sure whether brackets could be "name parts" - J.W.

9 10

Re: [Haskell-cafe] [Haskell Cafe] How to debug stack build failure? (YAMAMOTO Yuji)
by David Banas 29 Jun '21

29 Jun '21

$ stack build -v Version 2.7.1, Git revision 8afe0c2932716b0441cf4440d6942c59568b6b19 x86_64 hpack-0.34.4 {snip} 2021-06-28 16:20:17.903335: [info] comonad > configure 2021-06-28 16:20:17.905709: [debug] Run process within /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/: /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/bin/ghc-8.8.4 --make -odir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -hidir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -i -i. -clear-package-db -global-package-db -package-db=/home/david/.stack/snapshots/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -package-db=/home/david/prj/haskarch/.stack-work/install/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -hide-all-packages -package-id=Cabal-3.0.1.0 -package-id=base-4.13.0.0 -package-id=cabal-doctest-1.0.8-2wQRz9ec1yB5lMDRmEgBWB -optP-include -optP/tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup_macros.h /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/Setup.lhs /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup -threaded 2021-06-28 16:20:17.943489: [warn] comonad > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../haskeline-0.7.5.0/libHShaskeline-0.7.5.0-ghc8.8.4.so) 2021-06-28 16:20:17.944049: [warn] comonad > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../ghc-8.8.4/libHSghc-8.8.4-ghc8.8.4.so) 2021-06-28 16:20:17.944266: [warn] comonad > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc8.8.4.so) 2021-06-28 16:20:18.075957: [info] comonad > [1 of 2] Compiling Main ( /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/Setup.lhs, /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/Main.o ) 2021-06-28 16:20:18.195209: [info] comonad > [2 of 2] Compiling StackSetupShim ( /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/StackSetupShim.o ) 2021-06-28 16:20:18.353001: [info] comonad > Linking /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup ... 2021-06-28 16:20:20.173612: [debug] Process finished in 2267ms: /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/bin/ghc-8.8.4 --make -odir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -hidir /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup -i -i. -clear-package-db -global-package-db -package-db=/home/david/.stack/snapshots/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -package-db=/home/david/prj/haskarch/.stack-work/install/x86_64-linux/6d64ef72f82ddc8525a7ddc3720c5e56c966b1ecb86aceed15c48dc305ef2f2c/8.8.4/pkgdb -hide-all-packages -package-id=Cabal-3.0.1.0 -package-id=base-4.13.0.0 -package-id=cabal-doctest-1.0.8-2wQRz9ec1yB5lMDRmEgBWB -optP-include -optP/tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup_macros.h /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/Setup.lhs /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs -main-is StackSetupShim.mainOverride -o /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup -threaded Progress 1/10 2021-06-28 16:20:20.191005: [error] Did not find executable at specified path: /tmp/stack-d3c8d82a69b145e0/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup > On Jun 29, 2021, at 5:00 AM, haskell-cafe-request(a)haskell.org wrote: > > Try stack build -v firstable.

1 0

Prolog-style list syntax?
by Anthony Clayden 29 Jun '21

29 Jun '21

One of the annoying (to me) inconsistencies with Haskell syntax is that `[ ]` means 'here comes a list'; but for the most common way to write a list, you can't use `[ ]`: > elem x [] = False > elem x ( y: ys ) = ... Prolog syntax has lists, signalled by `[ ]`: [], [1], [2, 3], [4, 5, 6], [[7, 8], [9, 10, 11]] are all valid list literals. For cons it also uses `[ ]` syntax > elem x [y | ys ] = ... `[ x, y, z | zs ]` is also valid; pattern match or build a list with at least 3 elements, where `zs` is the tail -- 4th element onwards (if any). That structure is particularly ugly in Haskell syntax. Neither `|` inside `[ ]` in a pattern nor a comma-list with `|` inside `[ ]` is valid H98 syntax, nor valid in GHC extensions AFAICT. In an expression, `[ x | xs ]` could be taken as a list comprehension, which is I guess why Haskell didn't follow Prolog. I've come across another theorem-prover that follows Prolog style, except it uses `:` instead of `|` inside `[ ]`. Unfortunately ... > elem x [ y: ys ] = ... Is valid syntax, where `:` is cons, so this is a nested list. I'm thinking that's relatively uncommon, and means the same as `[ ( y: ys ) ]`. Would anyone be violently pro or anti changing the meaning of `:` appearing at top level in `[ ]` to mean cons-tail? AntC

4 4

Help Improving Conduit Performance
by Matthew Leach 29 Jun '21

29 Jun '21

Hi there! I'm currently trying to write a program for the creation of IQ samples from various sound files; AM is my current focus. This seems like a really good application for the conduit library. I've so far got: --8<---------------cut here---------------start------------->8--- run :: AMOptions -> IO () run opts = do (info, Just (aSamps :: SV.Buffer Float)) <- SF.readFile $ inputFile opts putStr "Processing samples... " hFlush stdout runConduitRes $ yieldMany (SV.fromBuffer aSamps) .| modulateAM (modIndex opts) .| zeroStuff (upsample opts) .| mapC renderSample .| unsafeBuilderToByteString .| sinkFile (outputFile opts) --8<---------------cut here---------------end--------------->8--- However, this is *slow*. It takes over 40 seconds to run; I've previously implemented the above without using streaming and this code took approx 3 seconds to run with the same input. I compiled the code for profiling and it appears as though the main culprit is the function `injectLeftovers': --8<---------------cut here---------------start------------->8--- Mon Jun 28 22:55 2021 Time and Allocation Profiling Report (Final) ayeQ +RTS -p -RTS am -i /Users/matthew/40.flac -o /Users/matthew/out.cfile -u 15 -m 150 total time = 76.32 secs (76322 ticks @ 1000 us, 1 processor) total alloc = 445,275,685,456 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc injectLeftovers Data.Conduit.Internal.Pipe src/Data/Conduit/Internal/Pipe.hs:(410,1)-(418,38) 79.5 81.6 runPipe Data.Conduit.Internal.Pipe src/Data/Conduit/Internal/Pipe.hs:(395,1)-(399,33) 7.1 5.0 awaitForever Data.Conduit.Internal.Conduit src/Data/Conduit/Internal/Conduit.hs:(950,1)-(952,10) 5.3 3.7 run AM AM.hs:(62,1)-(77,88) 4.4 7.0 renderSample Render Render.hs:8:1-58 3.5 2.5 --8<---------------cut here---------------end--------------->8--- I'm at a bit of a loss as to where to start looking for why this particlar function is using so many resources, or which part of the pipeline is causing the issue. The custom pieces of code that I've got in the pipeline are: --8<---------------cut here---------------start------------->8--- modulateAM' :: Int -> Float -> IQ modulateAM' modIdx s = (base + amp) :+ 0.0 where x = fromIntegral modIdx / 200 amp = s * x base = 1 - x modulateAM :: Monad m => Int -> ConduitT Float IQ m () modulateAM = mapC . modulateAM' --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- zeroStuff :: Monad m => Int -> ConduitT IQ IQ m () zeroStuff factor = awaitForever (\v -> yield v >> replicateM_ (factor - 1) (yield zero)) where zero = 0 :+ 0 --8<---------------cut here---------------end--------------->8--- --8<---------------cut here---------------start------------->8--- renderSample :: IQ -> Builder renderSample (real :+ imag) = floatLE real <> floatLE imag --8<---------------cut here---------------end--------------->8--- Any help would be appreciated! Regards, -- Matt

1 0

Re: [Haskell-cafe] Prolog-style list syntax?
by Johannes Waldmann 29 Jun '21

29 Jun '21

>> but it would be interesting if this worked: >> >> [x, y, z] ++ zs = list this works in Curry; a functional-logic PL, very roughly: Prolog semantics (in a sane way) with Haskell syntax and typing https://curry.pages.ps.informatik.uni-kiel.de/curry-lang.org/ - J.W.

1 0

How to debug stack build failure?
by David Banas 29 Jun '21

29 Jun '21

Anyone know how to start debugging this? $ stack build comonad > configure comonad > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../haskeline-0.7.5.0/libHShaskeline-0.7.5.0-ghc8.8.4.so) comonad > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../ghc-8.8.4/libHSghc-8.8.4-ghc8.8.4.so) comonad > /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/ghc: /lib64/libtinfo.so.5: no version information available (required by /home/david/.stack/programs/x86_64-linux/ghc-8.8.4/lib/ghc-8.8.4/bin/../terminfo-0.4.1.4/libHSterminfo-0.4.1.4-ghc8.8.4.so) comonad > [1 of 2] Compiling Main ( /tmp/stack-038db506ab1301e1/comonad-5.0.6/Setup.lhs, /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/Main.o ) comonad > [2 of 2] Compiling StackSetupShim ( /home/david/.stack/setup-exe-src/setup-shim-mPHDZzAJ.hs, /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/StackSetupShim.o ) comonad > Linking /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup ... Progress 1/10 Did not find executable at specified path: /tmp/stack-038db506ab1301e1/comonad-5.0.6/.stack-work/dist/x86_64-linux/Cabal-3.0.1.0/setup/setup

2 1

Munich Virtual Haskell Meeting, 2021-06-29 @ 19:30
by Leah Neukirchen 27 Jun '21

27 Jun '21

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Tuesday, June 29 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

How to eliminate Cabal warning message, re: internal library version number?
by David Banas 27 Jun '21

27 Jun '21

How do I eliminate these messages from my `cabal build` output? Warning: The package has an extraneous version range for a dependency on an internal library: {proj_name} >=0 && ==0.1.0.0. This version range includes the current package but isn't needed as the current package's library will always be used.

4 3

How to fix linker error on MacOS
by David Banas 27 Jun '21

27 Jun '21

How do I fix this (from `cabal build`)? Undefined symbols for architecture x86_64: "___darwin_check_fd_set_overflow", referenced from: _awaitEvent in libHSrts.a(Select.o) System Info: ========= $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.10.5 $ cabal --version cabal-install version 3.4.0.0 compiled using version 3.4.0.0 of the Cabal library dbanas@Davids-MBP-2:~/Documents/Luminous/Projects/haskarch $ sw_vers ProductName: Mac OS X ProductVersion: 10.14.6 BuildVersion: 18G9216

2 1

Why can't I seem to use environment variables in my cabal file?
by David Banas 26 Jun '21

26 Jun '21

I’m trying to make use of an environment variable in my cabal file: ${ENV_VAR}, but I don’t think its value is getting used correctly. Is this a known issue? Workaround?

2 1

Cabal v misses changes to cxx-files: files?
by David Banas 25 Jun '21

25 Jun '21

Using Cabal v3.2.0.0 and with the following stanza in my *.cabal file: executable ex9 import: shared-properties main-is: src/ex/ex9.hs cxx-sources: src/ex/ex9.cpp {snip} if I edit the file: `src/ex/ex9.cpp`, and then execute: `cabal build`, I'm told: $ cabal build Up to date Is this a known issue? Is there a workaround? Thanks, -db

3 2

ICFP 2021: Second Call for Students Volunteers
by Jaemin Hong 24 Jun '21

24 Jun '21

Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'21 SECOND CALL FOR STUDENT VOLUNTEERS ========================================= ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'21 will take place **virtually** from Sun 22 - Fri 27 August 2021. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2021 student volunteer, you will get more visibility and be able to interact closely with researchers, academics and practitioners from various disciplines and discuss with other students from around the world. While the exact structure of the conference is still being discussed, job assignments for student volunteers will probably include: 1- Assisting with technical sessions, workshops, tutorials, Q&A sessions, social activities, and panels. 2- Helping to get authors' videos prepped and ready for broadcast. 3- Managing channels on a virtual event platform. To be considered as a student volunteer for ICFP, please fill in the following application form. https://forms.gle/cEXE4GfXzm24f6mF6 <https://forms.gle/cEXE4GfXzm24f6mF6> The permanent link to this form can be found on the official conference website. https://icfp21.sigplan.org/track/icfp-2021-student-volunteers <https://icfp21.sigplan.org/track/icfp-2021-student-volunteers> There is one remaining round of a call with the following deadline: * deadline for second round: July 16th, 2021 AoE (notification: July 20th)

1 0

Fwd: Is anyone running regular virtual Haskell hacking events?
by Chris Smith 24 Jun '21

24 Jun '21

Forwarding as I forgot to include the mailing list in my reply. ---------- Forwarded message --------- From: Chris Smith <cdsmith(a)gmail.com> Date: Wed, Jun 23, 2021 at 9:21 PM Subject: Re: [Haskell-cafe] Is anyone running regular virtual Haskell hacking events? To: Jeffrey Brown <jeffbrown.the(a)gmail.com> Jeffrey Brown <jeffbrown.the(a)gmail.com> wrote: > I think it's a great idea. What would helping you organize involve? > Great question. I think what I need most is: 1. Well before the event: a second brain to look at the plan and help think of things that can go wrong for some attendees, and what we might do to mitigate these factors, or anything else that should be done differently from what's in my head. 2. Shortly before the event: advertise! Make sure people know about it and are excited to come. 3. During the event: someone to play host a bit and help people find something to do, and generally be helpful to anyone who is lost or confused. That's not a role that I'm very good at, and I think it's more than a one-person job anyway. >

2 1

How to debug HSC to HS conversion failure?
by David Banas 23 Jun '21

23 Jun '21

I’m getting the following error in response to `cabal build`: running {pros_dir}/dist-newstyle/build/x86_64-osx/ghc-8.8.4/haskarchpriv-0.1.0.0/build/HaskArch/TLM2_hsc_make failed (exit code -11) rsp file was: “{proj_dir}/dist-newstyle/build/x86_64-osx/ghc-8.8.4/haskarchpriv-0.1.0.0/build/HaskArch/hsc2hscall86171-3.rsp" My project contains one *.hsc file, which is the target of the error above. How can I debug the cause of this? The “rsp” file is nowhere to be found; what is(was) it? And, is it a helpful debugging aid? If so, is there an option I can give, to preserve it? Thanks! -db

2 1

Is anyone running regular virtual Haskell hacking events?
by Chris Smith 23 Jun '21

23 Jun '21

I'm thinking of ideas, and wondering if anyone's beat me to this one. Before COVID-19, I organized a "co-hack" with the New York Haskell User Group one Saturday per month, where people would get together and write or discuss Haskell for several hours. I always had a great time, but... then COVID-19. Does something like this exist online? If not, I was just looking at Zoom, and realized they have breakout rooms where people can divide up and separately talk in groups. I was thinking of setting up an event something like this: Start: 9am Pacific / 12pm Eastern / 4pm GMT / 6pm CET - 15 minute intro and logistics - 30 minute Small group intros. Divide people up randomly into small groups to introduce themselves and talk about their Haskell stories and what they are working on. About 4-5 people per group (because 2 people feels too small, but too many people means shy people are afraid to speak up.) - 30 minute lightning talks and project pitches: Maybe 5 minutes / 3 slides max, sign up in advance or jump in and do a talk impulsively - 2.5 hours project time. Use for working together on projects, pair programming, teach and learn Haskell, etc. Use Zoom breakout groups and let people hop from room to room as desired. Pre-create some rooms for common activities (like "Beginner Questions", "Project Euler", etc.) Create some generic rooms people can jump in as they like for short collaborations. Create persistent project-specific rooms on demand. - 15 minute wrap-up. Finish: 1pm Pacific / 4pm Eastern / 8pm GMT / 10pm CET What does everyone think? I don't see any reason this couldn't go really well. The Cohack in New York was really fun, and I'd like to give it a shot. Anyone else motivated to help run this? If I can get at least one co-facilitator, I'll jump in and make it happen. I'll spring for the Zoom account. Probably use Meetup to take signups and manage scheduling, unless someone has another preference. Thanks, Chris Smith

3 3

Final Call for Talks: Haskell Implementors' Workshop @ ICFP'21
by Ningning Xie 23 Jun '21

23 Jun '21

Final Call for Talks ACM SIGPLAN Haskell Implementors' Workshop https://icfp21.sigplan.org/home/hiw-2021 Virtual, 22 Aug, 2021 Co-located with ICFP 2021 https://icfp21.sigplan.org/ New: Invited Speaker -------------------- Title: Haskell reinterpreted – large-scale real-world experience with the Mu compiler in Financial Markets Speaker: Bengt Marten Agren, Standard Chartered Bank Important dates --------------- Deadline: Wednesday, 30 June, 2021 (AoE) Notification: Wednesday, 14 July, 2021 Workshop: Sunday, 22 August, 2021 The 13th Haskell Implementors' Workshop is to be held alongside ICFP 2021 this year virtually. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2021. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. The Implementors' Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community encouraged to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are specially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw21.hotcrp.com/ We will also have lightning talks session. These have been very well received in recent years, and we aim to increase the time available to them. Lightning talks be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Logistics --------- Due to the on-going COVID-19 situation, ICFP (and, consequently, HIW) will be held remotely this year. However, the organizers are still working hard to provide for a great workshop experience. While we are sad that this year will lack the robust hallway track that is often the highlight of HIW, we believe that this remote workshop presents a unique opportunity to include more of the Haskell community in our discussion and explore new modes of communicating with our colleagues. We hope that you will join us in making this HIW as vibrant as any other. Program Committee ----------------- * Dominique Devriese (Vrije Universiteit Brussel) * Daan Leijen (Microsoft Research) * Andres Löh (Well-Typed LLP) * Julie Moronuki (Typeclass Consulting) * John Wiegley (DFINITY) * Ningning Xie (the University of Hong Kong) * Edward Z. Yang (Facebook AI Research) Contact ------- * Ningning Xie <xnning at hku.hk>

1 0

Re: [Haskell-cafe] Tips for debugging seg. faults?
by David Banas 22 Jun '21

22 Jun '21

Thank you, Viktor! Wrt/ `withForeignPtr`, you are suggesting that I use it, not that I avoid it; correct? Wrt/ “pinned memory”, could you give me a little more explanation? Thanks, -db :) > On Jun 20, 2021, at 5:00 AM, haskell-cafe-request(a)haskell.org wrote: > > Thus functions like `withForeignPtr` which try to make sure the the > referenced memory is not released too early. > > Buffer pointers should be to pinned memory, ...

4 3

Re: [Haskell-cafe] 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 22 Jun '21

22 Jun '21

Hi. Thanks for answer! I already wrote arrow parsing lib. I will publish it when I was done. Also, you forgot to add haskell-cafe(a)haskell.org to CC. Понедельник, 21 июня 2021, 21:53 +03:00 от "Olaf Klinke" <olf(a)aatal-apotheke.de>: > Dear Askar, > > your theorem is convincing. While a counterexample is sufficient for a > rigorous proof, I'll try to add some mathematical theory to this. Many > monad transformers are of the form FooT m a = g (m (f a)) where (f,g) > is an adjoint pair of functors. The Kleisli lifting operation (=<<) for > such a composite monad uses the Kleisli lifting of m. For your > application that means that you can not use monadic actions of your > monad transformer without executing the monadic actions of the > transformed monad m. I conjecture that any transformer FooT with the > property that FooT m is a monad provided m is a monad necessarily runs > m-actions. > > A transformer that does not require m to be a monad is the continuation > transformer ContT m r a = (a -> m r) -> m r. However, for this > transformer the lift operation is interdefinable with an operation m (m > r) -> m r so it seems that at least lift will run m-actions. > > As Chris Smith pointed out, this does not rule out that Applicative- > style parsing code may be able to prevent executing the m-actions. > > Olaf > == Askar Safin http://safinaskar.com https://sr.ht/~safinaskar https://github.com/safinaskar

1 0

Is `MonadBaseControl` dead?
by YueCompl 21 Jun '21

21 Jun '21

Greetings! This is also posted at https://www.reddit.com/r/haskell/comments/o4sggi/is_monadbasecontrol_dead/ <https://www.reddit.com/r/haskell/comments/o4sggi/is_monadbasecontrol_dead/> but I'd like to also seek wider help here. (Background issue I'm facing: https://github.com/snapframework/snap-core/issues/309) I think the functionality of [MonadUnliftIO](https://hackage.haskell.org/package/unliftio-core-0.2.0.1/do… is exactly what I want, but unfortunately [Snap](https://hackage.haskell.org/package/snap-core-1.0.4.2/docs/Snap-Core.… appears not eligible for: > the intuition is that a monad must have no monadic state, but may have monadic context. This essentially limits MonadUnliftIO to ReaderT and IdentityT transformers on top of IO. Then I found `Snap` [has a MonadBaseControl instance](https://hackage.haskell.org/package/snap-core-1.0.4.2/docs/src/Sn…, and thought it should work for me. But sadly to find it [losing states](https://github.com/snapframework/snap-core/issues/309). Also I failed to find a user side example of `MonadBaseControl` on Github ([as there're only instance impl. hits](https://github.com/search?l=Haskell&q=org%3Asnapframework+liftBaseWit…) so I have not way to verify whether that's due to my incorrect usage. Any way quoting u/snoyberg : https://github.com/fpco/unliftio/issues/17#issuecomment-363655106 > Continuation-based monads cannot have instances of MonadUnliftIO, the same as MonadBaseControl and MonadMask. Then I'm not sure `Snap`'s `MonadBaseControl` instance shall really work. Also seems there had been debates I'm not aware of with clue at: https://github.com/fpco/unliftio/tree/master/unliftio#monad-control > > The main contention until now is that unlifting in a transformer like > `StateT` is unsafe. This is not universally true: if only one action > is being unlifted, no ambiguity exists. So, for example, `try :: IO a > -> IO (Either e a)` can safely be unlifted in `StateT`, while `finally > :: IO a -> IO b -> IO a` cannot. > > `monad-control` allows us to unlift both styles. In theory, we could > write a variant of `lifted-base` that never does state discards, and > let `try` be more general than `finally`. In other words, this is an > advantage of `monad-control` over `MonadUnliftIO`. We've avoided > providing any such extra typeclass in this package though, for two > reasons: > > * `MonadUnliftIO` is a simple typeclass, easy to explain. We don't > want to complicated matters (`MonadBaseControl` is a notoriously > difficult to understand typeclass). This simplicity > is captured by the laws for `MonadUnliftIO`, which make the > behavior of the run functions close to that of the already familiar > `lift` and `liftIO`. > * Having this kind of split would be confusing in user code, when > suddenly `finally` is not available to us. We would rather encourage > [good practices](https://www.fpcomplete.com/blog/2017/06/readert-design-pattern) > from the beginning. > > Another distinction is that `monad-control` uses the `MonadBase` > style, allowing unlifting to arbitrary base monads. In this package, > we've elected to go with `MonadIO` style. This limits what we can do > (e.g., no unlifting to `STM`), but we went this way because: > > * In practice, we've found that the vast majority of cases are dealing > with `IO` > * The split in the ecosystem between constraints like `MonadBase IO` > and `MonadIO` leads to significant confusion, and `MonadIO` is by > far the more common constraints (with the typeclass existing in > `base`) > So is `MonadBaseControl` dead or alive? Any user side example for it?

1 0