- Haskell-Cafe - Haskell.org

Cabal install fails, don't understand why
by Volker Wysk 31 Mar '24

31 Mar '24

Hi I've migrated my HsShellScript library to Cabal 3.0 and now I get an error when I try to install it: -----snip----- desktop /usr/local/src/hsshellscript $ cabal install --user Wrote tarball sdist to /usr/local/src/hsshellscript/dist-newstyle/sdist/hsshellscript-3.6.0.tar.gz Resolving dependencies... Error: cabal: Cannot build the executables in the package hsshellscript because it does not contain any executables. Check the .cabal file for the package and make sure that it properly declares the components that you expect. -----snip----- I don't understand this error message. Why does it think it should build executables? There aren't any. It's a library only. The hsshellscript.cabal file is this (comments and description removed): -----snip----- cabal-version: 3.0 name: hsshellscript version: 3.6.0 synopsis: Using Haskell for Unix shell scripting tasks Description: (...) Homepage: http://www.volker-wysk.de/hsshellscript/ license: LGPL-3.0-or-later license-file: LICENSE author: Volker Wysk maintainer: post(a)volker-wysk.de Copyright: (C) 2021-2024 by Volker Wysk category: System build-type: Simple extra-doc-files: CHANGELOG.md, README.md Extra-source-files: Makefile common warnings Library import: warnings Exposed-Modules: HsShellScript HsShellScript.Args HsShellScript.Paths HsShellScript.Shell Other-Modules: HsShellScript.Commands HsShellScript.GetOpt HsShellScript.Misc HsShellScript.ProcErr Default-Extensions: DeriveDataTypeable, ForeignFunctionInterface, RecordWildCards, ScopedTypeVariables, NamedFieldPuns, StandaloneDeriving Build-depends: base ^>=4.13.0.0, directory >= 1.3.6 && < 1.4, unix >= 2.7.2 && < 2.8, parsec >= 3.1.14 && < 3.2, random >= 1.1 && < 1.2 hs-source-dirs: src C-Sources: src/cbits/hsshellscript.c default-language: Haskell2010 source-repository head type: git location: https://gitlab.com/volkerwysk/hsshellscript.git -----snip----- Thanks for any help! Cheers, Volker

5 9

PostDoc in using Formal Methods for finding security vulnerabilities and misconfigurations in business-process-driven systems (Deadline: 2024-04-18)
by Achim D. Brucker 30 Mar '24

30 Mar '24

Dear all, As part of a US funded project, we have an exciting opportunity for a PostDoc in the Security and Trust of Advanced Systems Group at the University of Exeter (UK) to work applying formal methods to enterprise systems: We will use formal methods (e.g., model checking, SMT solving, interactive theorem proving), to analyze business-process-driven (enterprise) systems (e.g., business logic and workflows described a BPMN models). A particular focus will be the analysis of complex compositions of workflows within one organization as well as across multiple organizations. In particular, we will develop novel techniques to detect faults and vulnerabilities (that can be exploited by both internal and external attackers) in complex business-process-driven systems, contributing to protecting critical workflows such as manufacturing or logistics. In such environments, attackers can exploit such faults and vulnerabilities to cause all kinds of harm such as direct financial losses or causing the production of safety or security critical products to stop. Overall, the project aims to develop automated techniques for assessing the risk of business process or workflows as well as finding and mitigating such attacks. This is a unique opportunity for somebody wanting to use/apply formal methods to the security of large enterprise systems. More information and application details can be found at: * <https://jobs.exeter.ac.uk/hrpr_webrecruitment/wrd/run/etrec179gf.open?WVID=…> Application deadline is the 18th of April 2024. Please contact me for more details. Best, Achim -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

[ANNOUNCE] GHC 9.10.1-alpha2 is now available
by Ben Gamari 29 Mar '24

29 Mar '24

The GHC developers are very pleased to announce the availability of the second alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.10.1-alpha2 We hope to have this release available via ghcup shortly. GHC 9.10 will bring a number of new features and improvements, including: * The introduction of the `GHC2024` language edition, building upon `GHC2021` with the addition of a number of widely-used extensions. * Partial implementation of the [GHC Proposal #281], allowing visible quantification to be used in the types of terms. * [Extension] of LinearTypes to allow linear `let` and `where` bindings ([linear let]) * The implementation of the [exception backtrace proposal], allowing the annotation of exceptions with backtraces, as well as other user-defined context * Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely * Javascript FFI support in the WebAssembly backend * Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector. * ... and many more A full accounting of changes can be found in the [release notes]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.10.1-alpha2/docs/users_guide/9.10.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [exception backtrace]: https://github.com/ghc-proposals/ghc-proposals/pull/330 [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/pull/281 [linear let]: https://github.com/ghc-proposals/ghc-proposals/pull/624 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

Volunteers for ICFP 2024 Artifact Evaluation Committee (AEC)
by Benoit Montagu 25 Mar '24

25 Mar '24

Dear all, We are looking for motivated people to be members of the ICFP 2024 Artifact Evaluation Committee (AEC). Students, researchers and people from the industry or the free software community are all welcome. The artifact evaluation process aims to improve the quality and reproducibility of research artifacts for ICFP papers. In case you want to nominate someone else (students, colleagues, etc.), please send them the nomination form. Nomination form: https://forms.gle/KJAjtDzhm5VLxjVf9 Deadline for nominations: Mon April 8th 2024 For more information, see the AEC webpage: https://icfp24.sigplan.org/track/icfp-2024-artifact-evaluation The primary responsibility of committee members is to review the artifacts submitted corresponding to the already conditionally accepted papers in the main research track. In particular, run the associated tool or benchmark, check whether the results in the paper can be reproduced, and inspect the tool and the data. We expect evaluation of one artifact to take about a full day. Each committee member will receive 2 to 3 artifacts to review. All of the AEC work will be done remotely/online. The AEC will work in June, with the review work happening between June 5th and July 5th. Come join us in improving the quality of research in our field! Best, the Artifact Evaluation chairs: Quentin Stiévenart and Benoît Montagu

1 0

Requesting For Comments for a new simple-dsp library
by Tristan Cacqueray 21 Mar '24

21 Mar '24

Dear cafe and Dr. Henning Thielemann, I'd like to propose a new package named simple-dsp. I couldn't figure out how to use the existing dsp library, so I made my own version featuring a little GUI to try the code in realtime. I'd be happy to contribute this work directly to dsp. My goal is to be able to extract sensible discrete values from a sound input at 60 Hz for video production. I implemented low/band/high pass filters to compute 3 RMS volumes, but the values I'm getting are not sharp enough, e.g. the band pass picks the low end. Ideally I would extract the transient events of the percusive sound and the note pitch of the melodic elements. I have very little understanding of DSP, and I'm sure there are better ways to achieve this goal, so I would appreciate it if someone more experienced could take a look: * Doc: https://tristancacqueray.github.io/simple-dsp/ * Candidate: https://hackage.haskell.org/package/simple-dsp-0.1/candidate * Forum: https://discourse.haskell.org/t/rfc-a-new-simple-dsp-library/9094 Thanks in advance, -Tristan

2 3

my ancient hackage account
by Keith Sheppard 21 Mar '24

21 Mar '24

Hi All, I wrote https://hackage.haskell.org/package/txt-sushi a long long time ago. I'd like to clean some things up and make some improvements. I tried to use the password recovery tool but it said it "wasn't available" for this account. Maybe because it's so old? Can anyone suggest how to recover the account? Thank you, Keith

2 1

Funded PhD Position in Formalizing/Verification of Golang (Application Deadline 2024-03-31)
by Achim D. Brucker 20 Mar '24

20 Mar '24

We have an exciting opportunity for PhD study with myself and Prof. Burkhart Wolff from the Université Paris-Saclay on developing a formal semantics for Go(lang) in Isabelle/HOL. This is part of a new 'double PhD' programme leading to a PhD award from the University of Exeter and the Université Paris-Saclay. More information and application details can be found at: * https://www.exeter.ac.uk/study/pg-research/funding/phdfunding/paris-saclay/ * https://adum.fr/as/ed/voirproposition.pl?site=adumR&matricule_prop=53822#ve… Application deadline is the 31st of March 2024. Please contact me for more details. Best, Achim -- Prof. Achim Brucker | Chair in Cybersecurity & Head of Group | University of Exeter https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Utrecht Summer School on Advanced Functional Programming
by Wouter Swierstra 19 Mar '24

19 Mar '24

# Call for Participation SUMMER SCHOOL ON ADVANCED FUNCTIONAL PROGRAMMING Utrecht, the Netherlands, 08 July – 12 July 2024 http://www.afp.school **Please register before June 1st ** ## ABOUT The Advanced Functional Programming summer school has been running for more than ten years. We aim to educate aspiring Haskell programmers beyond the basic material covered by many textbooks. The lectures will cover several more advanced topics regarding the theory and practice of Haskell programming, including topics such as: * lambda calculus; * monads and monad transformers; * lazy evaluation; * generalized algebraic data types; * type families and type-level programming; * concurrency and parallelism. The summer school will be held in Utrecht and consists of a mix of lectures, labs, and a busy social program. ## PREREQUISITES We expect students to have a basic familiarity with Haskell already. You should be able to write recursive functions over algebraic data types, such as lists and trees. There is a great deal of material readily available that covers this material. If you've already started learning Haskell and are looking to take your functional programming skills to the next level, this is the course for you. ## DATES **Registration deadline: June 1st, 2024** School: 08 July – 12 July 2024 ## COSTS 750 euro - Profession registration fee 250 euro - Student registration fee 200 euro - Housing fee We will charge a registration fee of 750 euros (or 250 euros for students) to cover our expenses. If this is problematic for you for any reason at all, please email the organisers and we can try to offer you a discounted rate or a fee waiver. We have a limited number of scholarships or discounts available for students that would not be able to attend otherwise, especially for women and under-represented minorities. ## FURTHER INFORMATION Further information, including instructions on how to register, is available on our website: http://www.afp.school

1 0

Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order
by John Creighton 17 Mar '24

17 Mar '24

I was asking Bing Copilot questions to better understand the order of precedence in: sequence :: Monad m => [m a] -> m [a] sequence = foldr mcons (return []) where mcons p q = p >>= \x -> q >>= \y -> return (x:y) I noticed that for evaluation (e.g. binding variables to real world data), the left most "->" seems to have it's lambda variables bound first but with regards parsing this left most "->" seems to be the least deeply nested which in a strick language would suggest a low order of precedence. In the summary part of bing's answer, bing actually said that "->" has the highest order of precedence but if you read the whole answer you see it is only for type construction where Bing specifically made claims of the order of precedence and in the other case (parsing & fixity), bing said that the fixity of "->" is not defined in the Haskell 98 report, and nuanced it by saying that the parsing rules depend on both fixity and associativity. Here is my Question to bing: > Related to the above there seems to be ambiguity in the > phrase “order of precedence here”. With regards to evaluation > the order -- in the case of mcons (shown above) -- the “->” > operator seems to get bound first, with real world data. > This suggests a higher order of precedence for “->” than > the other operators. However, with regards to parsing the > operator “->” is associated with less deeply nested brackets, > which in a strict language would suggest a lower order of > precedence, or equivalently in Haskell lingual, a lower fixity. > Fixity is defined in Talb 2 at but this table doesn’t give the > fixity for “->”. www.haskell.org/onlinereport/decls.html#nested *https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/item582390761 <https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/i…> * and here is bing's answer: > You’ve raised an interesting point regarding the perceived > ambiguity in the phrase “order of precedence” when it > comes to the -> operator in Haskell. Let’s delve into this > topic and clarify the nuances. > *1. Operator Precedence and Associativity:> * *In Haskell, operator precedence determines > the order in which operators are evaluated. It > ensures that expressions are parsed unambiguously. > * The associativity of an operator determines whether > it is evaluated from left to right (left-associative) or from > right to left (right-associative). > * The -> operator (function type constructor) has a > specific precedence and associativity. *> 2. Function Type Constructor (->) Precedence:**> * *The -> operator has the *highest precedence* among > all operators in Haskell. > It is used to specify a function’s type signature, such > as Int -> Int -> Float. > * Being right-associative, it means that function types > associate from right to left. For example, > Int -> Int -> Float is equivalent to Int -> (Int -> Float). > *3. Parsing and Fixity:**> * *When parsing expressions, Haskell follows specific > rules for each operator, including the -> operator. > * The compiler determines how to group expressions based on the fixity (precedence and associativity) of operators. > * Fixity declarations allow you to control how > operators are parsed. > *Unfortunately, the Haskell 98 Report does not > explicitly list the fixity of the -> operator. > *4. Custom Operators and Readability:**> * *Custom operators (including symbolic ones) > can indeed decrease readability and maintainability. > * When encountering unfamiliar operators, it’s > challenging to deduce their meaning solely from > their names. > * The arbitrary-looking names lack hints for understanding > their purpose, especially for newcomers. > 5. *Using $ to Clarify Expressions:**> * *The $ operator is defined with very low precedence. > * Writing f $ x is equivalent to f x, but it helps avoid > parentheses. > * By using $, you can explicitly indicate the evaluation > order without relying on operator precedence. > *6. Conclusion:**> * *While the -> operator has the highest precedence, > its behavior is influenced by associativity and context. > * Fixity declarations (such as infixr 0 ->) can help > control how operators are parsed. > * Understanding operator behavior and using $ judiciously > can lead to more idiomatic and maintainable code. > > In summary, the -> operator’s precedence is indeed high, > but its behavior is nuanced due to associativity and > parsing rules. Fixity declarations and careful usage of > operators contribute to code clarity. > > For more details, refer to the Haskell 98 Report. > > Feel free to ask if you have further questions or need additional clarification! 😊 >Learn more > 1 https://stackoverflow.com/questions/23553139/operator-and-function-preceden… > 2 https://www.haskellsos.com/basics/what-order-would-haskell-evaluate-2-opera… > 3 https://devhubby.com/thread/what-is-the-precedence-of-and-in-haskell > 4 https://studentprojectcode.com/blog/how-to-change-precedence-of-constructor… > 5 https://stackoverflow.com/questions/3125395/haskell-operator-vs-function-pr… > 6 https://stackoverflow.com/questions/56202894/what-is-the-precedence-of-and-… > 7 https://codereview.stackexchange.com/questions/120900/expression-parser-in-… > 8 https://kowainik.github.io/posts/fixity > 9 https://devtut.github.io/haskell/infix-operators.html > 10 https://www.haskell.org/onlinereport/decls.html https://sl.bing.net/gHzlncNjtLw https://www.pearltrees.com/s243a/question-evaluation-questions/id76447605/i… I wonder how people would rate Bing's answer.

4 3

Bing/Copilot Answer: "->", has highest precedence for type construction but in general has nuanced precedence order
by Olaf Klinke 17 Mar '24

17 Mar '24

Next time ask GHCi first. (Perhaps you did, but wanted to learn Copilot's opinion anyways): ghci> :info (->) data (->) (a :: TYPE q) (b :: TYPE r) -- Defined in ‘GHC.Prim’ infixr -1 -> ghci> :type (->) <interactive>:1:2: error: parse error on input ‘->’ So while (->) as a type-level function is an infix operator with a precedence, there is no such operator on the term level, otherwise the :type query would have shown it. That the term-level -> is not an operator arguably makes it a lot harder to obtain proper information about. The relevant part of the language documentation I think is this: https://www.haskell.org/onlinereport/exps.html Olaf

1 0