[Haskell-cafe] Haskell's "historical futurism" needs better writing, not better tools

[Michael Turner]

I might have missed your link to "Monoid" because my attention fell on
"monoid mappend". Sorry for that.

"The contribution of each element to the final result is combined with an
   accumulator via an /operator/ function.  The operator may be explicitly
   provided by the caller as in `foldr` or may be implicit as in `length`. In
   the case of `foldMap`, the caller provides a function mapping each element
   into a suitable 'Monoid', which makes it possible to merge the per-element
   contributions via that monoid's `mappend` function."

This is a little better, but I'd write it this way, I think.

"Folds take operators as arguments. In some cases, it's implicit, as
in the function "length". These operators are applied to elements when
lazy evaluation requires it, with a fold 'accumulator' as one of the
operands. 'foldMap' uses a function (implicit? explicit?) that maps
elements into . . . ."

And this is where I bog down, because I don't know what makes a monoid
'suitable' or even really what a monoid is -- it's been a long time
(25 years or so) since my last abstract algebra course.

I don't doubt that you're doing something good here. It's just that
I'm frustrated about what's in the way of benefitting from it. I
gather that there's something about the algebraic properties of folds
that makes some code easier to write and understand, once you have the
underlying concepts fully understood. My biggest problem is probably
out of scope for what you're working on: I need motivating examples.
I've used folds in other programming languages. But how they can be
algebraically leveraged is still beyond me. I still remember
installing a Haskell command-line parser for my project code and
marveling that "semigroup" was one of its dependencies.

My main concern is whether I can use Haskell for a natural-language
processing project. Here, I started on a long Haskell primer for
linguists, in case I leave any useful code behind that linguists might
need to maintain. But also, I sometimes find that understanding comes
from writing. Did I write it clearly? If not, is it because I don't
really understand it? If I don't, writing tells me where I need to dig
deeper.

"Haskell in Plain English: A Primer for the Lexical Semanticist"
https://docs.google.com/document/d/1GIDWMbFBAaOZc-jxOu1Majt6UNzCpg4vxMGeydb421M/edit

In that piece (no, don't read it if you're not interested in
linguistics), I remark that the algebraic facet of Haskell practice
may not be very useful for natural language parsing and understanding.
The truth is: I'd prefer to be proven wrong about that. This area is
so hard, we need all the good tools we can get. IF abstract algebra
could be useful for this application, I want it.

Regards,
Michael Turner
Executive Director
Project Persephone
1-25-33 Takadanobaba
Shinjuku-ku Tokyo 169-0075
Mobile: +81 (90) 5203-8682
turner at projectpersephone.org

Understand - http://www.projectpersephone.org/
Join - http://www.facebook.com/groups/ProjectPersephone/
Donate - http://www.patreon.com/ProjectPersephone
Volunteer - https://github.com/ProjectPersephone

"Love does not consist in gazing at each other, but in looking outward
together in the same direction." -- Antoine de Saint-Exupéry

On Fri, Sep 17, 2021 at 1:24 PM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> On Fri, Sep 17, 2021 at 11:27:12AM +0900, Michael Turner wrote:
>
> > > I am also curious whether I'm part of the solution or part of the
> > > precipitate.  I've recently contributed new documentation for
> > > Data.Foldable and Data.Traversable:
> > >
> > >     https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-Foldable.html#g:7
> > >     https://dnssec-stats.ant.isi.edu/~viktor/haskell/docs/libraries/base/Data-Traversable.html#g:4
> >
> > OK:
> >
> > "Merging the contribution of the current element with an accumulator
> > value from a partial result is performed by an operator function,
> > either explicitly provided by the caller as in foldr, implicit count
> > as in length, or partly implicit as in foldMap (where each element is
> > mapped into a Monoid, and the monoid's mappend operator performs the
> > merge)."
> >
> > Let me tell you how I tried to read that lo-o-ong sentence.
>
> If I may trouble you just a bit longer, I'd like to ask whether the
> problem is the phrasing, or the selection of subject matter.  If the
> latter, then any defects in the phrasing are perhaps moot.
>
> Supposing I rephrase the same thing as:
>
>    The contribution of each element to the final result is combined with an
>    accumulator via an /operator/ function.  The operator may be explicitly
>    provided by the caller as in `foldr` or may be implicit as in `length`. In
>    the case of `foldMap`, the caller provides a function mapping each element
>    into a suitable 'Monoid', which makes it possible to merge the per-element
>    contributions via that monoid's `mappend` function.
>
> Does that help?  At all?  Enough?  The word "Monoid" hyperlinks to the
> documentation of that class, and I thought it fair to reference Monoids
> in the reference documentation for a module that defines `foldMap`.
>
> If the above is helpful, I am not too proud to rewrite any paragraphs
> that are poorly phrased, if there is some merit in the subject matter.
>
> I don't think the module overview can be a beginner tutorial, that's
> more the domain of books, ...  I think that the descriptive prose in the reference
> docs that follows the function synopses just need to cover any concepts
> and API behaviours that don't immediately follow from those synopses.
>
> A rough guide for me were Unix manpages, where e.g. setsockopt(2) is not
> a networking tutorial, and yet still has a bunch of useful prose, and not
> just function signatures.
>
> --
>     Viktor.