- Haskell-Cafe - Haskell.org

Building Asterius locally
by Hilco Wijbenga 06 Jun '20

06 Jun '20

Hi all, Has anyone tried building Asterius (https://asterius.netlify.app/building.html)? I'm stuck because GHC/GCC can't find binaryen-c.h which is available in /usr/include/binaryen. If I add a symbolic link in /usr/include to binaryen-c.h then this one is found but the next one isn't. Obviously, I don't want to link to every binaryen header file like that. binaryen > /tmp/stack-b6b7026e470b48c5/binaryen-0.0.1.1/cbits/wrappers.c:1:10: error: binaryen > fatal error: binaryen-c.h: No such file or directory binaryen > 1 | #include <binaryen-c.h> binaryen > | ^~~~~~~~~~~~~~ binaryen > | binaryen > 1 | #include <binaryen-c.h> binaryen > | ^ binaryen > compilation terminated. binaryen > `gcc' failed in phase `C Compiler'. (Exit code: 1) I've tried adding include-dirs: /usr/include/binaryen in various places (in package.yaml) but that did not make any difference. In short, how do I make sure /usr/include/binaryen is part of the search path for C header files? Cheers, Hilco

1 0

ICFP 2020: First Call for Students Volunteers
by Victor Lanvin 06 Jun '20

06 Jun '20

Please don't hesitate to share this information with your students, classmates or colleagues! ICFP'20 FIRST CALL FOR STUDENT VOLUNTEERS ========================================= ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. The conference covers the entire spectrum of work, from practice to theory, including its peripheries. In order to smoothly run the conference, associated workshops, and tutorials, we need student volunteers to help out on the practical aspect of the organization. All the events associated with ICFP'20 will take place **virtually** from Sun 23 - Fri 28 August 2020. Even though the event will be virtual, we will more than ever need the help of student volunteers to make sure everything runs smoothly. In return, as an ICFP 2020 student volunteer, you will get more visibility and be able to interact closely with researchers, academics and practitioners from various disciplines and discuss with other students from around the world. While the exact structure of the conference is still being discussed, job assignments for student volunteers will probably include: 1- Assisting with technical sessions, workshops, tutorials, Q&A sessions, and panels. 2- Helping to get authors' videos prepped and ready for broadcast. 3- Managing the various slack channels and social activities. To be considered as a Student Volunteer for ICFP, please fill in the following application form. https://forms.gle/TRN9LxWWkfR3sHtN6 The permanent link to this form can be found on the official conference website. https://icfp20.sigplan.org/track/icfp-2020-student-volunteering There are two rounds of calls with the following deadlines: * deadline for first round: June 21st, 2020 AoE (notification: June 23rd) * deadline for second round: July 19th, 2020 AoE (notification: July 21th) **Please note that the first deadline is in two weeks only!** Positive notifications given in the first round are firm and the second round is only for spots not filled by the first round. If your application is not accepted in the first round, it will automatically be included in the 2nd round.

1 0

Re: [Haskell-cafe] GHC trying to load dynamic library when it really shouldn't
by Will Song 04 Jun '20

04 Jun '20

Is the shared library of the dependency that has it statically linked in not enough? At this point I am also unsure how ghc is able to determine which library to dynamically load. > On Jun 4, 2020, at 2:03 PM, Brandon Allbery <allbery.b(a)gmail.com> wrote: > > ghci loads dynamically for the same reason TH does: you would > otherwise need a ghc linked against your static library. (You could > try -fobject-code and/or an explicit -l option for the library with > ghci.) > > On 6/4/20, Will Song via Haskell-Cafe <haskell-cafe(a)haskell.org <mailto:haskell-cafe@haskell.org>> wrote: >> The 2nd module to compile uses TemplateHaskell and that's where stack build >> will fail. However, trying to load Echidna.Mutator into ghci will also fail >> for the same reason, but it compiles just fine. The import list is pasted >> below. >> >> {-# LANGUAGE FlexibleContexts #-} >> >> module Echidna.Mutator where >> >> import Control.Monad.Random.Strict (fromList, MonadRandom, getRandomR) >> import Data.Maybe (maybe) >> >> import qualified Data.ListLike as LL >> >>> On Jun 4, 2020, at 1:51 PM, Jinwoo Lee <jinwoo68(a)gmail.com> wrote: >>> >>> Does your code use TemplateHaskell? In that case, the compiler will try to >>> load the library for the compile-time computation. >>> >>> >>> On Wed, Jun 3, 2020 at 12:17 PM Will Song via Haskell-Cafe >>> <haskell-cafe(a)haskell.org <mailto:haskell-cafe@haskell.org> <mailto:haskell-cafe@haskell.org <mailto:haskell-cafe@haskell.org>>> wrote: >>> Hey all, I am experiencing some weird build issues with respect to GHC. I >>> would like to mention that what I am doing is somewhat non-standard but >>> theoretically I think it should work. >>> >>> I am developing a Haskell program which depends on a library, hevm, with >>> several external library dependencies, libsecp256k1 and libff. Since these >>> libraries are a bit of a pain to install by default in the macOS >>> ecosystem, having no brew packages, my plan is to statically link these >>> libraries into the release builds. To start off this task, I have simply >>> moved the dynamic libraries for secp256k1 to another location, e.g. # mv >>> /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm >>> appears to work as expected. It compiles fine, and otool reports the >>> following. >>> >>> % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm >>> .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current >>> version 1281.0.0) >>> libff.dylib (compatibility version 0.0.0, current version 0.0.0) >>> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current >>> version 800.7.0) >>> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current >>> version 1.2.11) >>> /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, >>> current version 5.4.0) >>> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current >>> version 7.0.0) >>> /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current >>> version 2.0.0) >>> >>> We can check libHShevm... as well and it does not depend on the secp256k1 >>> dylib anymore. >>> >>> However, moving back onto my program, the build fails. >>> >>> % stack build >>> Building all executables for `echidna' once. After a successful build of >>> all of them, only specified executables will be rebuilt. >>> echidna-1.5.0: configure (lib + exe) >>> Configuring echidna-1.5.0... >>> Warning: 'ghc-options: -threaded' has no effect for libraries. It should >>> only >>> be used for executables. >>> echidna-1.5.0: build (lib + exe) >>> Preprocessing library for echidna-1.5.0.. >>> Building library for echidna-1.5.0.. >>> [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, >>> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) >>> [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, >>> .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) >>> <command line>: can't load .so/.DLL for: libsecp256k1.dylib >>> (dlopen(libsecp256k1.dylib, 5): image not found) >>> >>> -- While building package echidna-1.5.0 using: >>> >>> /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 >>> --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna >>> exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file >>> -fdiagnostics-color=always" >>> Process exited with code: ExitFailure 1 >>> >>> Would anyone happen to know why this failure is occurring? We have no C >>> sources that would create unresolved references to this library, all the >>> code is Haskell. My understanding is that ghc should end up using the >>> static variant now that there is no dynamic library but clearly this >>> intuition is misguided. >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> >>> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> >>> Only members subscribed via the mailman list are allowed to post. >> >> > > > -- > brandon s allbery kf8nh > allbery.b(a)gmail.com <mailto:allbery.b@gmail.com>

1 0

GHC trying to load dynamic library when it really shouldn't
by Will Song 04 Jun '20

04 Jun '20

Hey all, I am experiencing some weird build issues with respect to GHC. I would like to mention that what I am doing is somewhat non-standard but theoretically I think it should work. I am developing a Haskell program which depends on a library, hevm, with several external library dependencies, libsecp256k1 and libff. Since these libraries are a bit of a pain to install by default in the macOS ecosystem, having no brew packages, my plan is to statically link these libraries into the release builds. To start off this task, I have simply moved the dynamic libraries for secp256k1 to another location, e.g. # mv /usr/local/lib/libsecp256k1.dylib{,.bak}. Rebuilding the dependency hevm appears to work as expected. It compiles fine, and otool reports the following. % otool -L .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm .stack-work/install/x86_64-osx/lts-14.14/8.6.5/bin/hevm: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.0.0) libff.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.7.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11) /usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0, current version 5.4.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/lib/libcharset.1.dylib (compatibility version 2.0.0, current version 2.0.0) We can check libHShevm... as well and it does not depend on the secp256k1 dylib anymore. However, moving back onto my program, the build fails. % stack build Building all executables for `echidna' once. After a successful build of all of them, only specified executables will be rebuilt. echidna-1.5.0: configure (lib + exe) Configuring echidna-1.5.0... Warning: 'ghc-options: -threaded' has no effect for libraries. It should only be used for executables. echidna-1.5.0: build (lib + exe) Preprocessing library for echidna-1.5.0.. Building library for echidna-1.5.0.. [ 1 of 24] Compiling Echidna.Mutator ( lib/Echidna/Mutator.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Mutator.o ) [ 2 of 24] Compiling Echidna.Orphans.JSON ( lib/Echidna/Orphans/JSON.hs, .stack-work/dist/x86_64-osx/Cabal-2.4.0.1/build/Echidna/Orphans/JSON.o ) <command line>: can't load .so/.DLL for: libsecp256k1.dylib (dlopen(libsecp256k1.dylib, 5): image not found) -- While building package echidna-1.5.0 using: /Users/incertia/.stack/setup-exe-cache/x86_64-osx/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-osx/Cabal-2.4.0.1 build lib:echidna exe:echidna-test --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Would anyone happen to know why this failure is occurring? We have no C sources that would create unresolved references to this library, all the code is Haskell. My understanding is that ghc should end up using the static variant now that there is no dynamic library but clearly this intuition is misguided.

2 2

Popularity?!
by Gregory Guthrie 03 Jun '20

03 Jun '20

Ah; finally in a toip-10 list! Not for love, but for money..?! The Stack Overflow 2020 Developer Survey's top 10 "top paying" languages: 1. Perl, $76,000 2. Scala, $76,000 3. Go, $74,000 4. Rust, $74,000 5. Ruby, $71,000 6. Bash/Shell/PowerShell, $65,000 7. Objective-C, $64,000 8. Haskell, $60,000 9. Julia, $59,000 10. Python, $59,000 Dr. Gregory Guthrie Maharishi International University ----------------------------------------------------------------

7 7

How to compose operations in streaming
by ☂Josh Chia (謝任中) 03 Jun '20

03 Jun '20

I have a question about the streaming package. Let's say I have str :: Stream (Of String) IO () I want to putStrLn each element and then print the length of str, so I could do this: import Streaming import qualified Streaming.Prelude as SP doit :: Stream (Of String) IO () -> IO () doit str = do SP.mapM_ putStrLn str SP.length_ str >>= print However, will this result in doing 2 passes over str so that the memory requirement is not constant? If so, is there a simple way to combine the two actions so that only pass is needed? I could probably use a counter in a StateT but that's not really simple. More generally, are there techniques for combining folds like how one would with the foldl package?

2 3

Call for Submissions: ICFP Student Research Competition
by Sam Tobin-Hochstadt 02 Jun '20

02 Jun '20

ICFP 2020 Student Research Competition Call for Submissions ICFP invites students to participate in the Student Research Competition, which will be held virtually alongside the main conference, in order to present their research and receive feedback from prominent members of the programming language research community. As usual, the SRC consists of three rounds: * Extended abstract * Poster session at ICFP 2020 * ICFP presentation To make the virtual competition fruitful, we will make sure that every student will have an "invited audience" during the poster session. We are also planning to organize a social event for the students. Please visit the SRC website for updates. ### Important Dates Submissions due: 26 Jun 2020 (Friday) https://icfp20src.hotcrp.com Notification: 10 July 2020 (Friday) Conference: 23 August (Sunday) - 28 August (Friday) ### Submission Details Each submission (referred to as "abstract" below) should include the student author’s name and e-mail address; institutional affiliation; research advisor’s name; ACM student member number; category (undergraduate or graduate); research title; and an extended abstract addressing the following: * Problem and Motivation: Clearly state the problem being addressed and explain the reasons for seeking a solution to this problem. * Background and Related Work: Describe the specialized (but pertinent) background necessary to appreciate the work in the context of ICFP areas of interest. Include references to the literature where appropriate, and briefly explain where your work departs from that done by others. * Approach and Uniqueness: Describe your approach in addressing the problem and clearly state how your approach is novel. * Results and Contributions: Clearly show how the results of your work contribute to programming language design and implementation in particular and to computer science in general; explain the significance of those results. * Submissions must be original research that is not already published at ICFP or another conference or journal. One of the goals of the SRC is to give students feedback on ongoing, unpublished work. Furthermore, the abstract must be authored solely by the student. If the work is collaborative with others and*or part of a larger group project, the abstract should make clear what the student’s role was and should focus on that portion of the work. * Formatting: Submissions must be in PDF format, printable in black and white on US Letter sized paper, and interpretable by common PDF tools. All submissions must adhere to the "ACM Small" template that is available (in both LaTeX and Word formats) from https://www.acm.org/publications/authors/submissions. For authors using LaTeX, a lighter-weight package, including only the essential files, is available from http://sigplan.org/Resources/Author/#acmart-format. The submission must not exceed 3 pages in PDF format. Reference lists do not count towards the 3-page limit. Further information is available at the ICFP SRC website: https://icfp20.sigplan.org/track/icfp-2020-Student-Research-Competition Program Committee: Chair: Youyou Cong (Tokyo Institute of Technology) Stephen Chang (University of Massachusetts Boston) Jesper Cockx (Delft University of Technology) Hsiang-Shang Ko (Institute of Information Science, Academia Sinica) Cyrus Omar (University of Michigan)

1 0

Postdoc position at University of Bristol in functional programming
by Meng Wang 01 Jun '20

01 Jun '20

Dear Haskellers, The programming languages group at Bristol has an open postdoc position in the area of functional programming. Haskell programmers are particularly welcome! Best regards, Meng Meng Wang, PhD (Oxon) Senior Lecturer in Programming Languages International Director, SCEEM School We are looking for an enthusiastic, self-motivated individual to contribute to an EPSRC-funded project, which aims to design programming languages that guarantee strong properties, and the application of them. The post holder will be based in the programming languages group at the University of Bristol Computer Science Department, which consists of three academics, two PDRAs, and a number of PhD students. You will also be working with a network of partners from Oxford, Edinburgh, Kent, Tohoku Japan, Chalmers Sweden, and industrial partner DFINITY Foundations providing expertise on WebAssembly. The University of Bristol is a world-leading university (consistently ranked top 50 in the world by QS) with an exceptionally strong Faculty of Engineering (which the Department of Computer Science is part of). Bristol is a mid-sized city and is widely considered as one of the best places to live in the country. You should have a PhD in programming languages, or a closely related field. This post is available immediately and is offered on a full-time based for an initial term of three years. Appointment at a higher salary point than grade I is possible based on relevant experience. Informal enquiries should be addressed to Dr. Meng Wang (meng.wang(a)bristol.ac.uk<mailto:meng.wang@bristol.ac.uk>) For more details about this position, please see: http://www.bristol.ac.uk/jobs/find/details.html?nPostingID=68914&nPostingTa… Deadline: 28 Jun 2020

1 0

Why does Haskell have both `Maybe a` and `Either a ()`?
by Wiebe-Marten Wijnja 30 May '20

30 May '20

Greetings, everyone! Recently I was involved in a discussion on the new ML-style language 'gleam'. Gleam has for quite a while now only had an `Either a b` type, with all functions that in Haskell one would use a `Maybe a` for, working on an `Either a ()` instead. In the discussion(https://github.com/gleam-lang/gleam/issues/591), the language designers were asking the community whether it would make sense to add `Maybe` to the language as well, or keep using only `Either a ()`. My question: Is the difference between `Maybe a` and `Either a ()` only semantic and are they functionally equivalent, or are there differences in functionality as well? Have a nice day, ~Marten / Qqwy

8 7

ANN: Data.Monoid.First and Data.Monoid.Last are here to stay
by Simon Jakobi 29 May '20

29 May '20

Hi! I'm happy to report that the planned deprecation of Data.Monoid.{First,Last} [0] has finally been scrapped [1]. The original motivation for removing these newtypes of Maybe was to resolve the name conflict with Data.Semigroup.{First,Last} [2]. Unfortunately, while implementing the deprecation, I ended up discovering a whole host of problems with the suggested migration to (Maybe Data.Semigroup.First) and (Maybe Data.Semigroup.Last), which I have attempted to summarize in my email to the libraries mailing list [3]. I would like to thank everyone who contributed to the discussion of the matter, the CLC, and also everyone who pushed me to finally get the matter resolved. :) Cheers! Simon [0] http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Monoid.html#t:Fi… [1] https://gitlab.haskell.org/ghc/ghc/-/commit/f44d7ae08442ae6227db37cacc97fe0… [2] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [3] https://mail.haskell.org/pipermail/libraries/2020-April/030357.html

1 0