- Haskell-Cafe - Haskell.org

Tlon is hiring a Haskell developer as a Senior Platform Engineer
by Edward Amsden 05 Oct '22

05 Oct '22

Urbit (urbit.org) is a social OS for everyone, and Tlon (tlon.io) is the primary company building it. Currently, most people run their Urbit OS on their own machine, but this won’t work for the masses. People need an easy way to get onto the network, and Tlon Hosting is building the product and platform to provide that. We are committed to becoming the primary infrastructure company for Urbit, hopefully managing millions of Urbit instances (aka “ships”) in the future. You will be joining a small team that is laying the foundation to build an ambitious and profitable business, which means you can have a big impact, and not only at Tlon, but on Urbit at large. We are looking for an infrastructure and platform engineer that is capable of leading the development of the next iteration of the hosting system. Running many Urbit instances at scale is not easy, because each instance needs to be carefully monitored and most Urbit life-cycle tasks need to be fully automated. To that effect, we implemented our own Kubernetes operator and additional tooling, all of which are written in Haskell. The role we are hiring for will have a central place in the further buildout of the system. You will develop the basic primitives and APIs that other engineers use to create a full featured hosting product. Additionally, you will need to be able to think strategically about how to iterate on the hosting platform so that other people can build on top of Urbit without having to worry where and how most of the Urbit instances run. In other words, hosting will have to become the most reliable and fool-proof way of using Urbit. Urbit is written in its own programming language, Hoon, and the runtime is written in C. But the hosting platform code is all written in Haskell, and that is what we are hiring for. The position and team is 100% remote. Most of us work in Europe time zones, and we prefer UTC +- 3 hours, but we are flexible. We do multiple offsites every year where we get to spend time IRL as a team and with everyone else at Tlon. Compensation range is $140-190k base salary, plus benefits, plus sizable bonus. There is a slight difference in the comp package structure depending on whether you are in the US or not, but in dollar value it should come out the same. Job Posting: https://tlon.io/careers/senior-platform-engineer To apply, write us here: apply(a)tlon.io

1 0

CFP for PEPM 2023 (Partial Evaluation and Program Manipulation)
by Edwin Brady 04 Oct '22

04 Oct '22

(Apologies for any duplicate copies) -- CALL FOR PAPERS -- ACM SIGPLAN Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM) 2022 =============================================================================== * Website : https://popl23.sigplan.org/home/pepm-2023 * Time : 16th--17th January 2023 * Place : Boston, Massachusetts, United States (co-located with POPL 2023) The ACM SIGPLAN Workshop on Partial Evaluation and Program Manipulation (PEPM) has a history going back to 1991 and has been co-located with POPL every year since 2006. It originated with the discoveries of useful automated techniques for evaluating programs with only partial input. Over the years, the scope of PEPM has expanded to include a variety of research areas centred around the theme of semantics-based program manipulation — the systematic exploitation of treating programs not only as subjects to black-box execution but also as data structures that can be generated, analysed, and transformed while establishing or maintaining important semantic properties. Scope ----- In addition to the traditional PEPM topics (see below), PEPM 2023 welcomes submissions in new domains, in particular: * Semantics based and machine-learning based program synthesis and program optimisation. * Modelling, analysis, and transformation techniques for distributed and concurrent protocols and programs, such as session types, linear types, and contract specifications. More generally, topics of interest for PEPM 2023 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing new theories and applications related to semantics-based program manipulation in general. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme co-chairs, Edwin Brady (ecb10(a)st-andrews.ac.uk) and Jens Palsberg (palsberg(a)ucla.edu) Submission categories and guidelines ------------------------------------ Two kinds of submissions will be accepted: * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance, and clarity. Regular research papers must not exceed 12 pages. * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial, and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages. References and appendices are not included in page limits. Appendices may not be read by reviewers. Both kinds of submissions should be typeset using the two-column ‘sigplan’ sub-format of the new ‘acmart’ format available at: http://sigplan.org/Resources/Author/ and submitted electronically via HotCRP: https://pepm23.hotcrp.com/ Reviewing will be single-blind. Submissions are welcome from PC members (except the two co-chairs). Accepted regular research papers will appear in formal proceedings published by ACM, and be included in the ACM Digital Library. Accepted short papers do not constitute formal publications and will not appear in the proceedings. At least one author of each accepted contribution must attend the workshop (physically or virtually) and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Important dates --------------- * Paper submission deadline : **Thursday 13th October 2022 (AoE)** * Author notification : **Thursday 10th November 2022 (AoE)** * Workshop : **Monday 16th January 2023 to Tuesday 17th January 2023** Best paper award ---------------- PEPM 2023 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Programme committee ------------------- * Chairs: Edwin Brady (University of St Andrews, UK) Jens Palsberg (University of California Los Angeles, USA) * Nada Amin Harvard (USA) * Adam Barwell (Imperial College London, UK) * Nicolas Biri (Input Output Global) * David Castro-Perez (University of Kent at Canterbury, UK) * Cristina David (University of Bristol, UK) * Atsushi Igarashi (Kyoto University, Japan) * Yukiyoshi Kameyama (University of Tsukuba, Japan) * Geoffrey Mainland (Drexel University, USA) * Hila Peleg (Technion Israel Institute of Technology, Israel) * Casper Bach Poulsen (Delft University of Technology, Netherlands) * Sukyoung Ryu (KAIST, Korea) * Sven-Bodo Scholz (Radboud University Nijmegen, Netherlands) * Ilya Sergey (National University of Singapore, Singapore) * Satnam Singh (Groq Inc, USA) * Elena Zucca (University of Genova, Italy)

1 0

Obtain cost-centers stacks from eventlog file
by Ruben Astudillo 28 Sep '22

28 Sep '22

Hello -cafe! I got some experience profiling memory leaks using -prof and the +RTS -hc -L350 --RTS option. This gives me a .hp file with samples done at regular intervals. I can feed this file to `hp2pretty`, get some nice graphs and when I identify a suspicious band, I can grep the .hp file to get the complete "cost-center stack" responsible for that band. Here is an example of one: (18514)unsafeCreate/take/hexString/withText/parseOptionalFieldWith<...> I have been trying to replicate this setup using the eventlog logging. I use +RTS -l-aug -hc --RTS to get the eventlog with user and GC events. I use `eventlog2html` to get better view of memory allocation per cost-center. The normalized view presents me with cost-centers at the right side where I can filter on them[1]. But those labels are just the "top" of the cost-center stack. In fact I don't think the whole cost-center stack is represented anywhere on the eventlog file. I can sort of get the structure of the cost-center stack from the .hp file. The labels identifying the cost-center are different between the two files. Is there a way to recover the complete cost-center stack purely from the eventlog file? Thanks in advance [1]: https://imgur.com/a/nXyCEpG -- Rubén. (pgp: 1E88 3AC4 89EB FA22)

1 0

Munich Haskell Meeting, 2022-09-29 @ 19:30
by Leah Neukirchen 27 Sep '22

27 Sep '22

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, September 29 at Cafe Puck(!) at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this nuudel so we can reserve enough seats! It is OK to add yourself to the nuddel anonymously or pseudonymously. https://nuudel.digitalcourage.de/AtDC1Gfm99791KZ8 Everybody is welcome! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Haskell courses @ 47 Degrees Academy
by Alejandro Serrano Mena 27 Sep '22

27 Sep '22

Dear all, I’m happy to announce that we’ve released four video courses about different topics in Haskell, at https://academy.47deg.com/collections/haskell - Introduction to optics (beginner) - Discovering functors, monads, and applicative (beginner) - Type level programming (intermediate) - Generic programming (advanced) As far as I know, this is some of the first content in video about the more advanced techniques in the language, like data type promotion or constraint kinds. I hope you all enjoy it! We're happy to hear any feedback from you :)

1 0

ProLaLa 2023 -- Programming Languages and the Law (Jan 15th 2023, Boston) : Deadline Oct 27th 2022
by Jonathan Protzenko 27 Sep '22

27 Sep '22

----------------------------------------------------------------------------------------- ProLaLa 2023 -- 2nd Workshop on Programming Languages and the Law Sunday Jan 15th, 2022 Boston, MA co-located with POPL 2023 ------------------------------------------------------------------------------------------ (please forward to anyone who might be interested!) We are pleased to announce ProLaLa'23, the second edition of the workshop concerned with the intersection of PL (Programming Languages) techniques and the law. We are particularly concerned with the following topics: - language design for legal matters; - static analysis of legal texts; - program synthesis and repair for legal software components; - formal modeling of legal semantics; - non-standard logics in support of legal reasoning; - program verification for legal expert systems. If you have explored any of these areas, we encourage you to submit a short abstract. We are hoping to solidify around this workshop what we believe is a nascent but growing community; last year we had 25 submissions and 60 participants. As such, the workshop will be informal, and we strongly encourage you to submit ongoing or already-published work in the form of a brief 5-page submission for a long talk, or a 2-page submission for a short talk. Full details: https://popl23.sigplan.org/home/prolala-2023#Call-for-Papers <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpopl23.si…> Venue ProLaLa will be colocated with POPL'23. We plan to coordinate with the POPL conference on remote participation. We would like to have remote participation even if the workshop happens in person. Our plan is to create an inclusive environment that does not demand traveling for COVID-19 (or other) reasons. Submission details We accept two kinds of submissions. - Long talks: 5 pages excluding references - Short talks: 2 page excluding references We require using SIGPLAN's one-column LaTeX format (acmsmall). Submission site: https://prolala23.hotcrp.com <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprolala23…> Important dates - Thu 27 Oct 2022: Submission deadline - Thu 10 Nov 2022: Notification of acceptance - Sun 15 Jan 2023: Workshop Program committee - Shrutarshi Basu (co-chair), Middlebury College, USA - Denis Merigoux (co-chair), Inria, France - Jonathan Protzenko (co-chair), Microsoft Research, USA - Timos Antonopoulos, Yale, USA - Joaquín Arias, Universidad Rey Juan Carlos, Spain - James Grimmelman, Cornell, USA - Ekaterina Komandantskaya, Herriot-Watts University, UK - Emma Tosch, University of Michigan, USA - Saeid Tizpaz-Niari, University of Texas at El Paso, USA - Giovanni Sileno, University of Amsterdam, Netherlands - Chris Bailey, University of Illinois, USA - Laurence Diver, Vrije Universiteit Brussel, Belgium - Sarah Lawsky, Northwestern Pritzker School of Law, USA

1 0

PLMW@POPL 2023: Call For Scholarship Applications (DEADLINE: 10/14 AoE)
by Favonia 24 Sep '22

24 Sep '22

CALL FOR SCHOLARSHIP APPLICATIONS *DEADLINE: 14 October 2022, 23:59 AoE* (Anywhere on Earth) ACM SIGPLAN Programming Languages Mentoring Workshop Location: Boston, Massachusetts, USA Date: Tuesday, January 17, 2023 Web page: https://popl23.sigplan.org/home/PLMW-POPL-2023 Following the success of the first eleven Programming Languages Mentoring Workshops at POPL 2012-2022, we are pleased to announce the 12th SIGPLAN Programming Languages Mentoring Workshop (PLMW), co-located with POPL 2023 and organized by Hannah Gommerstadt, Michael Greenberg, Kuen-Bang Hou (Favonia), and Robbert Krebbers. The workshop will take place *in person* in Boston. PLMW aims to encourage graduate students and senior undergraduate students to pursue careers in programming language (PL) research. This workshop will bring together world leaders in PL research and teaching from both academia and industry to provide (a) technical sessions on cutting-edge PL research and (b) mentoring sessions on how to prepare for a research career. The workshop will help students imagine how they might contribute to our vibrant and thriving research community. We especially encourage women, members of underrepresented minorities, and people with disabilities to attend PLMW. This workshop is part of the activities surrounding POPL, the Symposium on Principles of Programming Languages, and takes place the day before the main conference. One goal of the workshop is to make the POPL conference more accessible to newcomers. We hope that participants will stay for the whole conference. A number of sponsors (listed below) have generously donated scholarship funds for qualified students to attend PLMW. These scholarships can cover expenses (airfare, hotel, and registration fees) for attendance at both the workshop and the POPL conference itself. The workshop registration is open to all (with or without scholarships). Students with alternative sources of funding are welcome as well. APPLICATION FOR PLMW SCHOLARSHIP The application form can be accessed at the following URL: https://forms.gle/Ct19QcsKjSLoE38B9 The deadline for full consideration of funding is *14 October 2022, 23:59 AoE.* Confirmed sponsors so far: - NSF - ACM SIGPLAN - Jane Street - Galois

1 0

Can this be made to fuse?
by David Feuer 23 Sep '22

23 Sep '22

The template-haskell package has functions `tupE` and `tupP` for building tuple expressions and patterns, respectively, but nothing really similar for building tuple types. I came up with the version below the other day: -- | Given a list of types, produce the type of a tuple of -- those types. This is analogous to 'tupE' and 'tupP'. -- -- @ -- tupT [[t|Int|], [t|Char|], [t|Bool]] = [t| (Int, Char, Bool) |] -- @ tupT :: [Q Type] -> Q Type tupT ts = n `seq` res where -- We build the expression with a thunk inside that will be filled in with -- the length of the list once that's been determined. This works -- efficiently (in one pass) because TH.Type is rather lazy. (res, n) = foldl' (\(acc, !k) ty -> ([t| $acc $ty |], k + 1)) (tupleT n, 0) ts I strongly suspect this is quite fast enough in practice, but it's a bit annoying that it won't participate in list fusion; tupT (map f xs) will (lazily) generate an intermediate list. I wasn't able to convince GHC to fuse it, short of a custom rewrite rule or two (tupT (build f) = ..., tupT (augment f r = ...). Does anyone know if it's possible?

2 4

Re: [Haskell-cafe] monoid homomorphism
by Olaf Klinke 23 Sep '22

23 Sep '22

> Hello every one, > I'm reading "Programming with Categories Brendan Fong Bartosz Milewski David I. Spivak" > and here there's an example of monoid in Haskell: > > Consider the monoids Z× � (Z, 1, ×) and BAND � (B, true, AND). Let > is_odd : Z → B be the function that sends odd numbers to true and even numbers to > false. This is a monoid homomorphism. It preserves identities because 1 is odd, and > it preserves composition because the product of any two odd numbers is odd, but the > product of anything with an even number is even. > > > I'd like representing it graphically I mean the object Zx and arrows about is_odd function, > but I do not know how can do it. > > This is a valid example of monoid homomorphism and I'd like to know > the Haskell implementation and the corresponding categorically view. > > Thanks > Co Extending Li-yao's excellent answer, you could draw a single diagram using the free monoid monad. Disregarding non-termination and infinite lists, the free monoid is the list monad [*]. Every monoid has a structure map, namely mconcat :: Monoid m => [m] -> m satisfying equations (2) and (3) below. A function h :: z -> b between monoids is a monoid homomorphism iff it commutes with the structure map: h . mconcat = mconcat . fmap f (1) mconcat [Z] ---------> Z | | | fmap h | h | | v v [B] ---------> B mconcat This commutative square subsumes Li-yao's two squares. Instantiate the equation (1) with empty and two-element lists to recover Li-yao's squares, where mconcat [] = mempty, mconcat [x,y] = x `mappend` y. In "Programming with Categories" terminology: Monoid homomorphisms are []-Algebra homomorphisms (Definition 4.9). What is not contained in "Programming with Categories" are the Eilenberg-Moore algebra laws. Namely, mconcat . pure = id (2) mconcat . concat = mconcat . fmap mconcat (3) See also chapters in 6 and 7 in [1]. There, the example is linear functions between vector spaces, which are algebra homomorphisms of the monad of formal linear combinations. Olaf [*] Mathematically, the free monoid over a set A is the set of finite words in the alphabet A, with the empty word as 'mempty' and concatenation of words as 'mappend'. E.g. the free monoid over Char is Text. [1] https://hub.darcs.net/olf/haskell_for_mathematicians

1 0

How to diagnose a loop in a large Haskell program?
by Han Joosten 23 Sep '22

23 Sep '22

Hi, I am struggling to debug a loop (some nontermination behaviour) of a huge program. Normally, I use `stack build` to generate it. I have tried to use `trace` at lots of places in the code, recompile and see what happens. However, it isn't always clear in what order the trace statements are fired, because of the lazy evaluation of Haskell. So I tried another approach. I have a function fatal :: HasCallStack => Text -> a fatal msg = exitWith . Fatal . T.lines $ ( msg <> "\n" <> (utf8BuilderToText . displayCallStackFull $ callStack) ) displayCallStackFull :: CallStack -> Utf8Builder displayCallStackFull cs = case reverse $ getCallStack cs of [] -> "<no call stack found>" xs -> mconcat $ fmap showCall xs where showCall :: (String, SrcLoc) -> Utf8Builder showCall (desc, loc) = let file = srcLocFile loc in "\n" <> fromString file <> ":" <> displayShow (srcLocStartLine loc) <> ":" <> displayShow (srcLocStartCol loc) <> " " <> fromString desc (The function to show the stack was inspired from https://hackage.haskell.org/package/rio-0.1.22.0/docs/RIO.html#v:displayCal… ). I would expect that at any place where I force a call to `fatal`, I would get the full stacktrace. Unfortunately, I only get the place where the call to fatal is in the code. I have been looking at the documentation of both stack and ghc, but I don't understand how to compile my code in a way that the full stacktrace is shown. Until now the best guess I have is stack install --profile --no-strip && ampersand -- check testing/Sentinel/Tests/ShouldSucceed/OnlyValidation/Issue280.adl The ultimate goal is to get rid of this ugly bug regarding the loop. Any help/suggestions is really appreciated! Thanks for reading. Han Joosten

2 3