- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] [hledger] ANN: hledger 1.30
by Simon Michael 02 Jun '23

02 Jun '23

> On Jun 2, 2023, at 00:55, Henning Thielemann <googlegroups(a)henning-thielemann.de> wrote: > > I can build with GHC-8.8.4, but with GHC-8.10 and later I get: > > > Hledger/Cli/Commands/Demo.hs:63:3: error: > • Exception when trying to run compile-time code: > /ram/cabal/tmp/src-191030/hledger-1.30/embeddedfiles/add.cast: openFile: does not exist (No such file or directory) > Code: embedFileRelative "embeddedfiles/add.cast" > • In the untyped splice: > $(embedFileRelative "embeddedfiles/add.cast") > | > 63 | $(embedFileRelative "embeddedfiles/add.cast"), -- https://asciinema.org/a/567935 The easiest way to start a journal (add) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thanks for the report; I have released hledger-1.30.1 on Hackage to fix this.

1 0

could not deduce Show compile error
by Zoran Bošnjak 02 Jun '23

02 Jun '23

Dear haskell cafe members, I would appreciate a suggestion how to fix compile error on this simple test program (I am using ghc 9.0.2). The idea is to have 'data Flow a b' unrestricted and create necessary constraints only when running/interpreting the flow. The problem is obviously an intermediate type 'b' in 'Compose', where the 'Show' instance is not deduced. I have a vague clue that some type families might be necessary to propagate Show constraint, or a type class with associated type family, but I don't know exactly how. --- import Prelude hiding ((.), id) import Control.Category data Flow a b where Id :: Flow a a Compose :: Flow a b -> Flow b c -> Flow a c instance Category Flow where id = Id (.) = flip Compose runFlow :: Show a => Flow a b -> a -> IO b runFlow f x = case f of Id -> print x >> pure x Compose f1 f2 -> runFlow f1 x >>= runFlow f2 main :: IO () main = runFlow (Id >>> Id) () --- The error is: • Could not deduce (Show b1) arising from a use of ‘runFlow’ from the context: Show a bound by the type signature for: runFlow :: forall a b. Show a => Flow a b -> a -> IO b at a02.hs:13:1-42 Possible fix: add (Show b1) to the context of the data constructor ‘Compose’ • In the second argument of ‘(>>=)’, namely ‘runFlow f2’ In the expression: runFlow f1 x >>= runFlow f2 In a case alternative: Compose f1 f2 -> runFlow f1 x >>= runFlow f2 | 16 | Compose f1 f2 -> runFlow f1 x >>= runFlow f2 | ^^^^^^^^^^ kind regards, Zoran

3 3

type error when specializing lens zooms in ghc >= 9.0
by Olaf Klinke 02 Jun '23

02 Jun '23

Dear Cafe, I'm an infrequent lens user so please forgive me if the below problem has a trivial solution. For a long time the documentation of Control.Lens.Zoom has been claiming that 'zoom' and 'magnify' can be specialized to the following types. {-# LANGUAGE RankNTypes #-} -- Type error with GHC 9.0.2 or 9.2.7, okay with GHC 8.8.4 import Control.Lens.Zoom (zoom,magnify) import Control.Lens.Type (Lens') import Control.Monad.RWS (RWS) zoomRWS :: Monoid w => Lens' s s' -> RWS r w s' a -> RWS r w s a zoomRWS = zoom magnifyRWS :: Monoid w => Lens' r r' -> RWS r' w s a -> RWS r w s a magnifyRWS = magnify Indeed GHC 8.8.4 compiles this happily (on lens-4.18.1), but 9.0.2 (on lens-5.0.1) throws nearly undecipherable errors, claiming that Lens' can not be matched with some more specialized type involving Magnified and LensLike. The source of Control.Lens.Zoom does not differ substantially between 4.18.1 and 5.0.1 so my guess is it is a type checker issue. Can anyone explain? On which bug tracker should I raise this issue, if it is indeed a valid one? (I pulled the above versions from stackage lts-16.31, -19.5 and -20.20, respectively and compiled with stack.) Thanks Olaf

4 6

[CfP][CONFLANG23] 2nd Workshop on Configuration Languages
by Yann Hamdaoui 02 Jun '23

02 Jun '23

Dear Haskellers, and maybe more generally programming language enthusiasts, I am happy to announce the 2nd Workshop on Configuration Languages, co-located at SPLASH 23, and focused on the quite peculiar (and thus, exciting!) space of designing configuration languages, and more general configuration and infrastructure management. Cheers, Yann CALL FOR PRESENTATIONS - 2nd Workshop on Configuration Languages 2023 (CONFLANG23) EVENT DETAILS Event: CONFLANG23, colocated at SPLASH 2023 Date: Tuesday 24 October 2023 Submission deadline: Friday 12 July 2023 Location: Cascais, Portugal Website: https://2023.splashcon.org/home/conflang-2023 OVERVIEW CONFLANG is a new workshop on the design, the usage and the tooling of configuration programming languages. CONFLANG aims at uniting language designers, industry practitioners and passionate hobbyists to share knowledge in any form. Topics of interest include, but are not limited to: - Infrastructure and configuration code maintenance and evolution - Specification learning and mining for configurations - Infrastructure and Configuration testing and verification - Infrastructure as Code and configuration repair - New languages for configuration - The application of language security and type theory to program configuration CALL FOR PRESENTATIONS The committee welcomes proposals for presentations: - Traditional talks on any theoretical or practical aspect of the usage, the tooling and the design of configuration languages - Experience and case study talks on the real world usage and deployment of configuration languages - Explorative talks and/or demos on experimenting with configuration languages and related tools SUBMISSION GUIDELINES Please submit an abstract (up to 600 words, excluding title, author names, and bibliography) of your proposed talk using the submission link provided below. - **Format**: 600 words maximum abstract (estimated between 1 and 1,5 pages) as a PDF, excluding title, author names, and bibliography. Any additional material will be considered at the discretion of the PC. - **URL** : https://conflang23.hotcrp.com/ PROGRAM CHAIRS - Yann Hamdaoui (Tweag) - Jürgen Cito (TU Wien and Facebook) - Mark Santolucito (Columbia University) - Marcel van Lohuizen (CUE Lang)

1 0

ANN: hledger 1.30
by Simon Michael 02 Jun '23

02 Jun '23

I'm pleased to announce hledger 1.30 ! Highlights: - Boolean queries - with the new `expr:` query type you can freely combined other queries with AND, OR, NOT and parentheses. - Easier CSV file management - you can now read a CSV .rules file, and let it fetch the data file from a downloads directory, simplifying CSV file management. - Built-in demos - a new `demo` command plays several asciinema casts to demonstrate features. We'll add more of these in future. - hledger-ui has a new Cash accounts screen, and now starts on the Menu screen. - The usual miscellaneous fixes. Thank you release contributors Chris Lemaire and Yehoshua Pesach Wallach. - https://github.com/simonmichael/hledger/releases/1.30 - https://hledger.org/release-notes.html#hledger-1-30 - https://hledger.org/install What is hledger ? - Fast, reliable, free, multicurrency, double-entry, plain text accounting software for unix, mac, windows, and the web - Built around human-readable, version-controllable plain text files - Inspired by and largely compatible with Ledger CLI, convertible to and from Beancount - Written in Haskell for reliability and longevity. For help getting started or more info, see https://hledger.org and join our Matrix/IRC chat or mail list: https://hledger.org/support . Newcomers, experts, contributors, sponsors, feedback are welcome! For more about plain text accounting, see https://plaintextaccounting.org . Live well and prosper, -Simon

1 0

property testing, point-free style
by Olaf Klinke 31 May '23

31 May '23

Dear Cafe, The expression \x -> f x == g x is a testable property, as long as values for x can be randomly generated. For clarity I'd prefer a point-free style, e.g. f ≡ g Are there extensions to QuickCheck that let me write this? The QuickCheck package itself does not seem to contain such an operator. My current work-around is a newtype ExtensionalEquality a b that holds two functions of type (a -> b) and a Testable instance for it. But I've got a hunch that I re-invented some wheel here. (My ExtensionalEquality is isomorphic to Refl (a -> b) (a -> b) but Refl ist conceptually about type equality, not term equality.) Thanks Olaf

3 3

Call for Papers: JFP Special Issue on Program Calculation
by Graham Hutton 30 May '23

30 May '23

Dear all, We're delighted to announce a Special Issue on Program Calculation for the Journal of Functional Programming. Please share, and submit your best papers! Best wishes, Graham Hutton and Nicolas Wu Guest Editors ================================================================== JFP Special Issue on Program Calculation We invite submissions to the Journal of Functional Programming Special Issue on Program Calculation: tinyurl.com/prog-calc Notification of intent : 20 October 2023 Submission deadline : 1 December 2023 SCOPE The idea of program calculation, in which programs are derived from specifications using equational reasoning techniques, has been a topic of interest in functional programming since its earliest days. In particular, the approach allows us to systematically discover how programs can be defined, while at the same time obtaining proofs that they are correct. The aim of this special issue is to document advances that have been made in the field of program calculation in recent years. TOPICS Full-length, archival-quality submissions are solicited on all aspects of program calculation and related topics. Specific topics of interest include but are not limited to: - Program derivation and transformation; - Inductive and co-inductive methods; - Recursion and co-recursion schemes; - Categorical and graphical methods; - Tool support and proof assistants; - Efficiency and resource usage; - Functional algorithm design; - Calculation case studies. The special issue will also consider papers on program calculation that are not traditional research papers. This may include pearls, surveys, tutorials or educational papers, which will be judged by the usual JFP standards for such submissions. Papers will be reviewed as regular JFP submissions, and acceptance in the special issue will be based on both JFP's quality standards and relevance to the theme. NOTIFICATION OF INTENT Authors must notify the special issue editors of their intent to submit by 20 October 2023. The notification of intent should be submitted by filling out the following form, which asks for data to help identify suitable reviewers: tinyurl.com/intent-to-submit If you miss the notification of intent deadline, but still wish to submit, please contact the special-issue editors. SUBMISSIONS Papers must be submitted by 1 December 2023. Submissions should be typeset in LaTeX using the JFP style file, and submitted through the JFP Manuscript Central system. Choose "Program Calculation" as the paper type, so it gets assigned to the special issue. Further author instructions are available from: tinyurl.com/JFP-instructions We welcome extended versions of conference or workshop papers. Such submissions must clearly describe the relationship with the initial publication, and must differ sufficiently that the author can assign copyright to Cambridge University Press. Prospective authors are welcome to discuss submissions with the editors to ensure compliance. SPECIAL-ISSUE EDITORS Graham Hutton <graham.hutton(a)nottingham.ac.uk> Nicolas Wu <n.wu(a)imperial.ac.uk> IMPORTANT DATES We anticipate the following schedule: 20 October 2023 : Notification-of-intent deadline 1 December 2023 : Submission deadline 22 March 2024 : First round of reviews 12 July 2024 : Revision deadline 4 October 2024 : Second round of reviews, if applicable 29 November 2024 : Final versions due ================================================================== This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please contact the sender and delete the email and attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. Email communications with the University of Nottingham may be monitored where permitted by law.

1 0

regex problem with ghc-8.6 and older
by Ben Franksen 28 May '23

28 May '23

Hi Everyone I was trying to fix a bug in a large program (darcs) and stumbled over a problem that I cooked down to the minimal test program below. The issue here is that with ghc-8.6 and earlier, properly handling an invalid regular expression (here: the empty string) does not work: somehow something calls "error". With ghc-8.8 and later it works as expected. In both cases the latest releases of the regex packages are used. {-# LANGUAGE GeneralizedNewtypeDeriving #-} import Prelude hiding (fail) import Control.Monad.Fail import Control.Exception import Text.Regex.Base import Text.Regex.TDFA newtype RegexFail a = RegexFail { runRegexFail :: Either String a } deriving (Functor, Applicative, Monad) instance MonadFail RegexFail where fail = RegexFail . Left test :: RegexFail Regex test = makeRegexM "" main = handle (\(ErrorCall _) -> putStrLn "error call") $ case runRegexFail test of Left _ -> putStrLn "clean error handling" Right x -> print (matchM x "" :: Maybe Bool) > runghc-8.6 test2.hs √ error call > runghc-8.8 test2.hs √ clean error handling (1) Is this a known problem with ghc < 8.8 / base < 4.13? (2) Is there a work-around for older ghc versions? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

4 5

GHC handling of signals
by Ben Franksen 27 May '23

27 May '23

Consider the following program: import System.IO import System.IO.Error import System.Posix.Signals main = do installHandler sigPIPE Default Nothing c <- readFile "/usr/share/dict/words" putStrLn c `catchIOError` \e -> hPutStrLn stderr (show e) hPutStrLn stderr "I survived" Compile with ghc and run as ./test | true As expected, you see nothing further displayed, since according to `man 7 signal` the default for SIGPIPE is to terminate the program, which happens before the exception handler has a chance to run. Without the line where the signal handler gets installed the behavior is different: You'll see: <stdout>: commitBuffer: resource vanished (Broken pipe) I survived Apparently the GHC runtime does something like installHandler sigPIPE Ignore Nothing This is not a complaint, I find the behavior quite reasonable and much more predictable than the default (why should I not be able to catch EPIPE and continue?). The question is whether it is documented how the GHC runtime treats signals and if yes where? Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

3 3

Munich Haskell Meeting, 2023-05-29 @ 19:30
by Leah Neukirchen 27 May '23

27 May '23

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 29 at 19h30. The weather should be good, so we'll meet at **Hirschgarten Biergarten**. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can look out for you. It is OK to add yourself to the nuudel anonymously or pseudonymously. https://nuudel.digitalcourage.de/xduCn5pUNTlcl7dT Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

3 2