[Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 17

[Ben Franksen]

Am 17.09.21 um 05:53 schrieb Michael Turner:
> 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.

Well, that's research papers for you. They are not tutorials for the 
programming language they use to illustrate their ideas. Nor are they 
intended primarily to show well-designed code.

(There *are* a fair number of exceptions, especially those that are 
published under the "functional pearl" rubric.)

> 'g' as a function name, a name not clearly related to
> any meaning?

It is a common idiom in Haskell to use a simple generic name like "go" 
or "doit" when you defer the bulk of the definition of a function to a 
local helper, reducing the main function definition to a trivial 
one-liner. I agree that using a single-letter name such as "g" for this 
purpose is bad style.

> Oh, and how about this type signature:
> 
> app :: (TTree -> TTree -> Tree) -> TTree -> TTree -> [TTree]

Yes, a type synonym here would have helped making the intention clearer.

Again, research paper vs. carefully engineered code. I am working in an 
electron accelerator, you should see the sort of mess physicists build 
as prototypes (and write their papers about).

What I do when i am confronted with such code is to refactor it until it 
is in a form I find easier to understand. It seems you arrived at a 
similar method for yourself.

Cheers
Ben
-- 
I would rather have questions that cannot be answered, than answers that
cannot be questioned.  -- Richard Feynman