- Haskell-Cafe - Haskell.org

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

08 Jun '20

>> On 6/5/20 7:05 AM, Anthony Clayden wrote: ... >>* 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. * > These all seem pretty irrelevant to the point being made, which I think > has merit. (See my prev post about its lack of merit.) No Haskeller I've ever come across would accuse Dijkstra of "stick[ing] to the antiquated imperative paradigm". Dijkstra advocated teaching Haskell as an antidote to imperativism. EWD1300 is advocating for his own 'notational conventions', chiefly for writing math and formalising proofs. I don't see anything very specific to programming languages; certainly nothing specific to any paradigm. The pdf (words imputed to 'Haskeller') doesn't understand 'first-class': The term dates back to Strachey 1967; it's to do with semantics of names; what in a FP context we'd call 'referential transparency'. It has nothing to do with syntax. Column 2 of page 1 is bogus. Even if 'Haskeller' didn't know that CompSci archaeology, they'd certainly know the ($) operator. Whether or not it's the most important operator, there _is_ an operator and it is first-class. 'Haskeller' gets several answers wrong at the top of p2; finally gets to $ and gets that wrong too: EWD's question re `length $ [] = 0` is not a way to define `length`. Any Haskell beginner could stick that into an actual Haskell compiler and see why. Towards the bottom of p2 EWD admits "I do not know your Haskell very well ...". I'd say this faux-Haskeller knows Haskell less well than faux-EWD. Just before that admission is another piece of bogus notation for operator sections of `x * y`. None of that appears in EWD1300. > This is all just a language design curiosity to me, though, > and I'm not looking to start a new religious war until some of the > present ones are resolved. Well, don't look for pointers to language design from the couple of jokers portrayed in that pdf. I find it actually insulting to the good sense the real Dijkstra always showed; and insulting to Haskellers -- what's with all this gratuitous imputing of emotion? What's with just getting Haskell wrong? It's easy to check those claims; it's easy to get the (alleged) 'thought' peer-reviewed from the Haskell community. AntC

6 7

Reminder: ZuriHac is happening (remotely) this weekend be great fun!
by Jasper Van der Jeugt 08 Jun '20

08 Jun '20

Hi everybody! This is a reminder that not only will ZuriHac be happening this year, but because it will be remote, the number of attendees has virtually no upper limit. We're quite excited (and a little bit nervous) to see how a remote event will play out. We will for sure lose a little bit of the magic feeling of hacking on projects together, however we hope that getting together online will still be a great experience. Another benefit is that people can join from all over the world, and that the event will generate a lot fewer CO2 emissions this year, so we can all feel good about ourselves! A brief summary of what will be there - Talks by Alexis King, Rob Rix, Gabriel Gonzalez, Philip Wadler and Simon Meier & Ognjen Marić will be live-streamed on our Youtube channel: <https://www.youtube.com/channel/UC2zfPMH_srjxUN5EYrfIhCw>. - Well-Typed will teach two advanced sessions, one about Datatype-Generic Programming and one about InfoSec and Haskell. - Julie Moronuki will teach a beginner track. - There is a GHC track with talks by Richard Eisenberg, Divesh Otwani, Facundo Dominguez and Nicolas Frisby. - Of course, lots of Haskell hacking and socialing! You can find all information & register on our website: <https://zfoh.ch/zurihac2020> Warm regards Jasper Van der Jeugt

1 0

First call for draft papers for IFL 2020 (Implementation and Application of Functional Languages)
by Jurriaan Hage 08 Jun '20

08 Jun '20

Hello, Please, find below the final call for draft papers for IFL 2020. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL ================================================================================ IFL 2020 32nd Symposium on Implementation and Application of Functional Languages venue: online 2nd - 4th September 2020 https://www.cs.kent.ac.uk/events/2020/ifl20/ ================================================================================ ### Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2020 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Topics of interest to IFL include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialisation - run-time code generation - partial evaluation - (abstract) interpretation - meta-programming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications ### Post-symposium peer-review Following IFL tradition, IFL 2020 will use a post-symposium review process to produce the formal proceedings. Before the symposium authors submit draft papers. These draft papers will be screened by the program chair to make sure that they are within the scope of IFL. The draft papers will be made available to all participants at the symposium. Each draft paper is presented by one of the authors at the symposium. After the symposium every presenter is invited to submit a full paper, incorporating feedback from discussions at the symposium. Work submitted to IFL may not be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy. The program committee will evaluate these submissions according to their correctness, novelty, originality, relevance, significance, and clarity, and will thereby determine whether the paper is accepted or rejected for the formal proceedings. We plan to publish these proceedings in the International Conference Proceedings Series of the ACM Digital Library, as in previous years. ### Important dates Submission deadline of draft papers: 17 August 2020 Notification of acceptance for presentation: 19 August 2020 Registration deadline: 31 August 2020 IFL Symposium: 2-4 September 2020 Submission of papers for proceedings: 7 December 2020 Notification of acceptance: 3 February 2021 Camera-ready version: 15 March 2021 ### Submission details All contributions must be written in English. Papers must use the ACM two columns conference format, which can be found at: http://www.acm.org/publications/proceedings-template ### Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honoured article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. ### Organisation IFL 2020 Chair: Olaf Chitil, University of Kent, UK IFL Publicity chair: Jurriaan Hage, Utrecht University, The Netherlands ### Virtual symposium Because of the Covid-19 pandemic, this year IFL 2020 will be an online event, consisting of paper presentations, discussions and virtual social gatherings. Registered participants can take part from anywhere in the world. ### Acknowledgments This call-for-papers is an adaptation and evolution of content from previous instances of IFL. We are grateful to prior organisers for their work, which is reused here.

1 0

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

08 Jun '20

> Ben Franksen wrote: >>* Well, don't look for pointers to language design from the couple of* >>* jokers portrayed in that pdf.* >> >>* I find it actually insulting to the good sense the real Dijkstra* >>* always showed; and insulting to Haskellers ...* > I really don't get why you're so upset about this harmless opinionated > piece that, in a humorous and obviously exaggerated way, It's not apparent to me this is humour, not even intended as humour. Notoriously, it's very difficult to get across sarcasm/irony on the interwebs. The tongue-in-cheek is not apparent to one of the authors, who has actually implemented these ideas blog.languager.org/2014/09/pugofer.html and it seems inflicted them on undergraduates. Including "8. layout is the only way to denote nesting ...". While they were at it, why not introduce sugar for function definition: > length . [] = 0 would be easy to desugar as an equation defining `length`. It's not apparent from the original thread May 2019 this is all a big hoot. If it's humour, who's the butt of the joke? A caricature of a Haskell newbie who doesn't understand Haskell, and can only regurgitate FP ideals as cheap dogma, played like a trout until "Exasperated". This is cruel sport, not Socratic method. Not humorous. > applies some of Dijkstra's ideas about programming language syntax ... It's not apparent to me that EWD1300 is about programming languages; the piece addresses "polite mathematics", name-checks Whitehead, Leibniz, Tarski -- who are not well-known for their work on programming languages. > Putting these words into Dijkstra's mouth is just an artist's freedom, If it's intended as art, the least they could do is put their name to it. > Despite your endless ranting the authors quite obviously do understand > EWD1300. That's not apparent to me either. > I also don't see how this has anything to do with Dijkstra promoting > Haskell for teaching. I'm not expecting the real Dijkstra would be uncritical of Haskell. I do expect that since Dijkstra saw Haskell's value for teaching, he would respect the (always difficult) design/syntax choices in the language. It's the faux-EWD's snide tripping-up of Haskeller that is uncharacteristic of Dijkstra. Also criticising Haskell's use of semicolon, which comes from ALGOL, as the real Dijkstra would be well aware. Also criticising allowing multiple constructs to express the same algorithm/semantics -- ALGOL also has plenty of that, and by design. And cheap shots about Haskell not supporting "assignments, pointers, gotos ..." -- we all know Dijkstra considers them harmful. AntC

1 0

Re: [Haskell-cafe] Generalization of types during inference
by Olaf Klinke 08 Jun '20

08 Jun '20

> f 0 x = 0 > f 1 x = f 0 () > f n x = f (n-1) 'a' That's very interesting, I learned something new about GHC today. I used to believe that my Haskell compiler always type checks declarations on its own, and after that unifies its result with the type declaration that I provide. Polymorphic recursion yields a case where the compiler's inference procedure is evidently not independent of my provided type declaration. Can the above be abused to compile programs containing false type declarations? (It seems the answer is no, but maybe I lack the fantasy.) Thanks, Olaf

3 2

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

07 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 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