Summary and call for discussion on text proposal

[Ian Lynagh]

On Sun, Nov 07, 2010 at 06:54:38PM +0100, Gregory Collins wrote:
> 
> of libraries and to head off serious problems before too much time is
> wasted on discussion, NOT to devolve into extended megathreads over

I think "extended megathreads" is something of an overexaggeration, but
I have had to repeat myself (or at least reconfirm my opinion) a couple
of times.

First in response to "I believe that #3 is actually resolved, but I
haven't deleted it pending confirmation from Ian or others.".

Then, in the call for consensus, "Say nothing" means "you're prepared to
accept the current proposal" so I needed to "Raise objection. Objections
need accompanying reasoning".

There were also a few messages from other people which made similar
arguments, but I don't see how we can establish what the consensus is
without several people giving their opinion.

> My understanding
> was that the HP process was intended to help with the overall design
[not]
> which colour to paint the bike shed.

I (perhaps not surprisingly) disagree with your characterisation of the
naming discussion.

We are not talking about whether a function should be named breakString,
breakSubstring, breakStr, breakList, ...

Rather, we are discussing a fundamental design decision for the
platform: whether it is more important to have global consistency of HP
packages, or to have each package have a locally optimal API. In this
case, whether 2 functions in different packages should have the same
name or not.

(and also some side discussion about whether glocal consistency aplies
in this case, and why the current API is locally optimal).

> Another point I would like to make is that unless I'm mistaken, even
> if text is accepted into the platform, that doesn't mean that
> maintainership of the library is assigned to libraries at haskell.org: it

That is true, but I would hope that a change in a package's philosophy
would be raised for discussion on the list by the maintainer or by the
person bumping HP library versions before it is encorporated into the
platform.

> a quality basis compared to some of the libraries we grandfathered in,

I think that is an argument for improving the other libraries, not for
opening the platform floodgates.


Thanks
Ian