Proposal: Add (&) to Data.Function

[Edward Kmett]

On Tue, Nov 20, 2012 at 2:20 PM, Johan Tibell <johan.tibell at gmail.com>wrote:

> On Tue, Nov 20, 2012 at 11:11 AM, John Wiegley <johnw at fpcomplete.com>wrote:
>
>> And let's not forget that the current <%= operator would turn into <|>=,
>> which
>> is completely unfortunate because it has nothing to do with <|>.
>
>
> lens currently defines 99 operators. As much as I admire Edward's work, I
> don't think we should take the interaction of these operators into account
> when we define a very important, standard operator for composing functions
> that's supposed to be used by the Haskell ecosystem as a whole.
>

Yes, lens defines 99 operators. The vast majority of them fall into a
common scheme;

operator~  for functional update using a well known operatr
operator= for an update into state.
<operator~  for when you want the answer
<operator= for when you want the answer to what you edited in your state.

The filling for those operators is almost entirely standard and conveys
meaning you'd expect:

+, *, -, ^, ^^, **, ...

and they are provided because they minimize confusion for anyone who is
aware of the scheme or who has programmed in another c-like language.

They are provided for convenience, and them and the other names in lens
were selected after I had done a frequency analysis against the names
already used in hackage to minimize the impact of their selection. The
package is designed to ship batteries included with lenses for the stuff
people use from the platform. There are far more minimal lens libraries out
there.



That said, none of my major arguments in favor of & are lens specific.

   - & is remarkably underutilized in haskell due to the fact that it can't
   pair with |
   - It is much closer to the feel of ($) than (|>) to use a single
   character symbol.
   - It is shorter involves less visual noise than |>. This accumulates
   quite a bit in long chains of them.
   - Arguably, you can read it off the screen better.
   - |> from an existing Haskell-semiotics perspective looks like something
   that involves Control.Applicative. e.g. x |> a = x <|> pure

None of those are lens specific.

Now, were I being selfish, and caring solely about maximize the consistency
of my own design, I'd be pushing for (%), because (%) is similarly
under-utilized but for the one unfortunate occurrence in Data.Ratio that
encourages everyone to screw up and make useless Ratio Int's and provides
the nice `mod` denotation when (%=)'d


I often chain this & a lot, when defining records or working with zippers

   foo & bar .~ baz & quux .~ quaffle & ...

looks a lot less like linenoise than the longer

   foo |> bar .~ baz |> quux .~ quaffle |> ...

In fact it looks better than the % i championed originally, because it
reads off the screen much better.

At this time I have no intention of changing %=, etc. to consistently use &
instead of %. If (|>) was picked, those operators would still be (%=), not
(|>=). I clung to consistency in my initial choice of (%) over (|>)
originally, but in practice what I found I liked was the terseness of the
one character operator, not necessarily the consistency with (%=), etc.

I've already conceded that inconsistency between that (&) and (%=), etc. in
lens is better than slavish consistency, but I really don't like using a
two character operator where a 1 character operator will do.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121120/4b0ed65d/attachment-0001.htm>