[Haskell-cafe] Readable Haskell

[Ignat Insarov]

> Well, sometimes you have to compromise between legibility and
> conciseness, especially when distinguishing between variants. The FL and
> RL sequence types are ubiquitous in our code base and the convention of
> suffixing a function with them to indicate what type of parameter it
> takes is well established. I wouldn't want to write out "monoidConcat"
> instead of "mconcat" everywhere. (Or would that have to be
> "semigroupConcat" nowadays? Thankfully we could avoid bikeshedding this
> to death...) Or "foldRight" or even "foldAssociatingRightwards" instead
> of "foldr".

My proposition is twofold and this is a perfect illustration for both its sides.

1. `mconcat` is an example of a thing that benefits from mathematical
   style. Please by all means shorten it to death and standardize. Take it from
   7 symbols to 1 — best a beautiful pictogram. Same for `foldr`.

    > As regards type setting and unicode symbols, I am not a great fan of
    > that stuff.
    >
    > IMO it makes no sense to mimic mathematical style in any literal sense.
    > The point of a formula is not that it contains fancy special notation.

    It is not about what you think, it is about what you think others
    think. Quoting Leonardo Da Vinci:

    > It seems to me no small grace in a painter to be able to give a
pleasing air
    > to his figures, and this grace, if he have it not by nature, he
may acquire
    > it by incidental study in this way: Look about you and take the best parts
    > of many beautiful faces, of which the beauty is established
rather by public
    > fame than by your own judgement; for you may deceive yourself and select
    > faces which bear a resemblance to your own, since it would often seem that
    > such resemblance pleases us; and if you were ugly you would select faces
    > that are not beautiful, and you would then create ugly faces as many
    > painters do. For often a master's shapes resemble himself; so therefore
    > select beauties as I tell you and fix them in your mind.

    That is, you should make sure that your judgement of beauty is independent
    of your own opinion. The effort of type setters and font designers is not
    vain. Even if you cannot detect the difference, you can guess that it is
    there by observing the choices of others. One famous programmer even went as
    far as to design a type setting language, I am sure you know his name.

    > Besides, a lot of notational conventions in mathematics are not well
    > suited to programming or formally proving things. Many (if not most)
    > constructs that traditionally have special notation in math (e.g. sum,
    > integral, etc) are subsumed by the concept of a higher order function.
    > This has been well-known for several decades now, but the mathematical
    > community is extremely conservative with its established notation. …

    I am sure the functional programming community deserves some special symbols
    of our own. I know research papers introduce various shorthand conventions
    for folds and such. Question is, whether we can find it in ourselves to
    converge on a notation.

2. `ctxAddInvFL` is an example of a thing that benefits from English prose
   style. I have a speech about it.

    There are things that are well established and at the same time not
    justifiable. As a special case, use may outlive justification. My
    proposition is that creative shortening was justified back then, but now is
    a relic. Benefits diminished, while drawbacks are still the same:
    * Harder to invent names. In addition to coming up with a short explanatory
      English phrase, you have to invent a plausible shortening — extra work.
    * Harder to read. As you see, it is virtually impossible to determine what
      `Prim` stands for, and that is an easy example. Even in a suggestive
      context, it is a tax on the mind of the reader. It is hard enough to learn
      English.
    * A trtr of lngstc snsblty. Try wrtn a blg pst ths way & see wht rdrshp u
      get. To continue from the previous point — it is hard enough to learn
      English, why should one be forced to learn an English to read prose and an
      Ngl to read code? I would rather not, if only out of æsthetic sense.

    I am sure one gets used to it. And I imagine it becomes faster to read and
    write the code in a given project once you internalize the shortenings. So
    then it is an optimization for those _«in»_ and a penalty for those _«out»_,
    thus setting up a _«walled garden»_. Is that ever wanted?