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