- Haskell-Cafe - Haskell.org

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

26 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 26 Sep '22

26 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 23 Sep '22

23 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 22 Sep '22

22 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 22 Sep '22

22 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 22 Sep '22

22 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

monoid homomorphism
by coplot coplot 22 Sep '22

22 Sep '22

2 1

Props to cpphs; why so little used?
by Anthony Clayden 20 Sep '22

20 Sep '22

Thank you to the author and maintainers of cpphs https://hackage.haskell.org/package/cpphs It has tightly-focussed functionality for what I wanted to do: a more haskell-friendly counterpart to cpp. How to get it to behave as I wanted wasn't always obvious. I made some notes https://stackoverflow.com/a/73768057/2840542 Haskell libraries generally use cpp -- and then users complain how awkward it can be. I don't see that cpp does anything better/different vs cpphs -- that is, cpphs understands all the #if compiler_version logic. Then why isn't every library preferring cpphs? AntC

4 4

Re: [Haskell-cafe] Cabal: other-modules necessary?
by Tom Ellis 19 Sep '22

19 Sep '22

Ah, that's interesting Oleg, thanks. I like the idea of Cabal being able to specify the exact mapping between modules and source files. Tom On Fri, Sep 16, 2022 at 04:05:53PM +0300, Oleg Grenrus wrote: > That is error generated by GHC. > > The culprit is `ghc --make` mode which discovers modules/files on its own. > > If there were a way to say (for Cabal to GHC) that use these files to > compile the component, and fail otherwise, then -Wmissing-home-modules > would turn into error. > > In fact, it would be great if it where possible to say that *this* > module is in *that* file, something like `MyFoo:src/MyFoo.hs`. > > That would also solve a problem of having same hs-source-dirs for > different components, as Cabal would be able to tell GHC that "don't > look for this modules locally, use dependencies". As currently GHC will > eagerly look for modules locally first. Always. > > - Oleg > > On 16.9.2022 12.23, Tom Ellis wrote: > > On Fri, Sep 16, 2022 at 10:47:47AM +0200, Volker Wysk wrote: > >> The cabal user guide says (in section 6.2.12): "Every module in the package > >> must be listed in one of other-modules, library:exposed-modules or > >> executable:main-is fields." > >> > >> However, I only get a warning message, when I comment out the other-modules > >> field in my .cabal file. The program compiles. This is the message: > >> > >> <no location info>: warning: [-Wmissing-home-modules] > >> These modules are needed for compilation but not listed in your .cabal > >> file's other-modules: > >> Hsskripte Sicherung SicherungAktionen Text Wahl Zeit > >> > >> Is it really necessary to specify all the imported modules? If so, why does > >> the program compile? Can that warning message be turned off? > > In response to all the sibling replies at once, is there a good reason > > for this behaviour? Succeeding but then failing later with obscure > > errors (once the original warning message is nowhere to be seen) seems > > like the worst of all worlds. Suppose cabal errored here and failed > > to proceed. What would be the downside of that (besides backward > > incompatibility)?

2 1

[TFP 2023 Call for Papers] 24th International Symposium on Trends in Functional Programming
by Peter Achten 19 Sep '22

19 Sep '22

# TFP 2023 -- Call for Papers (trendsfp.github.io) ## Important Dates Submission deadline: pre-symposium, full papers, Wednesday 23rd November, 2022 Submission deadline: pre-symposium, draft papers, Friday 16th December, 2022 Notification: pre-symposium submissions, Friday 23rd December, 2022 Registration: Friday 6th January, 2023 TFPIE Workshop: Thursday 12th January, 2023 TFP Symposium: Friday 13th - Sunday 15th January, 2023 Submission deadline: post-symposium review, Friday 17th February, 2023 Notification: post-symposium submissions, Friday 31st March, 2023 The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions. This year, TFP will take place in-person at UMass Boston, Massachusetts in the United States. It is co-located with the Trends in Functional Programming in Education (TFPIE) workshop, which will take on the day before the main symposium. Please be aware that TFP has several submission deadlines. The first, November 23, is for authors that wish to have their full paper reviewed prior to the symposium. Papers that are accepted in this way must also be presented at the symposium. The second, December 16, is for authors that wish to present their work or work-in progress at the symposium first without submitting to the full review process for publication. These authors can then take into account feedback received at the symposium and submit a full article for review by the third deadline, February 17. ## Scope The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: * Research Articles: Leading-edge, previously unpublished research work * Position Articles: On what new trends should or should not be * Project Articles: Descriptions of recently started new projects * Evaluation Articles: What lessons can be drawn from a finished project * Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: * Functional programming and multicore/manycore computing * Functional programming in the cloud * High performance functional computing * Extra-functional (behavioural) properties of functional programs * Dependently typed functional programming * Validation and verification of functional programs * Debugging and profiling for functional languages * Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. * Interoperability with imperative programming languages * Novel memory management techniques * Program analysis and transformation techniques * Empirical performance studies * Abstract/virtual machines and compilers for functional languages * (Embedded) domain specific languages * New implementation strategies * Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2023 program chair, Stephen Chang. ## Best Paper Awards TFP awards two prizes for the best papers each year. First, to reward excellent contributions, TFP awards a prize for the best overall paper accepted for the post-conference formal proceedings. Second, a prize for the best student paper is awarded each year. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, then that paper will receive both prizes. ## Instructions to Authors Papers must be submitted at: <https://easychair.org/conferences/?conf=tfp23> Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. Further, pre-symposium submissions may either be full (earlier deadline) or draft papers (later deadline). ## Pre-symposium formal review Papers to be formally reviewed before the symposium should be submitted before the early deadline and will receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected for publication but accepted for presentation may be resubmitted for the post-symposium formal review. ## Post-symposium formal review Draft papers will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. ## Paper categories Draft papers and papers submitted for formal review are submitted as extended abstracts (4 to 10 pages in length) or full papers (20 pages). The submission must clearly indicate which category it belongs to: research, position, project, evaluation, or overview paper. It should also indicate which authors are research students, and whether the main author(s) are students. A draft paper for which all authors are students will receive additional feedback by one of the PC members shortly after the symposium has taken place. ## Format Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site. ## Program Committee Peter Achten, Radboud University Nijmegen, Netherlands Nada Amin, Harvard University, USA Ambrose Bonnaire-Sergeant, Untypable LLC, USA Laura M. Castro, University of A Coruña, Spain Stephen Chang (Chair), University of Massachusetts Boston, US John Clements, Cal Poly, USA Youyou Cong, Tokyo Institute of Technology, Japan Paul Downen, University of Massachusetts Lowell, USA Kathy Gray, Meta Platforms, Inc., UK Ben Greenman, University of Utah, USA Jason Hemann, Seton Hall University, USA Patricia Johann, Appalachian State University, USA Alexis King, Tweag, USA Julia Lawall, Inria-Paris, France Barak Pearlmutter, Maynooth University, Ireland Norman Ramsey, Tufts University, USA Ilya Sergey, National University of Singapore, Singapore Melinda Tóth, Eötvös Loránd University, Hungary Ningning Xie, University of Toronto, Canada

1 0