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?