[Haskell-cafe] Haskell-Cafe Digest, Vol 217, Issue 17
ben.franksen at online.de
Mon Oct 4 10:45:36 UTC 2021
Am 17.09.21 um 05:53 schrieb Michael Turner:
> No. I started here:
> 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
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.
I would rather have questions that cannot be answered, than answers that
cannot be questioned. -- Richard Feynman
More information about the Haskell-Cafe