December 2022 - Haskell-Cafe

[ANN] Yampa 0.14
by Ivan Perez 14 Dec '22

14 Dec '22

Dear all, I'm happy to announce the release of Yampa 0.14! Yampa is a fast, elegant Functional Reactive Programming implementation. Yampa prides itself in being a long-standing community project. It has now been around for almost 20 years!!! See https://github.com/ivanperez-keera/yampa#features for details on Yampa's features. * Summary of Version 0.14 - Introduce new type constraint in functions that use VectorSpaces in order to support simple-affine-space 0.2. This is a breaking change, and may require applications to update code on their side providing new instances. - Unit tests in the yampa-test library for 2 more modules have been completed. As always, Yampa and yampa-test are released in sync. The CHANGELOGs are available at: https://github.com/ivanperez-keera/Yampa/blob/develop/yampa/CHANGELOG https://github.com/ivanperez-keera/Yampa/blob/develop/yampa-test/CHANGELOG * Releases You can explore the current versions at: https://hackage.haskell.org/package/Yampa https://hackage.haskell.org/package/yampa-test * Code The github repo is located at: https://github.com/ivanperez-keera/Yampa * What's coming This release comes exactly 2 months after the last release. The next release is planned for Feb 7, 2023. There are a number of issues open that you are more than welcome to contribute to: https://github.com/ivanperez-keera/Yampa/issues Following our roadmap, the pending changes remain as follows: - Complete tests: Our goal is to speed up the process of accepting new features and changes by having a comprehensive test suite that catches errors early. By automating the tests, we hope to free resources that can be dedicated to investigating other issues. - Full conformance to style guide. - Removal of unnecessarily exposed elements from the interface (e.g., FRP.Yampa.Arrow.arr3) that are not used and belong in other libraries. This topic is open to discussion. - Benchmarks: Facilitate making sound, evidence-based decisions about suggested improvements to the implementation, by completing a series of benchmarks. - New mailing list: We will in the future lose access to Yale's CS department-based mailman list, and are thinking of the best place to move the mailing list to. * Donations Our project is now seeking donations to help continue developing Yampa, create new open source libraries, new material, and give talks. Special thanks go to @johannes-riecken for sponsoring my work on the Yampa project with a regular contribution. Github will match the first 5K donated, so if you donate $1/month, github will donate the same amount. No donation is too small. Any contribution will absolutely help. See https://github.com/sponsors/ivanperez-keera for details. If you can help, please come forward. All the best, Ivan

2 1

From function body to DAG and back again?
by Mario Lang 14 Dec '22

14 Dec '22

Hi. I have a binary instance for a file format[1] which describes a graph of DSP primitives. This DAG was generated from a function body[2] (in another programming language). I think that language can be boiled down to a pure language with let expressions, to allow an output to be consumed by several inputs. And there the trouble starts. I am working on this without the usual theoretical background. I am not a PLD student, I am a self-taught Haskell fan. The function body is basically a very neat way to make a DAG readable without using visualisation. Since I am blind, this topic has always fascinated me. Since I have this bidirectional binary instance, and Haskell is supposed to be great at writing small languages, I wonder what would be required to * write a decompiler which would generate a version of the original function body as a data structure and * write a compiler which would translate that data structure back to the graph. This is very much for my own learning experience, especially since there is already a Haskell library which implements at least the compilation part, and more. However, I always found it very fascinating to try to understand how this translation works, so I'd finally like to take a stab at implementing it myself. I have now searched a day for matching learning material which would shed some light on the problem for me, without any great success. Most SLC-examples I stumbled across immediately proceed to implement an evaluation fucntion, which is not quite what I need. For both directions, I need to work out the data structure for my small language first, which is where I am stuck. I have a feeling the decompiler might be easier to write then the compiler. My intuition says all I need to do is work backwards from the last graph node, resolving all inputs until I am done. However, I am stuck on the data structure and the compiler part. Any hints on what could help me to get a better grasp on the problem and how to solve it in Haskell are greatly appreciated. [1] https://github.com/mlang/sound-supercollider/blob/master/Sound/SuperCollide… [2] SynthDef(\default, { arg out=0, freq=440, amp=0.1, pan=0, gate=1; var z = LPF.ar( Mix.new( VarSaw.ar(freq + [0, Rand(-0.4,0.0), Rand(0.0,0.4)], 0, 0.3, 0.3) ), XLine.kr(Rand(4000,5000), Rand(2500,3200), 1) ) * Linen.kr(gate, 0.01, 0.7, 0.3, 2); OffsetOut.ar(out, Pan2.ar(z, pan, amp)); }, [\ir]).writeDefFile; Which translates to the following graph. The pairs are inputs, pointing at the corresponding outputs in the graph, -1 refering to the list of constants at the beginning. defaultSynthDef :: SynthDef defaultSynthDef = SynthDef [ GraphDef "default" [-0.4,0.0,0.4,0.3,4000.0,5000.0,2500.0,3200.0,1.0,1.0e-2,0.7,2.0] [0.0,440.0,0.1,0.0,1.0] [("out",0),("freq",1),("amp",2),("pan",3),("gate",4)] [ UGen "Control" Scalar 0 [] [Scalar] , UGen "Control" Control 1 [] [Control,Control,Control,Control] , UGen "VarSaw" Audio 0 [(1,0),(-1,1),(-1,3)] [Audio] , UGen "BinaryOpUGen" Audio 2 [(2,0),(-1,3)] [Audio] , UGen "Linen" Control 0 [(1,3),(-1,9),(-1,10),(-1,3),(-1,11)] [Control] , UGen "Rand" Scalar 0 [(-1,0),(-1,1)] [Scalar] , UGen "BinaryOpUGen" Control 0 [(1,0),(5,0)] [Control] , UGen "VarSaw" Audio 0 [(6,0),(-1,1),(-1,3)] [Audio] , UGen "BinaryOpUGen" Audio 2 [(7,0),(-1,3)] [Audio] , UGen "Rand" Scalar 0 [(-1,1),(-1,2)] [Scalar] , UGen "BinaryOpUGen" Control 0 [(1,0),(9,0)] [Control] , UGen "VarSaw" Audio 0 [(10,0),(-1,1),(-1,3)] [Audio] , UGen "BinaryOpUGen" Audio 2 [(11,0),(-1,3)] [Audio] , UGen "Sum3" Audio 0 [(12,0),(8,0),(3,0)] [Audio] , UGen "Rand" Scalar 0 [(-1,4),(-1,5)] [Scalar] , UGen "Rand" Scalar 0 [(-1,6),(-1,7)] [Scalar] , UGen "XLine" Control 0 [(14,0),(15,0),(-1,8),(-1,1)] [Control] , UGen "LPF" Audio 0 [(13,0),(16,0)] [Audio] , UGen "BinaryOpUGen" Audio 2 [(17,0),(4,0)] [Audio] , UGen "Pan2" Audio 0 [(18,0),(1,2),(1,1)] [Audio,Audio] , UGen "OffsetOut" Audio 0 [(0,0),(19,0),(19,1)] [] ] [] ] -- CYa, ⡍⠁⠗⠊⠕

2 1

Some questions on Atkey-style indexed monads
by Nicolas Trangez 04 Dec '22

04 Dec '22

All, For some project, I'm considering (again) to use an indexed state monad, which are now somewhat ergonomic to use with QualifiedDo. When looking into existing packages exposing relevant types/classes, I had some questions: 1. These packages provide something like ``` class IxFunctor f where imap :: (a -> b) -> f i j a -> f i j b class IxFunctor f => IxApplicative f where ... ``` Is this `IxFunctor` actually required/useful? It seems to me the implementation of `imap` for some `IxFunctor f` would be equal to `fmap` in the `Functor` implementation for `forall i j. f i j`. Hence, can `IxFunctor` be dropped in lieu of ``` class (forall i j. Functor (f i j)) => IxApplicative f where ... ``` 2. Existing packages predate MonadFail and QualifiedDo. The latter requires (in some cases) an implementation of `fail` and `mfix` to be provided by the module also providing `>>=` etc. I was wondering whether or not there need to be (or can be) `IxMonadFail` and `IxMonadFix` classes like ``` class IxMonad m => IxMonadFail m where ifail :: String -> m i j a class IxMonad m => IxMonadFix m where ifix :: (a -> m i j a) -> m i j a ``` I'm not sure it "makes sense" to have an `ifail` which returns an `m i j a` vs. having only a `MonadFail` (and hence `fail`) implementation for `m i i` only, taking into account the requirement for `fail f >>= k` to be equal to `fail f`, hence `ifail f >>=: k` to be equal to `ifail f`. I think the above question boils down to: is there any use in having `ifail :: String -> m i j a` next to `fail :: String -> m i i a`, or should (i)fail always be state-type-preserving? Similar doubts about `IxMonadFix m` vs. `MonadFix (m i i)`. Thanks for any insights, Nicolas

2 2

TFPIE 2023 call for submissions (deadline Dec 27th)
by Elena Machkasova 03 Dec '22

03 Dec '22

Trends in Functional Programming in Education (TFPIE) 2023 Call for papers https://wiki.tfpie.science.ru.nl/TFPIE2023 (January 12th 2023, Boston, MA, USA, co-located with TFP 2023 and followed by POPL 2023) TFPIE 2023 welcomes submissions describing techniques used in the classroom, tools used in and/or developed for the classroom and any creative use of functional programming (FP) to aid education in or outside Computer Science. Topics of interest include, but are not limited to: FP and beginning CS students FP and Computational Thinking FP and Artificial Intelligence FP in Robotics FP and Music Advanced FP for undergraduates FP in graduate education Engaging students in research using FP FP in Programming Languages FP in the high school curriculum FP as a stepping stone to other CS topics FP and Philosophy The pedagogy of teaching FP FP and e-learning: MOOCs, automated assessment etc. Best Lectures - more details below In addition to papers, we are requesting best lecture presentations. What's your best lecture topic in an FP related course? Do you have a fun way to present FP concepts to novices or perhaps an especially interesting presentation of a difficult topic? In either case, please consider sharing it. Best lecture topics will be selected for presentation based on a short abstract describing the lecture and its interest to TFPIE attendees. The length of the presentation should be comparable to that of a paper. In addition, the speaker can provide commentary on effectiveness or student feedback. Submissions Potential presenters are invited to submit an extended abstract (4-6 pages) or a draft paper (up to 20 pages) in EPTCS style. The authors of accepted presentations will have their preprints and their slides made available on the workshop's website. Papers and abstracts can be submitted via easychair at the following link: https://easychair.org/conferences/?conf=tfpie2023 After the workshop, presenters are invited to submit (a revised version of) their article for the formal review. The PC will select the best articles for publication in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Articles rejected for presentation and extended abstracts will not be formally reviewed by the PC. Important Dates Submission deadline: December 27th 2022, Anywhere on Earth. Notification: December 30th 2022 (Note: earlier submissions will receive earlier response) TFPIE Registration Deadline: see https://trendsfp.github.io/register.html Workshop: January 12th 2023 Submission for formal review: April 19th 2023, Anywhere on Earth. Notification of full article: May 24th 2023 Camera ready: July 1st 2023 Program Committee Christopher Anand - McMaster University, Canada Attila Egri-Nagy - Akita International University, Japan Jason Hemann - Seton Hall University, USA Kevin Kappelmann - Technical University of Munich, Germany Elena Machkasova (Chair) - University of Minnesota Morris, USA Kristina Sojakova - INRIA, France Jørgen Villadsen - Technical University of Denmark, Denmark Invited Speaker: Shriram Krishnamurthi, Brown University Registration information: See https://wiki.tfpie.science.ru.nl/TFPIE2023 for updated information. Registration and attendance are mandatory for at least one author of every paper that is presented at the workshop. Only papers that have been presented at TFPIE may be submitted to the post-reviewing process. -- Dr. Elena Machkasova Associate Professor of Computer Science Division of Science and Mathematics University of Minnesota, Morris Office: Sci 2325 (320) 589-6308 http://cda.morris.umn.edu/~elenam/ Pronouns: she/her/hers or any other

1 0

How to create a list of each constructor value
by PICCA Frederic-Emmanuel 03 Dec '22

03 Dec '22

Hello, I have a type like this data InputType = CristalK6C | MarsFlyscan | MarsSbs | SixsFlyMedH | SixsFlyMedV | SixsFlyMedVEiger | SixsFlyMedVS70 | SixsFlyScanUhv | SixsFlyScanUhv2 | SixsFlyScanUhvTest | SixsFlyScanUhvUfxc | SixsSbsFixedDetector | SixsSbsMedH | SixsSbsMedV | SixsSbsMedVFixDetector deriving (Eq, Show) I want to create a list of each values in order to create meaningfull error message for the user and simplify my Arbitrary instances. I do not want to type two time the values. instance Arbitrary InputType where arbitrary = oneof (map pure [ CristalK6C , MarsFlyscan , MarsSbs , SixsFlyMedH , SixsFlyMedV , SixsFlyMedVEiger , SixsFlyMedVS70 , SixsFlyScanUhv , SixsFlyScanUhv2 , SixsFlyScanUhvTest , SixsFlyScanUhvUfxc , SixsSbsFixedDetector , SixsSbsMedH , SixsSbsMedV , SixsSbsMedVFixDetector ] ) Thanks for your help Frederic

7 12

Debugging a test suite freeze
by David Feuer 01 Dec '22

01 Dec '22

The logict-sequence test suite consistently freezes up on the last test when compiled with GHC 9.4.3. logict-sequence and its test suite don't do anything special with that GHC/base version as far as I can see, or anything particularly strange in general, so I'm pretty confident the problem lies elsewhere. My best guesses are hedgehog, tasty, and tasty-hedgehog. Has anyone else run into weird issues with any/all of these on GHC 9.4.3? David

3 7

ANN: hledger 1.28
by Simon Michael 01 Dec '22

01 Dec '22

I'm pleased to announce hledger 1.28 ! https://github.com/simonmichael/hledger/releases/1.28 https://hledger.org/install https://hledger.org/release-notes.html#hledger-1-28 Nothing earth-shaking for users in this release, but internal changes and the usual incremental improvements. Highlights: new hledger-ui screens and default screen; new hledger-move, watchaccounts scripts. Thank you to release contributors Felix Yan, Patrick Fiaux. What is hledger ? - Fast, reliable, free, multicurrency, double-entry, plain text accounting[1] software that runs on unix, mac, windows, and the web - Built around human-readable, version-controllable plain text files - Inspired by and largely compatible with Ledger CLI[2]; convertible to and from Beancount[3] - Written in Haskell for correctness and longevity. For help getting started, or more info, see https://hledger.org and join our chat via Matrix or IRC: https://hledger.org/support Newcomers, experts, contributors, sponsors, feedback are welcome! Aloha, -Simon [1] https://plaintextaccounting.org [2] https://ledger-cli.org [3] https://beancount.github.io

1 0