June 2020 - Haskell-Cafe

Generalization of types during inference
by chris done 07 Jun '20

07 Jun '20

I'm writing a type checker with type classes and for some reason thought that the below program should be inferred and generalized automatically. I wasn't sure whether or not GHC would actually accept this or not, so I had to test. For both Hugs and GHC, a recursive definition's type is not generalized by the inferer. You need a type signature. See below. I checked with Hugs just in case there was a generalization limit in GHC due to its more exotic capabilities (like how let generalization is disabled by type families). I wonder: is it in general impossible or super hard to infer the most general type for all cases like this without a type signature? Or is it just considered a rare case that we don't care about? Perhaps it has subtler downsides? It any case, I'm happy to just copy GHC and Hugs as it makes my life easier to just require an explicit signature in this case. Cheers -- ERROR "Q.hs":4 - Type error in application -- *** Expression : f (n - 1) 'a' -- *** Term : 'a' -- *** Type : Char -- *** Does not match : () -- • Couldn't match expected type ‘()’ with actual type ‘Char’ -- • In the second argument of ‘f’, namely ‘'a'’ -- In the expression: f (n - 1) 'a' -- f :: Int -> a -> Int f 0 x = 0 f 1 x = f 0 () f n x = f (n-1) 'a'

2 2

Re: [Haskell-cafe] Looking for a paper [Dijkstra-Dot]
by Anthony Clayden 07 Jun '20

07 Jun '20

>> On 6/5/20 7:05 AM, Anthony Clayden wrote: >>* Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a* >>* 'publication' and is not by Dijkstra, right?* > Sure. >> *It's taking some of the ideas from Dijkstra's EWD1300, but misapplying* >>* them to Haskell in a rather badly-informed way.* > I wouldn't say so, for reasons explained below. An undated pdf without even the authors names, but using a respected author's name seems dodgy to me. It's not "with E.W.Dijkstra" at all, indeed I'd say it's "against" him. I think what they impute to EWD is wrong in fact and wrong in attitude, for reasons explained below. >>* After all, Haskell already has a 'Application Operator' spelled ($),* >>* which is perfectly first-class and with which you can do the equational* >>* reasoning (with lambdas) that the doco is talking about.* > The thread that I was recalling (Language complexity & beginners) can be found here, > > https://mail.haskell.org/pipermail/haskell-cafe/2016-February.txt > and it started as a discussion about the use of ($) for function > application. Namely, what should its type be? Its type is :: (a -> b) -> a -> b; that's in the Haskell Report and what you get at the GHCi prompt :t ($) -- at GHC 6.5 with no extensions on. Also while we're at it Data.Function.& :: a -> (a -> b) -> b -- reverse application, which'll do for the paper Ben suggested. > Whatever you answer is going to be wrong. That's a fine type for the purposes of the 'thought-dialogue' -- which is not a language specification. If GHC's type under the hood is polykinded/higher-ordered/typeRep'd/etc yes that'll confuse beginners, but won't upset the 'thought'. > The root of that problem is that ($) is itself a > function, and you can't insist on using a function to apply function > application without risk of severe injury. So the only way to even use > ($) is via the true function application syntax, namely whitespace. So that's what the authors of EWD.pdf do at the end of the piece, so that they derive (.) by eta-reduction. It's bogus. Also bogus their is putting '.' between the lambda and the bound variable. WTF is that? You don't 'apply' lambda to a variable; it's not a function; it's a binding mechanism. Some syntaxes for lambda calculus put a dot _after_ the bound variable, where Haskell uses ->. To put it bluntly: the authors are blundering. > But whitespace as function application syntax has its own problems. EWD1300 has only a short section on 'Invisible operators'. Dijkstra doesn't like them. To expand his examples, in: > π + x sin(y) The invisible space (juxtaposition) between x and sin means multiplication; the invisible non-spaces within "sin" are not juxtaposition, they're merely a multi-letter name; the invisible non-space between "sin" and parens is function application. (To be precise in C-family languages, it's the pair of parens: rand() is niladic function rand applied to no arguments.) Practical programming languages are limited to ASCII, so can't have UTF-8 chars in names, so we'd have to spell π as "pi" -- which includes another invisible non-space. Then EWD1300 wants to put alternating operators with names, thusly: > pi + x * sin.y > So we want something like ($), but we want it to be *syntax*, Yes. EWD1300's syntax is that (presumably) what's lexed as a (sequence-of) symbol alternates with what's lexed as a name/sequence-of letter. And there's precedence/associativity; and parens' only purpose is to override. EWD1300 does not claim that what's between "pi" and + or between + and x is function application. EWD1300 does not consider operator sections or partial application of operators; only partial application of functions. There's brief mention of 'lambda-abstraction' (partial application), but no working of actual lambda expressions. EWD1300 is not talking about Haskell's peculiar syntax at all. Including not talking about lambda syntax. And I'm sure he'd complain about the iffy use of parens in operator sections -- they're not there merely to override precedence; (5) === 5; (pi) === pi; (+) =/= + > and it should take the place of " " rather than supplement it. > That's the argument those guys (and the paper Ben suggested) are trying to make. EWD1300 does not suggest there's function application between an operator and its operands -- although one could argue that's just as much juxtaposition. Suggesting that for any other operator than ($) would be OK and thereby deals with Haskell's operator sections. But suggesting it for ($) leads to infinite regress. Dijkstra (the real one) was smart enough to see that. The pdf poses a bogus problem; direct consequence of the authors not understanding EWD1300. AntC

1 0

Sliding windows for streaming
by David Feuer 07 Jun '20

07 Jun '20

I'm looking for a bit of help with a library design choice. The streaming package currently offers a slidingWindow function converting a stream into a stream of fixed-size windows of that stream[1]: slidingWindow :: Monad m => Int -- Window size -> Stream (Of a) m b -> Stream (Of (Seq a)) m b This is based directly on a similar function in conduit. Using a rough translation into the world of lists, we have slidingWindow 3 "abcdef" = ["abc","bcd","cde","def"] The awkward case where the stream is shorter than the window is handled by potentially producing a short sequence at the end: slidingWindow 3 "ab" = ["ab"] slidingWindow 3 "" = [""] I recently merged a pull request that adds variations on sliding window maxima and minima using what's apparently a "folklore" algorithm. For example slidingWindowMax 3 "abcbab" = "abcccb" This is basically like slidingWindowMax k = map maximum . slidingWindow k except that an empty stream doesn't yield anything, to avoid undefined values. The big advantage of these specialized functions is that rather than having to take a maximum over a sequence of length `k` at each step, they only do a constant (amortized) amount of work at each step. Nice! But not very general. Suppose we want to take a moving average of some sort, like an arithmetic mean, geometric mean, harmonic mean, or median? That thought leads quite naturally to a data structure: a queue holding elements of some arbitrary *semigroup* that efficiently keeps track of the sum of all the elements in the queue[2]. While the choice of *data structure* is moderately obvious, the choice of *sliding window function* is less so. The tricky bit is, again, what happens when the stream is too short for the window. If you work in the Sum semigroup and divide the results by the window size to get a moving average, then a too-short stream will give a (single) result that's completely wrong! Oof. What would be the most useful way to deal with this? The streams in `streaming` give us the option of producing a distinguished "return" value that comes after all the yields. Would it make sense to *return* the incomplete sum, and the number of elements that went into it, instead of *yielding* it into the result stream? That seems flexible, but maybe a tad annoying. What do y'all think? [1] https://hackage.haskell.org/package/streaming-0.2.3.0/docs/Streaming-Prelud… [2] See the AnnotatedQueue in https://github.com/haskell-streaming/streaming/pull/99/files which basically modifies Okasaki's implicit queues using some of the basic ideas that appear in Hinze-Paterson 2–3 trees.

3 4

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