October 2021 - Haskell-Cafe

Pattern guards seen in the wild?
by Anthony Clayden 04 Oct '21

04 Oct '21

Browsing some docos for a completely other purpose, I came across this code: > f' [x, y] | True <- x, True <- y = True > f' _ = False (In User Guide 6.7.4.5 Matching of Pattern Synonyms.) That business with the comma and left-arrows? They're 'Pattern guards', Language Report 2010 section 3.13. That also specs 'local bindings' introduced by `let`. In 10 years of reading Haskell code, I've never seen them. Does anybody use them? Are they more ergonomic than guards as plain Boolean expressions? Are 'local bindings' any different vs shunting the `let` to the rhs of the `=`? I'd write that code as: > f'' [x@True, y@True] = True > f'' _ = False I can see the rhs of the matching arrow could in general be a more complex expression. But to express that you could put a more complex Boolean guard(?) AntC

5 4

list of range
by PICCA Frederic-Emmanuel 04 Oct '21

04 Oct '21

Hello, I need to parse a commande line which allows user to describe indices like this 1 -> only one indice 1-5 -> [1..5] 1-5 6-10 ...-> [1..5] ++ [6..10] My question is what it the best type in order to store this information ? Range Int = Range Int | RangeFromTo Int Int | Range Int <+> Range Int At some point I would like to add the possibility to have multiples Indices with the ',' 1,3,5 -> [1,3,5] list of indices This type is used at some point as a List. My question is, are you aware of a similar type in the standar library. This is the kind of information tahth w should parse when we request to print pages. (list of pages to print). Cheers Frederic

4 8

Better writing about Haskell through multi-metaphor learning
by Michael Turner 04 Oct '21

04 Oct '21

Well, this is certainly blowing up into something bigger than I thought it would. (At one point last night, 12 people had my "Haskell in Plain English" essay/chapter open on Google Docs, a very unintentional side effect.) Me: "I finally got (most of?) what monads really mean for practical programming when none other than Simon Peyton-Jones said F# called a very similar construct "workflow," a word he likes." A response: "Was it literally just a single sentence introducing a new word for a concept that made you "get it"? Could you elaborate? This is really quite remarkable." Richard Eisenberg: "For me, coming from a mostly Java background (but with a healthy dollop of functional programming thrown in the mix -- but no Haskell), the phrase that unlocked monads was "programmable semicolon"." I think one explanation for the Monad Tutorial Explosion (and how it still didn't work for a lot of people) is that there's no single right metaphor that will finally make monads "click". It depends on what combination of conceptions (and perhaps all misconceptions to be dispelled) is floating around in given mind. And minds vary. Workflow is a metaphor at one useful level. "Programmable semicolon" is a metaphor at another useful level. Semicolon as imperative-language separator actually hides a lot that's going on in a real CPU. Even if the imperative language is assembly language, the compiled instructions go to an instruction fetch/decode unit that -- these days especially -- can be engaged in a bewildering number of tasks, including finishing up several previous instructions, translating the decoded instruction to what amounts to microcode that get sent to an instruction cache, and fetching the next few instructions even as it's been decoding the instruction fetched into a little to-do list for the CPU. Perhaps we can think of instruction fetch/decode as "monadal" -- it's wildly (but not chaotically) mapping a previous state of the machine into new one. After all, it's all still Turing machines down there somewhere (but even the Turing machine was mathematically defined as a function that maps one tape-state to the next while it's also mapping its internal state to a new state.) So the semicolon can be thought of as lexically exposing the fetch-decode operator in the CPU's own little program. The "workflow" metaphor is at a higher level. If you think of how incoming data can be sorted and parceled out as if to a number of desks in an office, with forms processed at a desk going from one outbox to another desk's inbox, you're ignoring exact sequencing. It's the view where you're labeling desks by their specialized tasks and drawing outbox-inbox connections. In this view, it matters little that, in the one-instruction-at-a-time CPU model, there's only one "clerk" who (ridiculously, I know) puts a form in an inbox, then takes it out again, puts it in the inbox of another desk, then sits down at that other desk, takes the same form out and does the very specific form-processing task assigned to that desk. You can instead imagine it as some sluggish bureaucracy where everyone else but the single busy clerk is waiting for a form to hit their empty inboxes. The fact is, "one-instruction-at-a-time CPUs" hardly exist anymore except in the cheapest microcontrollers -- there are all multitasking like crazy. And this is because CPU designers work very hard to see how much of the little bureaucracy they can actually keep busy, ideally at all times, but at least at high throughput for average instruction streams, even if 100% utilization is seldom reached. (Lambda, the Ultimate Semicolon?) Bryan: "Listing sequential actions one after the other is so intuitive you see it everywhere. Take baking recipes as one example. Or assembly code. Or poems." Yes, sequencing just grows out of the fact of time. You'd think that poems aren't really sequences of tasks to do. But in a way, they are, and in a sense that matters for my attempts at natural-language understanding. There IS an implicit imperative in the energy required to speak: the subtext of any statement addressed to another person (even when it's dead poet to living reader) is: think about what I'm saying. Each new word in a sentence being spoken maps the listener's mind-state to a new one. The purpose of the sequencing is to build up state in the listener's mind. "When a Haskeller says, "Monads are great! They let you chain effectful actions together!" it can take a very long time to understand they actually mean exactly what they're saying — the usual intuition is that sequencing actions can't possibly be a real problem, so you go round and round in circles trying to understand what "effectful" means, what "action" means, and how these oh-so-important "laws" have anything to do with it." Yes, it's sort of like aliens from outer space with a very alien consciousness, and a different relation to the dimension of time, and they are exulting (to each other, and to themselves, really, more than to you): "Periods at the ends of sentences are great! They enable these strange blobs of protoplasm who call themselves 'human' to more easily map the states of these internal things they call 'neurons' into new states. No wonder we've been having such trouble trying to tell them what to do, using our intuitively obvious gestaltic visual patterns that allow us to grasp, with our quantum-computer brains, a whole meaning at once, through our retinas." (Yes, I am riffing a little here on the SF movie Arrival.) Math is this world where we can feel a little like that. Instead of thinking of a function as a machine that takes inputs, grinds away for a little while, and extrudes outputs, you can think of all inputs and output as already existing, and reason logically from the resulting properties. Haskell's laziness helps you fake what you can't really have: infinite workspace and the ability to do everything in an instant. It's a fake-it-til-you-make-it language, and you don't have to be Buzz Lightyear going to infinity and beyond, perhaps to all the way to the galaxy Aleph-omega. You just have to make a Haskell program do something that people like as much as their Buzz Lightyear doll. The math view is a useful view at one level, but it can only help you so much. I greatly enjoyed the level where I could define a Turing machine as a mapper from one infinite tape to another, then imagine all possible Turing machines as a countably infinite set. I could then prove, with Cantor diagonalization (abstractly, at least, though not very intuitively) that there are things Turing machines can't do. I loved that. But I also listened to grad students mutter about how recursive function theory may be beautiful and all, but it's now classical, and therefore dead for their own practical purposes (getting a PhD, getting onto tenure track.) And by then I knew I wasn't good enough at math to make a go of computing theory in their world, as a career, no matter what. I think Simon Peyton-Jones had a similar experience of academia -- he wasn't a John Hughes -- but he found a way through anyway. Bryan: "I can understand why that [puzzled newbie] viewpoint might be long-forgotten by those who were involved in the effort to solve it. :) And I appreciate that it was solved in such a general way that it can be applied to so many seemingly unrelated things! That's the beauty of mathematics!" Yes, it's there. But in user experience design (and writings about Haskell ARE part of its user experience) there's a saying: the intuitive is the familiar. At some point in gaining sophistication, it's no longer intuitively obvious to you why something wasn't intuitively obvious for you before. You're so absorbed in where you are that you don't remember quite how you got there. You might even assume that everyone who has gotten where you are has gotten there by the same route. And, if you can dimly remember how you got a flash of inspiration, you might end up writing yet another monad tutorial that few people understand. "Workflow" helped me. And now "programmable semicolon" is helping a little, in another way. I presented a strategy at the NSMCon-2021 conference: think of NSM reductive paraphrasing as writing very complete and precise code for natural-language terms and grammar rules, using NSM primes and syntax as a kind of logic programming language -- one that might even be very simply translatable to Prolog. I did some coding experiments and saw a problem: viewed more procedurally -- i.e., with each line of an NSM explication adding to a conceptual schema of a natural-language meaning -- NSM wasn't single-assignment. A Prolog interpreter couldn't just try a match, looking at each statement of an explication in relative isolation, and bail out when a statement failed to be true in the given context of the attempted match. It had to drag some state along just to resolve what the NSM prime "this" referred to. (Think of "it" in GHCI.) OK: effects. But wait, more: scoped effects. You want to strip some schema-stuff back out if a match failed midway through, then try another match somewhere else. OK: I need a context stack to store assertions that succeeded. Uh-oh, Prolog doesn't give me that paper trail. Dang. And I still want the one-for-one translation of sentences in an NSM reductive paraphrase to something like Prolog. OK: I need to grab control of sequencing, so that I can not only use the intrinsic Horn clause resolution without pain. But I also want it to hold onto the assertions that succeeded, and knit them into the growing conceptual schema that's part of the state. AND I want it roll those back out, transactionally, if a match didn't succeed. It turns out that Prolog makes this not too much harder than, say, a Lisp with transactional memory. So: I think I might now return to my Prolog code and see if I was unconsciously reinventing some kind of monad. Because because I felt forced by Prolog's limits to write my own semicolon. It wasn't too hard, though the resulting code required for NSM explications looks clunkier now. (Prolog is very limited in syntax extensibility.) Maybe there's some way in which Haskell makes it easier still, and nicer-looking too. None of which is to say that "programmable semicolon" will immediately help everyone pick the conceptual lock of monads. But for those who just bonk on "programmable semicolon", it might help to point out that the load-operate-store model of CPUs is a lie these days. Say a little about why it's not true. Then again pose semicolon as a kind of operator. People like to think, "OK, this statement will finish, and the one after the semicolon will start." It's a convenient view, even though in fact, while the imperative statement is in progress, the CPU might have already fetched instructions beyond it, and scheduled them for speculative execution. Or, you can tell them, "Just learn lambda calculus, then study monads algebraically, and here's a side dish of category theory while I'm it. Bon appetit." How's that working for you, guys? It doesn't work for me. And I don't think it's because I can't do the math. It's that I often write code to see whether I'm thinking about a problem the right way. And is that so bad? I believe it was in Stewart Brand's "II Cybernetic Frontiers" where a researcher at Xerox PARC, Steve ("Slug") Russell, one of their star hackers, was described by his peers as "thinking with his fingertips." I'm no star hacker, but "workflow" feels like it will make my fingertips smarter. "Programmable semicolon" feels like it will make my fingertips smarter. You think top-down mathematically? Well, bon appetit. It's not to my taste. No single way is likely to work for all. Math is not some fundamental reality. It's not even reality -- in fact, it gains a lot of its power precisely from being imaginary. And it's just a bunch of metaphors too. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

10 18

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 17
by Michael Turner 04 Oct '21

04 Oct '21

Wow, someone on this thread said of me, from what I wrote on the beginner's list, "He's trying to translate Haskell to C/C++." No. I started here: https://www.stwing.upenn.edu/~wlovas/hudak/aug.pdf I'd like to use this parsing technique for natural language. I had no intention of translating Haskell to C/C++ unless it turned out to matter for performance. What I didn't realize starting out in trying to understand that code is that it's horribly written code, and underdocumented. 'g' as a function name, a name not clearly related to any meaning? Oh, and how about this type signature: app :: (TTree -> TTree -> Tree) -> TTree -> TTree -> [TTree] I actually reached a point where I thought, "I'm never gonna understand this code," because of that line. Somehow, after weeks of scrolling past it, grimacing, then looking at it again, I figure out a clarification. -- Order (Before/After) type Order = Typed_Tree -> Typed_Tree -> Tree and then I get app :: Order -> Typed_Tree -- the TT to be applied -> Typed_Tree -- TT applied to -> [Typed_Tree] -- result list Is that "translating it to C++"? Or is it "translating it to something you can at least mentally translate into plain English"? (Current frustration: can't seem to find a clean way to extract "Before" and "After" type constructors from Order, as strings to print in trace messages. Several "solutions" found, all either not working in my version of GHC, or not even compilable.) I finally realized: that paper where I started learning Haskell may be a gem as a paper in English, but the code is basically dashed off, by people so steeped in Haskell that it was all obvious to them. And it uses a representation of a left upper-triangular array (in a list-of-lists approach that probably sprays garbage left and right in the course of Haskell evaluations of "transpose", "reverse", etc.) which only makes the code harder to understand. And I haven't convinced myself that it wouldn't just spray smaller numbers of larger pieces of garbage anyway, if I rewrote it to clean out all the list-hacking cruft. Maybe it's OK. Maybe the GHC optimizer really is that good. But before I refactor it to Vector, first I have to make sure I really understand what this code is doing, so that the unit tests I'm adding don't just fail mysteriously. And I'm not there yet. When you read a "diagnosis" of me as someone whose mind is resistant to the Haskell execution model, please ignore it. I'm not resisting it. I'm trying to internalize it. Unfortunately, I haven't found a treatment that ties the execution model to where the rubber hits the road: real computers, like you buy at a store, which are derided by this commenter as "Turing machines." Sorry, guy, but you wrote your reply on a Turing machine. Turing machines got it to my inbox. As Simon Peyton-Jones said, in a talk about how to handle effects, you can't really verify that your program is executing correctly by noticing that the box it's running on gets warmer. I'm quite fine with purity, at least where it can reduce debugging time. I've learned a couple of other functional languages, if you'll condescendingly permit that, say, Lisp and Erlang are "functional." In college, I got fascinated by the idea of a Lisp interpreter with lazy evaluation, and read some papers on the subject, and I even believe laziness could prove useful for the project I'm on. I'm all for static typing. I'm all for how lazy evaluation and purity and functional programming in general can facilitate exploitation of multi-core parallelism. What I want is a clear, concise description of the execution model, to tie it all finally back down to those horrible grubby Turing machines that people buy in stores. Like the one on my desk, right now. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry On Fri, Sep 17, 2021 at 11:18 AM <haskell-cafe-request(a)haskell.org> wrote: > > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: Haskell's "historical futurism" needs better writing, not > better tools (Viktor Dukhovni) > 2. Re: Haskell's "historical futurism" needs better writing, not > better tools (David Feuer) > 3. Re: Haskell's "historical futurism" needs better writing, not > better tools (Viktor Dukhovni) > 4. Re: Haskell's "historical futurism" needs better writing, not > better tools (David Feuer) > 5. Re: Haskell's "historical futurism" needs better writing, not > better tools (Anthony Clayden) > 6. Haskell reference documentation, laws first or laws last? > (Viktor Dukhovni) > 7. Re: Haskell reference documentation, laws first or laws last? > (Anthony Clayden) > 8. Re: Haskell reference documentation, laws first or laws last? > (Chris Smith) > 9. Re: Haskell reference documentation, laws first or laws last? > (David Feuer) > 10. Re: Haskell reference documentation, laws first or laws last? > (Viktor Dukhovni) > 11. Re: Haskell reference documentation, laws first or laws last? > (Anthony Clayden) > 12. Re: Haskell reference documentation, laws first or laws last? > (Chris Smith) > 13. Re: Haskell reference documentation, laws first or laws last? > (David Feuer) > 14. Re: Haskell reference documentation, laws first or laws last? > (Viktor Dukhovni) > 15. Re: Haskell reference documentation, laws first or laws last? > (Sebastiaan Joosten) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Sep 2021 16:52:22 -0400 > From: Viktor Dukhovni <ietf-dane(a)dukhovni.org> > To: haskell-cafe(a)haskell.org > Cc: Michael Turner <michael.eugene.turner(a)gmail.com> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs > better writing, not better tools > Message-ID: <YUOuhjb3t0bYRkI0(a)straasha.imrryr.org> > Content-Type: text/plain; charset=us-ascii > > On Wed, Sep 15, 2021 at 04:07:38PM +0900, Michael Turner wrote: > > > The real problem is that the writing sucks. Not all of it -- and some > > contributors to the community are stellar writers, even if, in the > > snarkish commentary they write about Haskell and the community, I > > don't quite get all the jokes. But speaking as a contributor to the > > Haskell.org wiki -- to which I contribute at times out of hope that > > clarifying points I understand will also lead to more clarity for > > myself -- I have to say it: the writing sucks. > > Can you be a bit more specific about which sort of writing you find > sufficiently unsatisfactory to say "the writing sucks"? > > * Books about Haskell > - Introductory (e.g. http://learnyouahaskell.com/) > - Comprehensive (e.g. the classic Real World Haskell) > - Topic focused (e.g. the IMHO rather excellent Parallel and > Concurrent Haskell) > - Theory focused (e.g. > https://bartoszmilewski.com/category/category-theory/) > - ... > * The library reference documentation? > * The GHC User's Guide? > * The Haskell report? > * Blog posts? > * The Haskell Wiki? > * r/haskell? > * Haskell mailing lists? > ... > * All of the above??? > > I am also curious whether I'm part of the solution or part of the > precipitate. I've recently contributed new documentation for > Data.Foldable and Data.Traversable: > > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-F… > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-T… > > are these a step in the right direction, or examples of more writing > that sucks? These are reference documentation, not beginner tutorials, > so a more detailed write up of the concepts, pitfalls, ... things to > keep in mind when using library, ... > > More of that sort of thing would help me to more quickly learn to use > some of the libraries that lack this sort of overview prose, but perhaps > what you're looking for is something else? > > -- > Viktor. > > > ------------------------------ > > Message: 2 > Date: Thu, 16 Sep 2021 16:57:28 -0400 > From: David Feuer <david.feuer(a)gmail.com> > To: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> > Cc: Michael Turner <michael.eugene.turner(a)gmail.com> > Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs > better writing, not better tools > Message-ID: > <CAMgWh9tRX=r8MMSvzTGMr2iQMcgzKwdRc7SF=zx2wgPXPojN+A(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I am not a fan of how the new Traversable documentation buries the actual > laws. > > On Thu, Sep 16, 2021, 4:55 PM Viktor Dukhovni <ietf-dane(a)dukhovni.org> > wrote: > > > On Wed, Sep 15, 2021 at 04:07:38PM +0900, Michael Turner wrote: > > > > > The real problem is that the writing sucks. Not all of it -- and some > > > contributors to the community are stellar writers, even if, in the > > > snarkish commentary they write about Haskell and the community, I > > > don't quite get all the jokes. But speaking as a contributor to the > > > Haskell.org wiki -- to which I contribute at times out of hope that > > > clarifying points I understand will also lead to more clarity for > > > myself -- I have to say it: the writing sucks. > > > > Can you be a bit more specific about which sort of writing you find > > sufficiently unsatisfactory to say "the writing sucks"? > > > > * Books about Haskell > > - Introductory (e.g. http://learnyouahaskell.com/) > > - Comprehensive (e.g. the classic Real World Haskell) > > - Topic focused (e.g. the IMHO rather excellent Parallel and > > Concurrent Haskell) > > - Theory focused (e.g. > > https://bartoszmilewski.com/category/category-theory/) > > - ... > > * The library reference documentation? > > * The GHC User's Guide? > > * The Haskell report? > > * Blog posts? > > * The Haskell Wiki? > > * r/haskell? > > * Haskell mailing lists? > > ... > > * All of the above??? > > > > I am also curious whether I'm part of the solution or part of the > > precipitate. I've recently contributed new documentation for > > Data.Foldable and Data.Traversable: > > > > > > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-F… > > > > https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-T… > > > > are these a step in the right direction, or examples of more writing > > that sucks? These are reference documentation, not beginner tutorials, > > so a more detailed write up of the concepts, pitfalls, ... things to > > keep in mind when using library, ... > > > > More of that sort of thing would help me to more quickly learn to use > > some of the libraries that lack this sort of overview prose, but perhaps > > what you're looking for is something else? > > > > -- > > Viktor. > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. >

4 3

Haskell reference documentation, laws first or laws last?
by Viktor Dukhovni 04 Oct '21

04 Oct '21

On Thu, Sep 16, 2021 at 06:51:42PM -0400, David Feuer wrote: > The last time I went to look at the laws it took me a couple minutes to > find them. I use them to write instances. Pretty important, IMO. I agree the laws are important to document, I just don't think they belong at the top of the module. The beginner to intermediate users will be using the library and existing instances for some time before they start to write their own instances. If more modules adopt something like the style of the new Data.Foldable, experienced users will know to look for the laws at the end, if not still present at the top of the module. Of course perhaps the community would prefer the original Laws first format, I'm fine with that emerging as the consensus. Perhaps worthy of a separate thread (made it so). Of course the conjectured users who might most benefit from not being intimidated by being exposed to laws before they're ready to understand them might not be present on this forum... -- Viktor.

7 14

Haskell's "historical futurism" needs better writing, not better tools
by Michael Turner 04 Oct '21

04 Oct '21

I haven't been able to view Andrew Boardman's video so far, but I gather from the summary that he feels the solution to the most pressing problem -- growth through fostering newbies -- is simply . . . better tools. I beg to differ, as a newbie who is now struggling with the revival of some Haskell code only with a feeling of claustrophobia. Where is this incredible feeling of freedom I was promised? At the top of the learning curve. And it feels like a Sisyphean slope -- the boulder stops, when I lay off learning, and then slowly starts to roll down under the gravitational force of memory decay. The real problem is that the writing sucks. Not all of it -- and some contributors to the community are stellar writers, even if, in the snarkish commentary they write about Haskell and the community, I don't quite get all the jokes. But speaking as a contributor to the Haskell.org wiki -- to which I contribute at times out of hope that clarifying points I understand will also lead to more clarity for myself -- I have to say it: the writing sucks. Why does it suck? Well, there are several syndromes. One is to think that Haskell is so incredibly good and pure and elementally profound that one must start conceptually from scratch. (I've actually been curtly informed on the beginners' list -- yes, the beginner' list! -- that my problems of comprehension can be solved simply: "Learn lambda calculus.") I've had a book recommended to me whose author had such pretensions to writing in a way that was easily foundational that he actually claimed his book could teach you Haskell even if you have no programming experience at all. Now, in practical marketing terms, that's just silly: such an approach addresses a minuscule fraction of the book's potential audience. If you've heard of Haskell as a programming language, you're probably software-multilingual already. But in practical pedagogical terms, it's also a little ridiculous. Your average reader (already a programmer) would be better served by a comparative approach: Here's how to say something in a couple of other programming languages, here's how to say something roughly equivalent in Haskell -- BUT, here's how it's subtly different in Haskell. Here's how Haskell makes something easier (at least perhaps in being more concise, if the Haskell is more concise) but also conferring useful leverage where Haskell might otherwise seem unnecessarily verbose. The problem of better writing is ultimately social, I believe. I have a friend who's a tenured professor at Columbia University, who has used Haskell in courses, who praises Haskell for how it makes students think a little more clearly about how to structure software. However, his final verdict is this: Functional programming is a cult. Now, he's a unabashedly abrasive type. (Just ask him, he'll tell you.) And that verdict IS a little over the top. But I have to say, my impression of the community is that there are Founder demi-gods praised even though they leave something to be desired in how articulate and clear they are for newbies, even when claiming to be addressing newbies, while the language itself seems to be somewhat an object of worship. How can the writing be better? Well, here's a clue: Simon Peyton-Jones, somewhere in a talk where he was his usual vibrant self (but where the audience was clearly stunned and intimidated into silence even though he'd invited people to interrupt with questions) said that F# had settled on the term "workflow" instead of "monad", and he felt this was wise. Workflow? Workflow!? My still-feeble understanding of monads took a leap forward, because suddenly I had a motivation for them: abstraction of the idea of a workflow. Could it be that something as simple as Maybe was a kind of "degenerate case" of a "workflow abstraction"? I felt massively encouraged that I might finally figure out how great monads were. Which is not to say that I have. Writers: you need to stop speaking your own obscure little dialect of "programmer English". If you're not aware that you are, become more self-aware. If you ARE aware of it, become aware of how snobbish or pointlessly mysterious you sound. And if you do become aware of how you sound, but don't care, ask yourself: if the goal now is to spread Haskell and help it flourish, isn't your attitude more of a hindrance than a help? Tools? That's not the front I'd pick. Because I hit a glitch in getting VScode to work under Windows 10 (yes, cue the snobbery), I backed off to github bash and vim. And you know what? It's fine. Sorry if my knuckles seem to be dragging on the floor, but I'm from the Stone Age of Unix v7 command line and Bill Joy's original vi. I'd like nicer tools. But they aren't likely to help me with Haskell. What's not fine: half the time, I can't figure out the error messages from GHC, and a dismaying portion of the time, I can't figure out the language documentation. And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages) they often don't really stick. It's like my Sysiphean boulder has been pre-greased -- if I stop pushing (hard enough with all the abstraction grease on it), it starts to slide even before it rolls, whenever I leave off coding in Haskell for any length of time. Sorry for not writing better email here -- my sentences get rather long and tortuous when I rant. But not sorry for ranting. You say the solution to a tool adoption problem (getting more people to use Haskell) is yet more tools written in Haskell, for your favorite language, Haskell? No. The failure here is a failure to communicate. Regards, Michael Turner Executive Director Project Persephone 1-25-33 Takadanobaba Shinjuku-ku Tokyo 169-0075 Mobile: +81 (90) 5203-8682 turner(a)projectpersephone.org Understand - http://www.projectpersephone.org/ Join - http://www.facebook.com/groups/ProjectPersephone/ Donate - http://www.patreon.com/ProjectPersephone Volunteer - https://github.com/ProjectPersephone "Love does not consist in gazing at each other, but in looking outward together in the same direction." -- Antoine de Saint-Exupéry

7 26

Seeking community input on change to Haskell.org Downloads page
by Tom Ellis 03 Oct '21

03 Oct '21

The Haskell.org committee is considering a change to the [Haskell.org Downloads page]. The change is being reviewed in a [GitHub PR]. The specifics of the change are to replace Chocolatey with ghcup as the preferred installation method of GHC, cabal-install and haskell-language-server on Windows. The overall effect is that the install instructions become common over Windows, Linux and MacOS. The Chocolatey install method is mentioned further down the page. (The PR does not impinge on Stack. The Stack instructions remain unchanged.) The committee would welcome input from any interested parties, particularly those who have familiarity with Chocolatey, or ghcup on Windows, or both. You are welcome to comment on the [PR itself][GitHub PR] (or this thread if absolutely necessary). Thanks to @bodigrim for the PR. [Haskell.org Downloads page]: https://www.haskell.org/downloads/ [GitHub PR]: https://github.com/haskell-infra/www.haskell.org/pull/125

3 3

Re: [Haskell-cafe] Improving the docs (specifically Data.Foldable)
by Anthony Clayden 02 Oct '21

02 Oct '21

At *Fri Oct 1 01:42:39 UTC 2021* Ben Franksen wrote >> Am 17.09.21 um 07:15 schrieb Michael Turner:>> >>* "The contribution of each element to the final result is combined with an *>>* accumulator via an /operator/ function. The operator may be explicitly *>>* provided by the caller as in `foldr` or may be implicit as in `length`. In *>>* the case of `foldMap`, the caller provides a function mapping each element *>>* into a suitable 'Monoid', which makes it possible to merge the per-element *>>* contributions via that monoid's `mappend` function." *> >>* This is a little better, but I'd write it this way, I think. *>> >>* "Folds take operators as arguments. In some cases, it's implicit, as *>>* in the function "length". These operators are applied to elements when *>>* lazy evaluation requires it, with a fold 'accumulator' as one of the *>>* operands. 'foldMap' uses a function (implicit? explicit?) that maps *>>* elements into . . . ." * > The problem you two are both facing is this: you want to describe, > abstractly, generally, the common principle behind an ad-hoc > lumped-together set of functions. This is very likely to result in > contortions and provides you with no insight. I think neither "ad-hoc" nor "lumped-together" is accurate. For both `Functor t` and `Foldable t` the metaphor is `t` as container. * For `Functor` we wish to preserve the shape/spine and mangle each element irrespective of other content. * For `Foldable` we wish to throw away the shape/spine and return some characteristic of the contents-as-a-whole. (The fold is possibly returning another container/contents, but it won't necessarily be the same `t`; even if it is, the result won't be the same shape/spine.) There are some frequent use-cases for "characteristic of the contents-as-a-whole": count, sum, min/max, is-element. So it makes sense to provide (possibly optimised) methods. Yes the insight is that there's a common principle. But the optimising devil is in the detail. The devilish detail is that although we're going to throw away the shape/spine, knowing its organising principle will help navigating it effectively. Otherwise we could stick with List as container -- but as Ref [1] points out, that's hardly ever wise. For somebody coming to the docos to generate their own `instance Foldable`, thinking in terms of `toList` might help in getting the right result; it won't explain why they'd want to use something other than a List.

2 1

Stack lock issue
by Dominick Samperi 01 Oct '21

01 Oct '21

Hi, Stack install does its thing in some hashed directory under .stack-work by default, but I want to write to <package-root>/bin as part of the configure process. I'm trying to do this as follows: -- configure file contains: cd $(stack path --project-root) echo "..." > .bin/foo.sh cd - > cd <project-root> > stack install I'm doing this under Windows with the born shell in my path. Problem: the use of stack to find the project-root directory is blocked waiting for the outer stack to terminate! This may have something to do with Windows "Device or resource busy" lock. Is there a better way? Thanks, Dominick <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Virus-free. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

1 0

Cabal or stack in 2021 ?
by Alexis Praga 01 Oct '21

01 Oct '21

Hi, As an intermediate beginner, I've been back into Haskell for the last months for a small project, using stack as the building tool. Why stack ? A few years back, I learned that it was the "best" way to build projects to avoid "cabal hell", which I understood at the time as "managing dependencies with cabal is hard". As such, I've use stack since and have been quite happy with it. The only drawback is that building a project can be quite long. This is usually not a problem, except for writing Haskell scripts using shelly (for example), where the stack layout is a bit impractical for fast-paced development. A solution is to use `runghc` or a script interpreter [1]. However, I've seen some projects where cabal is used to build directly instead of cabal, so it looks like the situation improved. My question is this: in 2021, is there a reason to switch back to cabal ? Thanks, [1] https://www.fpcomplete.com/haskell/tutorial/stack-script/ -- Alexis Praga

8 11