- Haskell-Cafe - Haskell.org

PhD Position at KU Leuven
by Tom Schrijvers 27 Mar '23

27 Mar '23

Dear Haskell Cafe, Are you a highly motivated individual with a passion for programming languages and theory? Do you hold a master's degree in computer science or a related field and have a proven academic track record? If so, we invite you to apply for the PhD Position in Programming Languages at KU Leuven. In this position, you will join the team of Professor Tom Schrijvers, which has a strong reputation in programming language research, covering topics such as functional programming, domain-specific languages, and equational reasoning. Your research will focus on multi-stage programming and computational effects, with the aim of developing a formal calculus for multi-staging with support for algebraic effects and handlers. You will benefit from a competitive monthly stipend, an exciting interdisciplinary research environment, and the opportunity to attend international conferences and collaborate with international partners. Apply now and advance the state-of-the-art in programming language research. For more information and applications, see: https://www.kuleuven.be/personeel/jobsite/jobs/60203785?hl=en&lang=en Best, Tom Schrijvers

1 0

Basic list exercise
by Todd Wilson 26 Mar '23

26 Mar '23

Dear Cafe, Here's a basic exercise in list processing: define a function runs :: Ord a => [a] -> [[a]] that breaks up its input list into a list of increasing "runs"; e.g., runs [3,4,5,6,2,3,4,1,2,1] ---> [[3,4,5,6],[2,3,4],[1,2],[1]] A natural solution is the following: runs [] = [] runs (x:xs) = let (ys, zs) = run x xs in (x:ys) : runs zs where run x [] = ([], []) run x (y:ys) = if x <= y then let (us, vs) = run y ys in (y:us, vs) else ([], y:ys) My question: can we do better than this? It seems that this solution is constantly building and breaking apart pairs. (Or is it, when optimized?) Todd Wilson

6 12

Re: [Haskell-cafe] Basic list exercise
by Johannes Waldmann 26 Mar '23

26 Mar '23

Dear Anthony, and Cafe, > ... get sidetracked into all sorts of places you didn't ask about that's the semantics of "-cafe"? I think we agree. In that spirit, allow me to continue with some more tangential remarks. > Haskell community is so off-putting to learners ... I think a language (or other tool) is best for learning if it shows the concepts (that are the subject of the study) most clearly, instead of ignoring, hiding, or sugarcoating them. > So now they have to find out about `Ordering` > and generic compare functions. Yes - that's algebraic data types, higher order functions, generic polymorphism. You don't get Haskell without that. (By definition: functional, strongly typed) Now we might argue whether that's really the concepts that are needed to answer the original question of this thread. In a way, yes - it is about runs in a list, and a run is defined with respect to an order, so it feels natural that the order is an input of the problem. In another way, no (I think that is your point) - it was about efficient implementation, and that could as well be discussed with a monomorphic type and some fixed order. I found the original question interesting, and I thought that authors of the standard library must have asked the same thing, and the resulting library source code seems to confirm what the OP conjectured: there is no easy way to get ascending runs. How bad is it? I made this experiment: import Criterion.Main import qualified Data.List as L main = do let up = [1 .. 10^7 :: Int] down = reverse up print (sum up, sum down) defaultMain [ bench "length up" $ nf length up , bench "length down" $ nf length down , bench "sort up" $ nf L.sort up , bench "sort down" $ nf L.sort down ] and it shows that sorting an ascending list (which just builds the one ascending run) takes three times the work of just traversing it, but sorting a descending list (building one descending run) only two times. Now, I am not too much worried about efficiency of these particular functions (ascending/descending/sort) because I firmly believe that: 1. using a list as a container is wrong (did you mean Data.Sequence?) 2. sorting lists is more wrong (use Data.Set from the start) 3. writing a sort function yourself is most wrong, - of course with the caveat: 0. unless you get this as homework. Then you should absolutely do it (and then learn from it, and then forget the concrete instance). What worries me here much more deeply is https://github.com/haskell/criterion/issues/273 yes, that's another thing the OP did not ask about. - J.W.

1 0

Re: [Haskell-cafe] Basic list exercise
by Anthony Clayden 24 Mar '23

24 Mar '23

>* On 24 Mar 2023, at 18:44, Johannes Waldmann <johannes.waldmann at htwk-leipzig.de <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: *> >* ... *>* Does the implementation in Data.List do better? *> Data.List's sort is doing a different thing. So I'm not seeing the relevance. Specifically, sort doesn't pay any attention to the incoming list's ordering. >* Since this is about "exercise" - I would expect my students *>* to find that code, so perhaps I'd point them to it right away, *>* and give the task to "understand it" (= argue that it is correct). *>* Arguing about cost seems harder. *> This (ex-)student would wonder why you'd sent me to that code. (Perhaps the lesson is: first read the question.) Why does the correctness (or otherwise) of a sort bear any relation to preserving list sequence and chopping up a list into ascending sublists? AntC

2 2

Re: [Haskell-cafe] Never-ending discussion... Was: Basic list exercise
by Johannes Waldmann 24 Mar '23

24 Mar '23

@Jerzy : I like your plan to use combinators. Then let's remove (visible) recursion completely: map (map fst ) $ groupBy (const snd) $ zip xs ( True : zipWith (<=) xs (tail xs))

2 1

Re: [Haskell-cafe] Basic list exercise
by Johannes Waldmann 24 Mar '23

24 Mar '23

> can we do better than this? Does the implementation in Data.List do better? https://hackage.haskell.org/package/base-4.18.0.0/docs/src/Data.OldList.htm… note that 'ascending' does some trickery there - perhaps exactly to solve the problem you describe? Since this is about "exercise" - I would expect my students to find that code, so perhaps I'd point them to it right away, and give the task to "understand it" (= argue that it is correct). Arguing about cost seems harder. NB: 'descending' is different here, and that's no surprise since lists are asymmetric. We do have a symmetric (and strict) implementation of sequences - how do we sort these? https://hackage.haskell.org/package/containers-0.6.7/docs/src/Data.Sequence… That's not exactly an advertisement for functional programming, as it has "state" written all over the place? But it makes for a nice exercise reading the types. I needed some time to understand that the mouse-over block for an identifier contains _two_ types: the instantiated one (for the use site) and, below that, the general one (from the definition). - J.W.

3 2

ANN: NASA's Ogma 1.0.8 -- with FPrime support
by Ivan Perez 23 Mar '23

23 Mar '23

Hi everyone! I'm thrilled to announce the release of Ogma 1.0.8! Ogma is a NASA tool that facilitates integrating runtime monitors or runtime verification applications into other systems. This is one of the biggest releases of Ogma ever: We can now generate monitors for FPrime [1], a component-based flight software framework used in many NASA missions, including the Ingenuity Mars Helicopter. Since the last release, Ogma also has officially become one of the solutions recommended for monitoring in Space ROS applications [2]. Use cases supported by Ogma also include producing Robot Operating System (ROS 2) packages [3] and NASA Core Flight System (cFS) monitoring applications [4], and generating monitors directly from requirements specified using a structured natural language framework [5]. Ogma leverages existing Haskell work, like the Copilot language [6] (also funded by NASA) and BNFC [7]. For more details, including videos of monitors being generated and flown in simulators, see: https://github.com/nasa/ogma * Releases Ogma is released as a collection of packages in Hackage. The entry point is https://hackage.haskell.org/package/ogma-cli. * Code The github repo is located at: https://github.com/nasa/ogma. * What's coming The next release is planned for May 21st, 2023. Ogma is currently undergoing the qualification process necessary for NASA Class D Software. Apart from the changes required by that process, we also have the following in our roadmap: - Extend ROS 2 monitors with further information about sources of violations. - Add tests to generated code. - Simplify NASA cFS monitor generation process. We hope that you are as excited as we are and that our work demonstrates that, with the right support, Haskell can reach farther than we ever thought possible. Happy Haskelling! Ivan [1] https://github.com/nasa/fprime [2] https://space.ros.org/ [3] https://www.ros.org/ [4] https://github.com/nasa/cFS [5] https://github.com/NASA-SW-VnV/fret [6] https://github.com/Copilot-Language/copilot [7] https://github.com/BNFC/bnfc

1 0

Re: [Haskell-cafe] Basic list exercise
by Anthony Clayden 23 Mar '23

23 Mar '23

On Thu, Mar 16, 2023, 20:33 Todd Wilson <twilson at csufresno.edu <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: > ... > My question: can we do better than this? It seems that this solution is > constantly building and breaking apart pairs. (Or is it, when optimized?) I don't think we can do better (as others have commented). Laziness is a benefit for peeling off only the beginning(s) of possibly-infinite (sub-)lists. Possibly splitting off the head to call sub-function `run x xs` is also "breaking apart". If you don't like pairs, you can split the returned list itself to give the pairing. Using `l@(y:zs)` as did Viktor might help a little if the compiler is particularly dumb. (GHC isn't.) > runs :: Ord a => [a] -> [[a]] > > runs [] = [] > runs l@[x] = [l] > runs (x: l@(y:zs)) > | x <= y = let (ys:zs) = runs l in ((x:ys) : zs) > | otherwise = ([x]: runs l) This solution appears to achieve the same level of laziness as Viktor's. AntC

2 1

Intend to take over package filelock
by Andreas Abel 23 Mar '23

23 Mar '23

See https://discourse.haskell.org/t/take-over-filelock-package/6037?u=andreasab… : I intend to take over https://hackage.haskell.org/package/filelock. It is a dependency of crucial Haskell infrastructure such as `pantry` and `haskell-server` (via `acid-state`). I needs a fix to work with `unix-2.8` as released with GHC 9.6: - https://github.com/takano-akio/filelock/pull/13 I have been trying to communicate this on github to the maintainer Takano Akio since 2023-02-08. I have tried to contact the maintainer by email 2023-03-12, but have gotten no response. Preferably, the maintainer would come back, but I do not have much hope, their last public github activity was 2021-08-22. -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www.cse.chalmers.se/~abela/

1 0

Package takeover: OpenSCAD
by Brecht Serckx 21 Mar '23

21 Mar '23

Hi all, I would like to take over the OpenSCAD[1] package, of which I believe the maintainer is no longer active. The maintainer hasn't replied to my ticket[2] on the issue tracker or to an email to the listed email-address for over a year. On my fork[3] I have implemented multiple bugfixes and features already, and I have some ideas for future improvements. Best regards, Brecht [1] https://hackage.haskell.org/package/OpenSCAD [2] https://chiselapp.com/user/mwm/repository/OpenSCAD/tktview?name=73c74f477b [3] https://github.com/BrechtSerckx/OpenSCAD

4 8