Would you consider doing an edit/follow up using more user friendly variable names? This is super interesting and I just noticed that it was easy to get lost with the filler variables if you weren't reading closely. This can be a problem to new coders/coders from other backgrounds.
I know that you were using the examples from the article you linked, but having a stand-alone series on this could be useful/interesting, especially with a Typescript focus. As someone with 0 Haskell exposure, I found the original article hard to grok.
Would you consider doing an edit/follow up using more user friendly variable names? This is super interesting and I just noticed that it was easy to get lost with the filler variables if you weren't reading closely. This can be a problem to new coders/coders from other backgrounds.
I know that you were using the examples from the article you linked, but having a stand-alone series on this could be useful/interesting, especially with a Typescript focus. As someone with 0 Haskell exposure, I found the original article hard to grok.
Thanks for the article.
My guess reading the original article is that the naming convention is based on the contraction of the signatures, so
(a: A) => Bbecomesab(a: A) => numberbecomesan(an: (a: A) => number) => numberbecomesannActually it looks good to me as the examples are such a general functions but I'm open to alternatives, what naming convention are you proposing?
I personally would use variable names that describe what the values mean and do
could be