- Haskell-Cafe - Haskell.org

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

08 Jun '20

Hi Michael, I apologise if I'm being dumb, but that ewd.pdf is not a 'publication' and is not by Dijkstra, right? It's taking some of the ideas from Dijkstra's EWD1300, but misapplying them to Haskell in a rather badly-informed way. 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. Also it doesn't seem to know Haskellers very well; nor Dijkstra's well-known support for Haskell in education. There's other bits and pieces of 'Publications' on that the-magus site; including spoofs of Dijkstra which can't even spell his first name right. I rather suspect the ewd.pdf is a spoof that didn't turn out very funny. So altogether it's a couple of dudes shooting the breeze. AntC > On 4/9/19 11:09 AM, Michael Orlitzky wrote: > *>> On 4/9/19 10:41 AM, jaro.reinders at gmail.com <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe> wrote: *>>* I found it: https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html <https://www.cs.utexas.edu/~EWD/transcriptions/EWD13xx/EWD1300.html> *>>> >> * Thank you, this is obviously also relevant, but it's not the one I'm * >> * remembering. The notation is the same, though, so this explains what I'm * >> * looking for (and is also an interesting read). * > After the Dijkstra hint, I was able to track it down: > http://www.the-magus.in/Publications/ewd.pdf

3 2

ANN: hledger 1.18
by Simon Michael 08 Jun '20

08 Jun '20

I'm pleased to announce hledger 1.18. hledger is a robust, cross-platform, plain text accounting tool, with command-line, terminal and web UIs. It is a modern and largely compatible reimplementation of Ledger CLI with many improvements. You can use it to track time, money, investments, cryptocurrencies, inventory and more. See: http://hledger.org http://plaintextaccounting.org HIGHLIGHTS: Fixed JSON output; market prices inferred from transactions; more Ledger file compatibility; more flexible journal entries from CSV; misc. fixes and improvements. See all changes at https://hledger.org/release-notes . Thanks to release contributors Stephen Morgan, Dmitry Astapov, Henning Thielemann, Andriy Mykhaylyk, Pavan Rikhi, and Vladimir Sorokin. GETTING STARTED: Many install methods are described at http://hledger.org/download. Here are three ways to build from source: stack update; stack install --resolver=lts hledger-lib-1.18 hledger-1.18 hledger-ui-1.18 hledger-web-1.18 --silent or: cabal v2-update; cabal v2-install hledger-1.18 hledger-web-1.18 hledger-ui-1.18 or: curl -sO https://raw.githubusercontent.com/simonmichael/hledger/master/hledger-insta… less hledger-install.sh bash hledger-install.sh While building, peruse https://hledger.org/start For help, see http://hledger.org#help-feedback and join us on Freenode (#hledger, http://irc.hledger.org) or via Matrix (#freenode_#hledger:matrix.org, http://riot.hledger.org) New and old users, contributors, sponsors, and all feedback are most welcome! Best, -Simon

1 0

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

08 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 07 Jun '20

07 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 07 Jun '20

07 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 05 Jun '20

05 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 05 Jun '20

05 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 04 Jun '20

04 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