Summary and call for discussion on text proposal

[Sterling Clover]

On Nov 7, 2010, at 12:51 PM, Edward Kmett wrote:

> On Sun, Nov 7, 2010 at 11:56 AM, Malcolm Wallace <malcolm.wallace at me.com> wrote:
> Option 3
> --------
> 
> breakStr :: Text           -> Text -> (Text, Text)
> breakChr :: (Char -> Bool) -> Text -> (Text, Text)
> 
> This give neither version the short name 'break', but gives both
> reasonably short names with a suffix to indicate the character
> predicate vs substring.
> 
> As a compromise between options 1 & 2, this option has merit.  It leaves open the possibility that the signatures of the short names might yet be decided at a later date.  If Bryan were willing to go with this option, I would certainly support it.
> 
> +1. I too think Option 3 has merit, if only because it resolves the current logjam, and still leaves open the possibility for consensus to be reached on the short names at some point in the future without either side feeling disadvantaged -- but do we really really have to randomly abbreviate Char and String?
> 

"A good compromise is when both parties are dissatisfied, and I think that's what we have here." -- Larry David.

+1. If Bryan finds this an acceptable compromise, then we should proceed. Preferably breakChar and breakText, but anything along those lines is good for me. Future usage can then teach us what we can only speculate over now -- which functions do indeed turn out to be more common, useful, and necessary, and the degree to which relationship to the list API does or does not provide a point of utility or confusion.

I also want to make the case that this hasn't been a pointless bikeshedding discussion, although it has been slow. There's a valid case for uniformity, and a valid case for package-specific APIs. Uniformity is a good thing to strive for across the Haskell Platform, and is a key part of providing a set of basic libraries. We've done a better job with uniformity thus far than e.g., the OCaml community, and thus, unlike OCaml Batteries (http://batteries.forge.ocamlcore.org/doc.preview:batteries-alpha3/html/about.html), we don't need a uniformization layer. But that's because there's a culture of very careful attention to detail, with significant respect for history and convention. The folks that have weighed in have long lists of serious credentials, and I tend to feel that their input, whether or not I agree on any specific point, should be treated as worth its weight in gold. Frankly, if one of my libraries was up for consideration, I would give their concerns serious weight on their history and contributions alone, even if at first they struck me as written by martians.

So concerns have been raised. We've dallied with them perhaps too long and the process stalled out. But now the committee has stepped in, and in the process we're trying to iron out the consensus process. Maybe we need a point at which people who don't object step in, or some process for "voting" on agreement with objections that the package author is not amenable to. But a serious and arduous review, which has found undeniable problems as well (e.g. corner case problems with large operations) is far from a "trackless mire."

If Bryan doesn't agree with the proposal and wants to keep the Text API fundamentally as is, I vote for inclusion in the platform nonetheless. But, for what it's worth, my (significant) respect for his taste and ability to play well with others will be somewhat diminished.

Cheers,
Sterl.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20101107/acbc37a7/attachment.html