April 2023 - Haskell-Cafe

FFI: how to allocate a const char * from haskell
by PICCA Frederic-Emmanuel 18 Apr '23

18 Apr '23

Hello, I need to call a c method which take a const char * something like void hkl_holder_add_axis(const struct holder *holder, const char *name); during all the life of this object, the const char* should be accessible. So from haskell I need to create a CString which will not be affected by the garbage collection. The memory should be release only when the given object is freed. or when the program stop. when I use alloca, the memory is releases and the code segfault. I think that I could use malloc, but in that case I have a memory leak. (this is not that important in my case, since I create less than 10 of these objects). I would like you advice in order to solve this properly. thanks for your help. Frederic

4 4

[Haskell] [ANNOUNCE] GHC 9.4.5 released
by Zubin Duggal 18 Apr '23

18 Apr '23

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.5). Download Page: https://www.haskell.org/ghc/download_ghc_9.4.5.html Blog Post: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.4.4. These include: * Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695, #23184, #22998, #22662, #22725). * Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926, #22927, #22929, #22930, #17574, #21840, #22528) * A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965). * Bumping `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * A number of improvements to recompilation avoidance with multiple home units (#22675, #22677, #22669, #22678, #22679, #22680) * Fixes for regressions in the typechecker and constraint solver (#22647, #23134, #22516, #22743) * Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing. * ... and many more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, 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. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.5/docs/html/users_guide/9.4.5-notes.…

1 0

function decl syntax oddities
by Anthony Clayden 18 Apr '23

18 Apr '23

Consider > let f1 x = x + 1 in f1 1 -- ==> 2 ok > let f2 x y = x + y in (f2 2) 3 -- ==> 5 ok > let (f2 x) y = x + y in f2 3 4 -- ==> 7 ok > let (f1 x) = x + 1 in f1 4 The last gives a syntax error `Parse error in pattern: f1`. This is in line with the Language Report, but why? Something to do with patterns? > let ( x ) = 1 in x -- ==> 1 ok > let (Just x) = Just 6 in x -- ==> 6, pattern binding for x ok > let Just x = Just 7 in x -- ==> 7 ok > let (CP x y) = (CP 1) 2 in x -- ==> 1.0 ok > let (CP x) y = (CP 3) 4 in x -- `Parse error in pattern: (CP x)` So the parens are optional for a pattern binding. But if you use them they must enclose the whole pattern -- unlike partially applying a data constr on rhs. OTOH for a function binding, on lhs there must be at least one var (or pattern) not appearing inside outermost parens. Why not optional parens around a whole function binding? It might be your lhs is declaring an operator. Then that can't be inside parens, fair enough: > let (Just x) +? (Just y) = (x +) y in ... -- ok > let ((Just x) +?) (Just y) = x + y in ... -- rejected Lexically we can tell a function (starts lower case) from a data constr. Why the extra restriction with the parens? AntC

1 0

data familly and `sort of` alternative
by PICCA Frederic-Emmanuel 13 Apr '23

13 Apr '23

Hello, I have this class with two data type familly class DataSource a where data DataSourcePath a :: Type data DataSourceAcq a :: Type withDataSourceP :: (Location l, MonadSafe m) => l -> DataSourcePath a -> (DataSourceAcq a -> m r) -> m r instance DataSource Double where data DataSourcePath Double = DataSourcePath'Double (Hdf5Path Z Double) | DataSourcePath'Double'Const Double deriving (Generic, Show, FromJSON, ToJSON) data DataSourceAcq Double = DataSourceAcq'Double Dataset | DataSourceAcq'Double'Const Double withDataSourceP f (DataSourcePath'Double p) g = withHdf5PathP f p $ \ds -> g (DataSourceAcq'Double ds) withDataSourceP _ (DataSourcePath'Double'Const a) g = g (DataSourceAcq'Double'Const a) the purpose of this is to let our users gives multiple way to extract a value from different sources. In the previous case, from an hdf5 file or from a constante value. The withHdf5PathP method can fail and raise an Exception. So I would like a way to provide a fallback like (pseudo code) withDataSourceP f (datapath `or` fallback) g = try datapath and if it fails fallback My question is howto write this `or` method, it is not clear to me and it seems to me that this method should be usable by all the instance. I am also not use if this is the right way to design all this. Thanks for your help. Frederic

1 0

[ANN] data-forced 0.1.0.0 released!
by Ruben Astudillo 11 Apr '23

11 Apr '23

Hello everyone, I am excited to release the first version of data-forced 0.1.0.0. You can get it on <https://hackage.haskell.org/package/data-forced-0.1.0.0> <https://github.com/RubenAstudillo/data-forced> This is a library to avoid reference leaks (liveness leaks) on long lived data structures close to main. It does so without using explicit `seq` or bang patterns, instead using CBV functions, unlifted data type and tagging evaluated values with a unexported newtype constructor. It is a bang pattern you cannot forget! # The big idea We should not throw the information that a value was forced to WHNF or NF. We neither should be required to remember to put a `seq` or BangPattern at the use site to maintain this invariant. We accomplish this using two newtypes: - `newtype ForcedWHNF a = ForcedWHNF a` - `newtype ForcedNF a = ForcedNF a` that don't have their constructors exported. Only unidirectional patterns are provided so you can de-structure them. The *only* way to construct values of these types is via two CBVs functions: - strictlyWHNF :: forall a. a -> Strict (ForcedWHNF a) - strictlyNF :: forall a. NFData a => a -> Strict (ForcedNF a) The Strict data type is inspired by its analog on the data-elevator package <https://hackage.haskell.org/package/data-elevator>. It is a UnliftedDatatype, which means it cannot contain bottoms. The dynamic semantics of bound values of unlifted data types is that *before being bound, these are evaluated to WHNF*. It is a BangPattern you cannot forget! Once you obtain the `Strict (ForcedWHNF a)` value, you de-structurate it to obtain the *lifted* `ForceWHNF a` and store that. You are guaranteed that the references necessary to force it to WHNF are now free. Hopefully you will store it on a data structure that requires values to have been forced before like import Data.Map.Lazy type Accum1 = Map Char (ForcedWHNF Int) type Accum2 = Map Char (ForcedNF (Maybe Text)) # How to use it You should tag your long lived data structures with the correct type as in the previous example. It is less ergonomic than bang patterns, but you cannot forget to put them at the call site, parse not validate. import Data.Map.Lazy as ML -- Spine strict -- No references on added leafs even though it is a lazy map. basicEvent :: ML.Map Char (ForcedWHNF Int) -> IO (ML.Map Char (ForcedWHNF Int)) basicEvent map0 = do let val0 :: Strict (ForcedWHNF Int) -- val0 = strictlyWHNF (error "argument evaluated") -- would fail val0 = strictlyWHNF (2 + 2) -- CBV function, 2 + 2 reduced before val0 is bound. Strict val1 = val0 -- De-structure map1 = ML.insert 'a' val1 map0 pure map1 -- Same as before, but not references to values that were deleted and -- not forced. basicEventPromptDeletion :: Strict (ML.Map Char (ForcedNF (Maybe Int))) -> IO (Strict (ML.Map Char (ForcedNF (Maybe Int)))) basicEventPromptDeletion (Strict map0) = do -- map0 evaluated before being bound. let val0 :: Strict (ForcedNF (Maybe Int)) val0 = strictlyWHNF ((+1) <$> Just 28) Strict val1 = val0 -- De-structure map1 :: Strict (ML.Map Char (ForcedNF (Maybe Int))) -- forced when bound as map1 map1 = Strict (ML.insert 'a' val1 map0) pure map1 # Acknowledgment Sebastian Graf (sgraf812) should take all the credit. I was inspired by his data-elevator package that solves a sightly different problem. He infact pushed the proposal for unlifted data types and made the work to integrate them to GHC.

1 0

[ANN] Yampa 0.14.2, yampa-gloss 0.2.1, haskanoid 0.1.6, and more
by Ivan Perez 08 Apr '23

08 Apr '23

Hello everyone, I'm super excited to announce the release of Yampa 0.14.2! This release also comes with accompanying releases of many related projects: yampa-test (0.14.2), simple-affine-space (0.2.1), yampa-gloss (0.2.1), Space Invaders (0.14.2), and Haskanoid (0.1.6). 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 20 years!!! See https://github.com/ivanperez-keera/yampa#features for details on Yampa's features. This release has address mainly styling issues. All library code now conforms to the main rules of the style guide we follow (which is publicly documented). We've also addressed other minor maintenance issues, like compatibility with new versions of GHC and some dependencies, installation and CI issues, fixes to the README, and pointers to related community projects. In total, there have been more than 400 commits! Special thanks go to Miao ZhiCheng (@hellwolf) for a generous donation towards this release, and to @johannes-riecken for a regular contribution to support the Yampa project. All the projects listed above have been released in sync. For details, see: - https://github.com/ivanperez-keera/Yampa/releases/tag/v0.14.2 - https://github.com/ivanperez-keera/yampa-gloss/releases/tag/v0.2.1 - https://github.com/ivanperez-keera/simple-affine-space/releases/tag/v0.2.1 - https://github.com/ivanperez-keera/SpaceInvaders/releases/tag/v0.14.2 - https://github.com/ivanperez-keera/haskanoid/releases/tag/v0.1.6 You can explore the current versions at: - https://hackage.haskell.org/package/Yampa - https://hackage.haskell.org/package/yampa-test - https://hackage.haskell.org/package/yampa-gloss - https://hackage.haskell.org/package/simple-affine-space - https://hackage.haskell.org/package/SpaceInvaders - https://hackage.haskell.org/package/haskanoid *Code* The github repos are located at: - https://github.com/ivanperez-keera/Yampa/ - https://github.com/ivanperez-keera/yampa-gloss/ - https://github.com/ivanperez-keera/simple-affine-space/ - https://github.com/ivanperez-keera/SpaceInvaders/ - https://github.com/ivanperez-keera/haskanoid/ *What's coming* This release comes exactly 2 months after the last release. The next release is planned for Jun 7, 2023. There are several issues open that you can contribute in each project's issue tracker: Following our roadmap, the pending changes remain as follows: - 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. 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

1 0

log, exp, (**), and non-negative real numbers
by Benjamin Redelings 04 Apr '23

04 Apr '23

Hi, I'm working with some classes that handle probabilities in terms of their log or log-odds. Such classes only handle non-negative real numbers. For example, from Numeric.Log: newtype Log a = Exp { ln :: a } Since the log of a positive number can be negative, we don't want to use the same type to hold the number and its logarithm. Standard functions exp, log, and (**) are awkward because they all assume that numbers and their powers have the same type: log,exp :: a -> a (**) :: a -> a -> a In comparison the ln function from Numeric.Log has a different signature that allows a number and its logarithm to have different types: ln :: Log a -> a Exp :: a -> Log a In order to address this, I have tried defining a type class Pow: class Fractional a => Pow a where pow :: a -> Double -> a ln :: a -> Double expTo :: Double -> a Probably I should replace "Double" here by a type variable b, but I have not done so yet. I'm mostly interested in abstracting over the type of non-negative number, because I have another type Prob that is designed to handle numbers like 1e - 100000, and 1.0 - 1e-100000. data Prob = Zero | Odds Double | One | IOdds Double | Infinity -- store probability in terms of log odds = log (p/(1-p)) Q1. Does anybody know of an existing Haskell module that implements something like the Pow class above? Also, it would be nice (notationally) if I could use log, exp, and (**) instead of ln, expTo, and pow. In theory we could factor out log, exp, (**), sqrt, and logBase from Floating into a new superclass of Floating, so that Floating only contains trig and hyper-trig functions. But I suspect this will not work because the methods in class Pow are more ambiguous. For example, if (x :: Double) then you can do (expTo x :: Prob) and (expTo x :: Log Double) and they will yield different types. Q2. Does anybody have a suggestion for a nicer design? Thanks! -BenRI

4 3

APLAS 2023 first Call for Papers
by Shin-Cheng Mu 04 Apr '23

04 Apr '23

====================================================================== CALL FOR PAPERS 21st Asian Symposium on Programming Languages and Systems (APLAS 2023) Taipei, Taiwan, Sun 26 – Wed 29 November 2023 https://conf.researchr.org/home/aplas-2023 ====================================================================== IMPORTANT DATES ------------------------------------- Submission deadline: Thu 15 Jun 2023 AoE Author response: Mon 31 Jul 12:00 - Wed 2 Aug 12:00 2023 AoE Author notification: Mon 14 Aug 2023 AoE Final paper deadline: Wed 6 Sep 2023 AoE Conference: Sun 26 – Wed 29 Nov 2023 SCOPE ------------------------------------- We solicit submissions in the form of regular research papers describing original scientific research results, including system development and case studies. Among others, solicited topics include: - ** programming paradigms and styles ** : functional programming; object-oriented programming; probabilistic programming; logic programming; constraint programming; extensible programming languages; programming languages for systems code; novel programming paradigms; - ** methods and tools to specify and reason about programs and languages ** : programming techniques; meta-programming; domain-specific languages; proof assistants; type systems; dependent types; program logics, static and dynamic program analysis; language-based security; model checking; testing; - ** programming language foundations ** : formal semantics; type theory; logical foundations; category theory; automata; effects; monads and comonads; recursion and corecursion; continuations and effect handlers; program verification; memory models; abstract interpretation; - ** methods and tools for implementation ** : compilers; program transformations; rewriting systems; partial evaluation; virtual machines; refactoring; intermediate languages; run-time environments; garbage collection and memory management; tracing; profiling; build systems; program synthesis; - ** concurrency and distribution ** : process algebras; concurrency theory; session types; parallel programming; service-oriented computing; distributed and mobile computing; actor-based languages; verification and testing of concurrent and distributed systems; - ** applications and emerging topics ** : programming languages and PL methods in education, security, privacy, database systems, computational biology, signal processing, graphics, human-computer interaction, computer-aided design, artificial intelligence and machine learning; case studies in program analysis and verification. GENERAL INFORMATION ------------------------------------- Submissions should not exceed 17 pages, excluding bibliography in the Springer LNCS format. LaTeX template is available at: https://www.springer.com/gp/computer-science/lncs/conference-proceedings-gu… The accepted papers will be allowed to use one extra page for the content to accommodate feedback from the reviews in the final paper versions. Papers should be submitted via HotCRP: https://aplas2023.hotcrp.com/ The review process of APLAS 2023 is double-anonymous, with a rebuttal phase. In your submission, please, omit your names and institutions; refer to your prior work in the third person, just as you refer to prior work by others; do not include acknowledgments that might identify you. Additional material intended for reviewers but not for publication in the final version - for example, details of proofs - may be placed in a clearly marked appendix that is not included in the page limit. Reviewers are at liberty to ignore appendices and papers must be understandable without them. Submitted papers must be unpublished and not submitted for publication elsewhere. Papers must be written in English. The proceedings will be published as a volume in Springer’s LNCS series. Accepted papers must be presented at the conference. POSTERS and STUDENT RESEARCH COMPETITION ---------------------------------------- APLAS 2023 includes a Posters session and a Student Research Competition. For more details, please see the website. https://conf.researchr.org/track/aplas-2023/posters-and-src ORGANIZERS ------------------------------------- General Chair: Shin-Cheng Mu, Academia Sinica, Taiwan Program Chair: Chung-Kil Hur, Seoul National University, Korea Publicity Chair: Ryosuke Sato, University of Tokyo, Japan Program Committee: Soham Chakraborty, TU Delft, Netherlands Yu-Fang Chen, Academia Sinica, Taiwan Ronghui Gu, Columbia University, USA Ichiro Hasuo, National Institute of Informatics, Japan Ralf Jung, ETH Zurich, Switzerland Ohad Kammar, University of Edinburgh, UK Jeehoon Kang, KAIST, Korea Jieung Kim, Inha University, Korea Robbert Krebbers, Radboud University Nijmegen, Netherlands Ori Lahav, Tel Aviv University, Israel Doug Lea, State University of New York at Oswego, USA Woosuk Lee, Hanyang University, Korea Hongjin Liang, Nanjing University, China Nuno P. Lopes, University of Lisbon, Portugal Chandrakana Nandi, Certora and UW, USA Liam O'Connor, The University of Edinburgh, UK Bruno C. d. S. Oliveira, The University of Hong Kong, Hong Kong Jihyeok Park, Korea University, Korea Clément Pit-Claudel, EPFL, Switzerland Matthieu Sozeau, Inria, France Kohei Suenaga, Kyoto University, Japan Tarmo Uustalu, Reykjavik University, Iceland John Wickerson, Imperial College London, UK Danfeng Zhang, Penn State University, USA

1 0

IFL23 first CFP
by Pieter Koopman 03 Apr '23

03 Apr '23

*Call for papers* The 35th Symposium on Implementation and Application of Functional Languages (IFL 2023) Braga, Portugal, August 29th-August 31st, 2023 *Important dates* Draft paper submission: July 31st, 2023 Draft paper notification: August 1st, 2023 Early registration deadline: August 11th, 2023 Late registration deadline: August 23rd, 2023 Symposium: August 29th - August 31st (3 days) *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 2022 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. 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 specialization * run-time code generation * partial evaluation * abstract interpretation * metaprogramming * 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 * virtual/abstract machine architectures * validation, verification of functional programs * tools and programming techniques * industrial applications *Submissions and peer-review * Following IFL tradition, IFL 2023 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 chair 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. Notice that it is a requirement that accepted draft papers are presented physically at the symposium. After the symposium, a formal review process will take place, conducted by the program committee. Reviewing is single blind. There will be at least 3 reviews per paper. The reviewers have 6 weeks to write their reviews. For the camera-ready version the authors can make minor revisions which are accepted without further reviewing. Contributions submitted for the draft paper deadline must be between two and twelve pages long. For submission details, please consult the IFL 2023 website at https://ifl23.github.io/ <https://ifl21-publicity-dot-yamm-track.appspot.com/2FXkDEWOUAQ2Tbyu5BN0P9Im…> . *Where * IFL 2023 will be held physically in Braga, Portugal, arranged by University of Minho. See the IFL 2023 website at https://ifl23.github.io/ <https://ifl21-publicity-dot-yamm-track.appspot.com/2vSkCLOx6DJpj_Yo1M1_gXPf…> for more information. [image: beacon]

1 0

GPT & Haskell
by Gregory Guthrie 02 Apr '23

02 Apr '23

>From a colleague: GPT Pretty smart(?!). But this is of course simple, and searchable. Still... -------------------------------------------------------------------------------------------------- GPT-4 when prompted: Write binary search in Haskel. Print results using putStrLn. Ensure bug-free code by specifying preconditions, postconditions, invariants, variants, internal states. gives the following response: -- Binary search in Haskell -- Precondition: the list is sorted in ascending order -- Postcondition: the function returns the index of the target element if found, or Nothing otherwise -- Invariant: the search space is always within the bounds of the list -- Variant: the search space decreases by half at each recursive call -- Internal state: the lower and upper bounds of the search space binarySearch :: Ord a => [a] -> a -> Maybe Int binarySearch xs x = go xs x 0 (length xs - 1) where go xs x lo hi | lo > hi = Nothing -- base case: search space is empty | x == midElem = Just mid -- base case: target element is found | x < midElem = go xs x lo (mid - 1) -- recursive case: search in the left half | otherwise = go xs x (mid + 1) hi -- recursive case: search in the right half where mid = (lo + hi) `div` 2 -- calculate the middle index midElem = xs !! mid -- get the middle element -- Print results using putStrLn main :: IO () main = do let xs = [1, 3, 5, 7, 9] -- a sorted list of integers let x = 5 -- a target element to search for let result = binarySearch xs x -- call the binary search function case result of -- pattern match on the result Nothing -> putStrLn "Element not found" -- print a message if Nothing is returned Just i -> putStrLn $ "Element found at index " ++ show i -- print a message with the index if Just i is returned The above code runs: https://onecompiler.com/cpp/3z48yt2pp [cid:image001.png@01D963E1.B0EB6AB0]

20 38