- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] On finding the right exposition
by Douglas McIlroy 05 Oct '21

05 Oct '21

>> Aside: to this day, that sort of ad-hoc syntax makes me gag. K&R should be > publicly flogged on a regular basis. > And for so many other reasons, too, like mandating a preprocessor (with > a complex, operationally defined semantics) simply because they couldn't > be bothered to design a (simple, 1st order) module system. Manners, please. Such immoderate words have no place on this mailing list. Doug

1 0

Massaging data from the `extensible` package
by Ruben Astudillo 05 Oct '21

05 Oct '21

Hello cafe I have been enjoying the `extensible` package [1] for extensible records and variants, kudos to the author. I have had a problem of not understanding how to "massage" data from one representation to another. To exemplify, suppose I have the following two extensible records {-# language OverloadedLabels #-} import Data.Extensible import Control.Lens type Ext1 = Record '[ "field1" >: String, "field2" >: Integer ] type Ext2 = Record '[ "field1" >: Text, "field2" >: Double ] and I want to map some piece of data between these two types. Currently I am projecting each field individually like this ex1 :: Ext1 ex1 = #field1 @= "hello" <: #field2 @= 2.71 <: nil currentMap :: Ext1 -> Ext2 currentMap s = #field1 @= T.pack (view #field1 s) <: #field2 @= fromInteger (view #field2 s) <: nil For data types with few fields it is not so bad. But I have to do this transformation of data types generated from TH, I am dealing with a few dozens. The transformations are always from `String -> Text` and `Integer -> Double`. I would like to write a high lever combinator that grabs an extensible record, transforms each `String` field on a `Text` one and does the same with `Integer -> Double`. Most of the combinators for transforming the data deal with natural transformations, such as hmap, hsequence and the like. The closest one to what I want is `hfoldMapFor` where I have to define a class with instances for all the types the extensible record has, but it doesn't let me change the type of the result. Does anyone have an idea on how to solve this? Thanks for your time. [1]: https://hackage.haskell.org/package/extensible -- Rubén. (pgp: 4EE9 28F7 932E F4AD)

3 5

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

Vectors, vector spaces and type-level Haskell
by Stuart Hungerford 04 Oct '21

04 Oct '21

Greetings Haskellers, I'd like to model in Haskell two-dimensional vectors that "belong to" or "have an ambient space of" a two dimensional vector space. I'm also ignoring for now the issue of which field the vector space is over. I realize this is not strictly necessary to just start using 2D vectors, but I would like to bring the vector space in as a first class concept. Looking at for example this approach: https://hackage.haskell.org/package/linear-1.21.7/docs/Linear-V2.html, I get the impression this is likely to need some kind of type-level construct? e.g. type families or type-level literals? I haven't started learning yet about Haskell type-level programming so I thought I'd ask for advice first to see how this could be done idiomatically in Haskell either with or without type-level concepts. TIA, Stu

4 11

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 218, Issue 5
by Stuart Hungerford 04 Oct '21

04 Oct '21

On Mon, Oct 4, 2021 at 11:10 PM <haskell-cafe-request(a)haskell.org> wrote: > [...] > The V2 and V3 etc. types provided by the linear package (which you > already found) model vectors in 2- and 3-dimensional real vector spaces, > over the field given by their 'a' type parameter. Wanting to add a > vector from a 2-dimensional vector space over 'a' and a vector from a > 3-dimensional vector space over 'b' entails adding a 'V2 a' and 'V3 b'; > those are distinct types. The vector space of 'V2 a' is morally 'a^2'. > > It seems this satisfies what you want. Are there other guarantees you > want enforced at compile time that this cannot give you? Thanks Tom -- you're right this is enough for compile time guarantees. This need to encode dimensionality into a type seems to be a compelling use-case for type-level numbers or other type-level capabilities (which I've avoided learning about until now). Stu

1 0

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