October 2021 - Haskell-Cafe

Re: [Haskell-cafe] Pattern guards seen in the wild?
by Anthony Clayden 01 Oct '21

01 Oct '21

Thank you all for the examples. Hehe real-world data structures are messy. Especially if dictated by systems utilities that don't care for functional programming. In the back of my mind is: do these idioms date from before there were pattern synonyms? Would matching to a pattern synonym give clearer code in the case branching? (Would it be worth declaring a synonym for just one usage?) There's only one of those examples where I feel expressing without the Pattern guard would be awkward. Tom's example 1., whose characteristics are: * There's a long straggly sequence of matchers; * With a particularly awkward branch in the middle, needing sub-analysis of a _component_ of the scrutinee, and only if such a component is present; * If the sub-analysis fails to match, the logic must unnest itself and resume matching at the next branch of the straggle. The awkward branch (slightly reformatted) is > (GET, [x]) | Just (path', mime) <- List.lookup x staticFiles > -> Just (StaticFile mime path') `staticFiles` is a module-wide variable, so matching is looking outside the scrutinee, therefore couldn't be expressed as a pattern synonym. The `lookup` might return a `Nothing`, so the inner pattern match could fail/this is doing more than a 'local binding' with `let`, which "always succeed" says the Language Report.

1 0

Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools
by Anthony Clayden 01 Oct '21

01 Oct '21

Hi Michael, oh dear, oh dear, oh dear. The seeds of your confusion are very evident from your message. How to back you out of whatever deep rabbit-hole you've managed to get your head into? > ... 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. No. Just no. Haskell is not "subtly different" to (say) Java in the way that C++ or C# are different. (I'll leave others to judge how subtly different they are.) Haskell is dramatically and fundamentally different. You can't just 'translate' an algorithm from OOP to Haskell. Many newbies try, and there's many tales of woe on StackOverflow. Just No. I really don't know how you could have got any experience with Haskell and say "subtly". I suggest you unlearn everything you think you know about Haskell, and strike out in an entirely different direction. The best approach would be to spend a few days playing with lambda calculus. (That's what I did before tackling Haskell.) > (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.") Lambda calculus is an excellent place for beginners to start. What could be easier to learn? It's certainly easier than grokking a Turing machine; and much easier than Haskell: less than a handful of primitives yet can compute anything computable. > And since the concepts are seldom described in concrete enough and time-honored programming language terms (by comparison to other programming languages) I'm guessing that the concepts you're talking of simply don't correspond to anything in time-honoured (procedural) programming. Anybody writing about Haskell (including anybody writing the User Guide) assumes a base level of understanding of Haskell. You've clearly veered off the track and haven't yet reached base. Remember the User Guide builds on top of the Language Report. (On the point of 'time-honoured': lambda calculus is almost exactly the same age as Turing machines. The first well-known programming language using lambda-calculus ideas (LISP 1966) is almost exactly the same age as the first OOP language (Simula 1967). Which is the more time-honoured?) You do have a point that the terminology in Haskell is often mysterious > [SPJ said] F# had settled on the term "workflow" instead of "monad", and he felt this was wise. Yes many have yearned for a more warm-and-cuddly term than "monad". But the terminology barrier starts before that. Haskell typeclasses are not 'classes' in any sense recognisable from OOP. There are no objects, no hidden state, no destructive assignment. We might go back to February 1988 when a strawman for what became typeclasses used OVERLOAD/INSTANCE. AntC

5 5

Re: [Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools
by Anthony Clayden 01 Oct '21

01 Oct '21

> Switching subtopics to the "Chirality" section, ... I take Ben's point (with which I agree) to be that "Chirality" is an even more obscure word than "Endomorphism". (Except perhaps in the realm of subatomic particle physics.) Grokking this material is hard enough without having to reach for a dictionary. If you mean 'left-biased' vs 'right-biased', or 'from-front' vs 'from-rear' or 'Cons-oriented' vs 'Snoc-oriented', say that. (And I'll be interested to see how anyone explains this without `fromList` jigging their elbow.) Now I can see Foldable structures are abstract, not spatial. But Cons is recursive on its (textually) right operand, whereas `Bin` or `Node` are symmetric between their (textually) left/right recursive operands. I guessed that's what the Chirality section was talking about, so I skimmed the first sentence and skipped on.

3 2

Re: [Haskell-cafe] Pattern guards seen in the wild?
by Anthony Clayden 01 Oct '21

01 Oct '21

Thanks Viktor, you've answered (in the negative) one of my follow-on q's which was: isn't the comma just standing for Boolean `&&` ? > which would otherwise be something like: ... I would go: > smtpGreeting :: Int -> SmtpReply -> SmtpM B.ByteString > smtpGreeting _ r = > | replyCont r = pure B.empty > | code `div` 100 /= 2 = B.empty <$ modify' bail code > | otherwise = smtpSendHello > where > code = replyCode r > bail code s = > s { smtpErr = ProtoErr code $ replyText r } > but I find the pattern guard form to read "declarative", Hmm? Your `code <- ...` left-arrow doesn't look at all declarative to me. It's reminiscent of a binding in a do-block, or a 'source' in a comprehension. Strong imperative/sequential overtones. > with less "if then else" baggage and nesting getting in the way of seeing the essential conditions. My suggestion above also avoids "if then else". I guess a case of de gustibus ... To my taste, GHC Haskell is just too bloated/there's too many (equivalent) ways of writing code/there's too many idioms I have to keep up with to read code. It's not that there's anything particularly 'wrong' with any one of them; it's the sheer number of them. I'd have to say patterns/matching suffer a low power to weight ratio, where 'weight' means syntactic clutter and gotcha's: View pattern arrow-from-nowhere, I'm looking at you; pattern signatures double-forall's, empty forall's, double-constraints, I'm looking at you.

1 0