September 2021 - Haskell-Cafe

[ANN] cabal-clean (new tool)
by Andreas Abel 19 Aug '22

19 Aug '22

=== Wondering where your disk space goes with too many Haskell projects compiled with too many GHC versions? === https://hackage.haskell.org/package/cabal-clean https://github.com/andreasabel/cabal-clean `cabal-clean` is a small executable that removes outdated cabal build artifacts from `dist-newstyle`. A build tree is considered outdated if there is one with either - a newer version of the package you are building, or - a newer minor version of the GHC compiler. In contrast to `cabal clean`, the tool `cabal-clean` retains the latest build trees for each GHC major version. Thus, it is geared towards multi-GHC development. Example: (self-applied to cabal-clean's build directory) --- 3.7M ghc-8.8.4 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210815 --- 3.7M ghc-9.0.1 /cabal-clean-0.1.20210815 --- 3.5M ghc-8.10.6/cabal-clean-0.1.20210924 +++ 3.6M ghc-8.10.7/cabal-clean-0.1.20210924 +++ 3.7M ghc-9.0.1 /cabal-clean-0.1.20210924 The directories prefixed with --- will be deleted, the ones with +++ retained. Disclaimers: 1. cabal-clean does not check whether deletion will cause dangling references like broken symlinks etc. (Could happen if you created a symlink to an executable that resides in one of the deleted build directories.) 2. cabal-clean does not read nor utilize information from the .cabal file. 3. Calls `du` ("disk usage"), so, might not work on Windows. Enjoy, Andreas

6 6

Some Love for wxHaskell
by Tilmann 30 Jan '22

30 Jan '22

Hi cafe, I think wxHaskell needs some love :) Over the years I've written a small client for FICS (Free Internet Chess Server) and wxHaskell has served me really well. Also, wxWidgets seems solid and alive.. but today, wxHaskell is lagging behind updates and seems *sniff* dead. Is someone working on wxHaskell atm? I'd love to connect and help. If not, is there some interest to rejuvenate wxHaskell? Who is also depending on wxHaskell and wants to keep it going? Or, is it time to move on to gtk or reflex? Very much looking forward to your replies! Best, Tilmann

3 4

Do something about Cabal?
by Ignat Insarov 03 Jan '22

03 Jan '22

# Do something about Cabal? Hello. Cabal is the second most used tool in Haskell after GHC. It has many problems. It may be noticed that there is one and a half developers working on it. This is clearly not enough to address these problems. I propose that this is a good place to invest in. ### Problems I have in mind: * Poor communication, lack of open source development process. The whole Cabal–Stack schism appears to be an outcome of poor communication. One of the leading developers of Cabal is even banned from participation somewhere in Stack circles.[1] Personally, I reported several issues to Cabal and every single time it resulted in sadness. Observe a vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒ there are fewer contributors ⇒ core developers are overworked. I have no hard evidence but it appears that presently, more people that strive to improve the Haskell build experience are outside the Cabal cabal than are inside. * User experience is an afterthought. Cabal's user experience is horrifying. A collection of complaints is being compiled elsewhere.[2] There are also bugs being opened to Cabal because of this, requiring triage and therefore wasting the precious time of the few overworked developers. Stack is much more friendly — this shows by example that the user experience problem is not inherent and may be solved. It is ordinary to receive output like this: ``` % cabal run example-executable Warning: The package list for 'hackage.haskell.org' is 84 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: example-0.1.0.6 (user goal) [__1] next goal: opaleye (dependency of example) [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project config TODO requires ==0.6.7006.1) [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7) [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2, opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1, opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0, opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0, opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0, opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3, opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0, opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the previous version to fail: excluded by constraint '^>=0.7' from example) [__1] fail (backjumping, conflict set: example, opaleye) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: opaleye, example ``` There are so many things that are wrong here. Even a sneaky _«to do»_ remark. If you wonder, in this case the solution is to remove and re-generate `cabal.project.freeze`. Even the name of the program — it is actually _«cabal-install»_ — is incomprehensible, it should be re-branded to Cabal, which is how everyone calls it anyway. * Features are not being introduced. There is no reason for two build tools to exist. The killer feature of Stack — snapshots — should be supported by Cabal. Possibly Cabal itself should be refactored and split so that there are separate tools for packaging, version resolution and human interaction — I do not know. But certainly the way things are presently is a waste of developer effort and a source of confusion for everyone. ### My proposition, in particular. * Ask all the people that show compassion to the cause of a great Haskell build tool to unite and work together on a better Cabal. This includes the developers of Stack and everyone that expressed unhappiness with the current state of Cabal. These people should be seen as a blessing, not as an obstacle. * Put in place a clear process for contributing and decision making, so that it does not come down to the privileged opinion of one of the core developers. * Make a model of user experience that Cabal should conform to, and make conformance a priority. Surely there are among us people that know a thing or two about user experience — call for them to step forward. Every issue that stems from misunderstanding, re-assign to the model instead of closing. * Merge the support of Stackage snapshots into Cabal. Ask the core developers of Stack to join the effort. Transition from Stack to Cabal should be one well discoverable command that just works. I realize that this letter is largely an opinion piece. You can also see it as an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the present. I do not insist that my vision is the best. But the present reality is not the best vision either. I propose, foremost, that we work and fight for a better future. [1]: https://github.com/commercialhaskell/stackage/issues/4472 [2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal

23 39

Numerics (was: Re: Trouble with asinh)
by Barak A. Pearlmutter 25 Oct '21

25 Oct '21

The numerics in Haskell have not been carefully vetted, for a variety of reasons. Not just under MS Windows, even under Linux. Here's an example: atan has drastic loss of precision in the imaginary direction around zero in the complex domain. $ ghci GHCi, version 8.8.4: https://www.haskell.org/ghc/ :? for help Prelude> :m + Data.Complex Prelude Data.Complex> tan (1e-20 :+ 0) 1.0e-20 :+ 0.0 Prelude Data.Complex> atan (1e-20 :+ 0) 1.0e-20 :+ (-0.0) Prelude Data.Complex> tan (0 :+ 1e-20) 0.0 :+ 1.0e-20 Prelude Data.Complex> atan (0 :+ 1e-20) 0.0 :+ (-0.0) Although there have been amazing efforts to use fancy PLT methods to improve the numerics of programs using source-to-source transformations and such, the boring janitorial work of checking and fixing numeric issues in the standard library doesn't seem to attract people. To be fair, it isn't my cup of tea either...

6 7

Examples of Continuation monad that impossible to understand and maintain?
by YueCompl 08 Oct '21

08 Oct '21

Dear Cafe, I'm wrapping up my CPS codebase to provide some monadic interface, it appears almost the Cont monad, so the following statement is a pretty valid caveat to me now: > Abuse of the Continuation monad can produce code that is impossible to understand and maintain. Which can be viewed in context of Hackage at: https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… <https://hackage.haskell.org/package/mtl/docs/Control-Monad-Cont.html#:~:tex… of the Continuation monad can produce code that is impossible to understand and maintain> But I can't find concrete examples demonstrating the "impossible to understand and maintain" situation, in figuring out what pitfalls I'd rather to avoid. Please share what you know about it, many appreciations! Background of my CPS necessarity: Library code need to delegate STM transaction boundary delimitation to (scripting) application code, though `inlineSTM :: STM a -> m a` can be used to force some action to be within current tx, the usual `>>=` binding should honor whether a separate `atomically` tx should be issued for its rhs computation, as specified by the scripting context. Thanks, Compl

4 8

Re: [Haskell-cafe] mine sockets lib vs yesod
by Branimir Maksimovic 06 Oct '21

06 Oct '21

> On 27.09.2021., at 12:13, Mikolaj Konarski <mikolaj.konarski(a)gmail.com> wrote: > > Hi Branimir, > >> I guess that if I port it to Haskell purely from CPP, I won’t have problems with copyright? > > I will retain exactly the same copyright it had. To get rid of the old > copyright, you'd need to clean-room re-implement it (you yell ideas > from another room and somebody implements them in Haskell not having > seen the CPP code beforehand). OK. > >> if using -threaded performance is *worse*. > > This is normal. You trade performance for the ability to pre-empt > (e.g., not get stuck on blocking FFI). > > Kind regards, > Mikolaj I will implement it whole in Haskell, in async fashion as it seems with current hardware bandwith is saturated with just single CPU/Core. Greettings, Branimir.

1 1

Re: [Haskell-cafe] On finding the right exposition...
by Anthony Clayden 05 Oct '21

05 Oct '21

> GHC's use of a State-like monad to represent I/O is semantically bogus, .... I wouldn't take it as a good mental model. Indeed. I fondly remember that in my intro text (the 'Gentle Introduction'), there was a warning this section is not so gentle. But I was already well through the book so it didn't seem such a drama. I'd already figured that 'mentally evaluating' code wasn't about contents of memory locations. For Monads esp I/O, 'programmable semicolon' or 'workflow' might be a better model. Ref the current discussion, I'm expecting a learner would spend a long time writing expressions at the ghci prompt; investigating their type; chucking in a few in-line decls with `let { }`. Dropping those decls into a source file -- which would contain only decls, not even a `module { }` header. A few simple `do{ ; }` blocks at the prompt. I was advocating lambda-calculus for the pure function evaluation parts of an intro. Higher-order functions, partial evaluation, operator sections, (un)currying. The o.p. was having trouble with a signature like `(a -> b -> c) -> a -> b -> d`. Later remarks expressed surprise why function application wasn't written `add(x, y)`. The (very old) paper mentioned was nearly all pure code. Without a firm basis grokking type signatures, the Monad operators are going to seem deeply weird. If you're used to 'higher-order function' meaning something that passes round an entry point for a block of code, partial application will take some head-scratching. And I can see if you're used to `x ++` meaning something and `x+=1` meaning something similar and `* y` meaning something completely different and `(x +)` being a syntax error, Haskell is going to feel strange. (Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be publicly flogged on a regular basis. Why couldn't they just follow the model of BCPL, which is far more elegant and consistent in its syntax. They stole nearly everything else from BCPL.) Which reminds me ... My all-time favourite language intro text is still http://rabbit.eng.miami.edu/info/bcpl_reference_manual.pdf This serves also as a language definition.This was thrown at undergrads, and they were left to get on with it. (There was also a 'User Guide' that talked about the operating environment, debugging, IO and file handling -- essentially equiv to Haskell's Appendixes on the base modules.) I note again, the language is small and elegant (expressible in A5 minimanual format). Similarly, you can get enough of lambda-calculus on a few sheets of A4. I contrast that 'Category Theory for Programmers' (mentioned in this thread) is 500 pages, and not even a language primer, although it contains snippets of code. How many hundred pages must I read before I'm allowed to write a Foldable instance? I'm up to 100, and we seem to be still preparing the ground for what is an endomorph.

4 5

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