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@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 wrote:

Send Haskell-Cafe mailing list submissions to haskell-cafe@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@haskell.org

You can reach the person managing the list at haskell-cafe-owner@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 To: haskell-cafe@haskell.org Cc: Michael Turner Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools Message-ID: 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-Fo... https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-Tr...

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 To: "haskell-cafe@haskell.org" Cc: Michael Turner Subject: Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools Message-ID: 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 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-Fo...

https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-Tr...

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.