- Haskell-Cafe - Haskell.org

3-year Research Associate or Research Assistant position in formal verification, using a proof assistant (preferably Isabelle), at the University of Sheffield
by Andrei Popescu 20 Apr '23

20 Apr '23

Dear colleagues, We have an opening for a 3-year position of either research associate or research assistant at the University of Sheffield, UK. It is on a project called "Safe and secure concurrent programming for advanced hardware architectures" and involves modelling and verification using a proof assistant, preferably Isabelle. Please share this opportunity with anyone you think might be interested. The closing date for applications is *** 23rd May 2023 *** More details can be found here: https://www.jobs.ac.uk/job/CYZ645/research-assistant-or-research-associate-… and here: https://jobs.shef.ac.uk/sap/bc/webdynpro/sap/hrrcf_a_posting_apply?PARAM=cG… Best wishes, Andrei Popescu https://www.andreipopescu.uk/

1 0

[Summer of Haskell 2023] Submit your proposal by tomorrow!
by Ida Bzowska 19 Apr '23

19 Apr '23

Hi Everyone, This is the last call to those wanting to participate in the Summer of Haskell program - project proposals are due by April 20, 2023 (tomorrow!). Details, including application instructions and a list of suggested projects and volunteer mentors, can be found at: summer.haskell.org Additionally, if your company or organization wants to support new open-source contributors, please email us at summer(a)haskell.org. Funding a stipend or two can have a significant positive impact on the Haskell ecosystem! Regards, Ida Bzowska

1 0

Re: [Haskell-cafe] Call for Papers: Functional Software
by Adrian Cochrane 18 Apr '23

18 Apr '23

Would you an experience report regarding building my own (no-JS) browserengine be appreciated? On Wed, Apr 19, 2023, at 12:00 AM, haskell-cafe-request(a)haskell.org wrote: > Dear all, > > The first workshop on "Functional Software Architecture - FP in the Large” > will be held in Seattle in Sept 2023, co-located with the ICFP conference. > > Please share, and submit your best papers, experience reports, and > architectural pearls on large-scale functional programming! > > The submission deadline 1st June 2023. > > Best wishes, > > Mike Sperber and Graham Hutton > Program Chairs, FUNARCH 2023 > > > ====================================================================== > > *** FUNARCH 2023 -- CALL FOR PAPERS *** > > The First ACM SIGPLAN Workshop on > Functional Software Architecture - FP in the Large > > 8th September 2023, Seattle, Washington, USA > Co-located with ICFP 2023 > > https://tinyurl.com/FUNARCH-23 > > ====================================================================== > > TIMELINE: > > Paper submission 1st June 2023 > Author notification 28th June 2023 > Camera ready copy 18th July 2023 > Workshop 8th Sept 2023 > > BACKGROUND: > > "Functional Software Architecture" refers to methods of construction > and structure of large and long-lived software projects that are > implemented in functional languages and released to real users, > typically in industry. The goals for the workshop are: > > - To assemble a community interested in software architecture > techniques and technologies specific to functional programming; > > - To identify, categorize, and document topics relevant to > the field of functional software architecture; > > - To connect the functional programming community to the software > architecture community to cross-pollinate between the two. > > The workshop follows on from the Functional Software Architecture > open space that was held at ICFP 2022 in Slovenia. > > SCOPE: > > The workshop seeks submissions in a range of categories: > > - You're a member of the FP community and have thought about how > to support programming in the large, for example by framing > functional ideas in architectural terms or vice verse, comparing > different languages in terms of their architectural capabilities, > clarifying architectural roles played by formal methods, proof > assistants and DSLs, or observing how functional concepts are > used in other language and architecture communities. > > Great, submit a research paper! > > - You're a member of the architecture community, and have thought > about how your discipline might help functional programmers, for > example by applying domain-driven design, implementing hexagonal > architecture, or designing self-contained systems. > > Excellent, submit a research paper! > > - You've worked on a large project using functional programming, > and it's worked out well, or terribly, or a mix of both; bonus > points for deriving architectural principles from your experience. > > Wonderful, submit an experience report! > > - You know a neat architectural idiom or pattern that may be useful > to others developing large functional software systems. > > Fabulous, submit an architectural pearl! > > - You have something that doesn't fit the above categories, but > that still relates to functional software architecture, such > as something that can be written up, or that could be part of > the workshop format like a panel debate or a fishbowl. > > Superb, submit to the open category! > > Research papers should explain their research contributions in both > general and technical terms, identifying what has been accomplished, > explaining why it is significant, and relating it to previous work, > and to other languages where appropriate. > > Experience reports and architectural pearls need not necessarily > report original research results. The key criterion for such papers > is that they make a contribution from which others can benefit. > It is not enough simply to describe a large software system, or > to present ideas that are specific to a particular system. > > Open category submissions that are not intended for publication > are not required to follow the formatting guidelines, and can > submit in PDF, word or plain text format as preferred. > > If you are unsure whether your contribution is suitable, or if > you need any kind of help with your submission, please email > the program chairs at <funarch2023(a)easychair.org>. > > SUBMISSION: > > Papers must be submitted by 1st June 2023 using EasyChair, via the > following link: https://tinyurl.com/FUNARCH23-submit > > Formatting: submissions intended for publication must be in PDF > format and follow the ACM SIGPLAN style guidelines, using the > acmart format and the sigplan sub-format. Please use the review > option, as this enables line numbers for easy reference in reviews. > For further details, see: https://tinyurl.com/sigplan-acmart > > If your submission is not a research paper, please mark this using > a subtitle (Experience Report, Architectural Pearl, Open Category). > > Length: submissions must adhere to the limits specified below. > However, there is no requirement or expectation that all pages > are used, and authors are encouraged to strive for brevity. > > Research papers 5 to 12+ pages > Architectural pearls 5 to 12 pages > Experience reports 3 to 6 pages > Open category 1 to 6 pages > > Publication: The proceedings of FUNARCH 2023 will be published in > the ACM Digital Library, and authors of accepted papers are required > to agree to one of the standard ACM licensing options. Accepted > papers must be presented at the workshop by one of the authors, but > in special cases we may consider remote presentation. > > The official publication date is the date the papers are made available > in the ACM Digital Library. This date may be up to two weeks prior to > the first day of the conference. The official publication date affects > the deadline for any patent filings related to published work. > > PROGRAM CHAIRS: > > Mike Sperber Active Group, Germany > Graham Hutton University of Nottingham, UK > > PROGRAM COMMITTEE: > > Joachim Breitner Germany > Manuel Chakravarty Tweag & IOG, The Netherlands > Ron Garcia University of British Columbia, Canada > Debasish Ghosh LeadIQ, India > Lars Hupel Giesecke+Devrient, Germany > Andy Keep Meta, USA > Shriram Krishnamurthi Brown University, USA > Andres Löh Well-Typed, Germany > Anil Madhavapeddy University of Cambridge, UK > José Pedro Magalhães Standard Chartered, UK > Simon Marlow Meta, UK > Hannes Mehnert Robur, Germany > Erik Meijer USA > Ivan Perez KBR / NASA Ames Research Center, USA > Stefanie Schirmer DuckDuckGo, Germany > Perdita Stevens University of Edinburgh, UK > Stefan Wehr Hochschule Offenburg, Germany > Scott Wlaschin FPbridge, UK > > WORKSHOP VENUE: > > The workshop will be co-located with the ICFP 2023 conference at > The Westin Seattle Hotel, Seattle, Washington, United States. > > ====================================================================== > > > > > 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. > > > > >

2 1

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 17 Apr '23

17 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