Haskell Platform call for consensus: add 'text' package - Libraries - Haskell.org

newer
Haskell Platform Proposal: add the...

Haskell Platform call for consensus: add 'text' package

older
Re: Haskell Platform decision:...

Don Stewart

6 Nov 2010 6 Nov '10

12:28 p.m.

Hello! This is a call for consensus for the following proposal: http://trac.haskell.org/haskell-platform/wiki/Proposals/text Are there any unresolved concerns? Deadline: 2 weeks (Nov 21) -- Don P.S. the steps in the process for adding a package are: * described here: http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus * timetable for 'text' here: http://trac.haskell.org/haskell-platform/ticket/145 P.P.S.: work is happening at BelHac to fix the status of the trac wiki on the community server, which is rather flakey.

Reply

Sign in to reply online Use email software

Show replies by date

Ian Lynagh

6 Nov 6 Nov

3:43 p.m.

On Sat, Nov 06, 2010 at 05:28:28AM -0700, Donald Bruce Stewart wrote:

This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/text

Are there any unresolved concerns?

I still think the API should be consistent with base and bytestring. Thanks Ian

Reply

Sign in to reply online Use email software

Don Stewart

3:51 p.m.

igloo:

On Sat, Nov 06, 2010 at 05:28:28AM -0700, Donald Bruce Stewart wrote:

...
This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/text

Are there any unresolved concerns?

I still think the API should be consistent with base and bytestring.

Malcolm's proposal, which Bryan reviewed, seems to be the proposed function to smooth out the APIs somewhat. The unresolved issue is what Bryan would like to do with that proposal, and, if it is accepted, does anyone then wish to object to any remaining inconsistencies. Malcolm's proposal: http://www.haskell.org/pipermail/libraries/2010-October/014659.html Bryan's response: http://www.haskell.org/pipermail/libraries/2010-October/014674.html -- Don Also, as I hope we all can see, there are significant community benefits to having 'text' in the platform. This benefit should, at some point, outweigh any final wibbles we may have with a handful of function types or names. Perfection is not the primary goal of the platform -- Haskell being useful, however, is.

Reply

Sign in to reply online Use email software

Ian Lynagh

4:03 p.m.

On Sat, Nov 06, 2010 at 08:51:46AM -0700, Donald Bruce Stewart wrote:

Malcolm's proposal, which Bryan reviewed, seems to be the proposed function to smooth out the APIs somewhat.

FWIW, I don't think that goes far enough. For example, we have BS: count :: Char -> ByteString -> Int Text: count :: Text -> Text -> Int but I think we should have Text: count :: Char -> Text -> Int while Malcolm says Proposal: these are equivalent, no action. More generally, I don't think that treating Text effectively as the element type is really any more correct in general. It does mean that you can act on graphemes composed of multiple codepoints, but doesn't help you act on graphemes that may be followed by more combining characters. Furthermore, acting on general sequences can be useful with any of lists, bytestrings and text. Thanks Ian

Reply

Sign in to reply online Use email software

Ross Paterson

4:37 p.m.

On Sat, Nov 06, 2010 at 05:28:28AM -0700, Don Stewart wrote:

This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/text

Are there any unresolved concerns?

Deadline: 2 weeks (Nov 21)

I share the concern that an API that closely mirrors Data.List, but with a handful of exceptions where the names are changed, is less easy to use than it could be.

Reply

Sign in to reply online Use email software

Don Stewart

4:41 p.m.

ross:

On Sat, Nov 06, 2010 at 05:28:28AM -0700, Don Stewart wrote:

...
This is a call for consensus for the following proposal:

http://trac.haskell.org/haskell-platform/wiki/Proposals/text

Are there any unresolved concerns?

Deadline: 2 weeks (Nov 21)

I share the concern that an API that closely mirrors Data.List, but with a handful of exceptions where the names are changed, is less easy to use than it could be.

The next step here then will be for the author to address the naming concern with a proposed change. We can then repeat the check. Bryan? What would you like to do? -- Don

Reply

Sign in to reply online Use email software

Bryan O'Sullivan

7 Nov 7 Nov

3:55 a.m.

On Sat, Nov 6, 2010 at 9:41 AM, Don Stewart wrote:

The next step here then will be for the author to address the naming concern with a proposed change. We can then repeat the check.

I've actually lost track of the various different proposals, because that threads sprawled so much. I'm still leaning towards not changing any names, but I might go back and look. At this point, HP inclusion isn't looking worth the trouble.

Reply

Sign in to reply online Use email software

Don Stewart

9:13 a.m.

bos:

On Sat, Nov 6, 2010 at 9:41 AM, Don Stewart wrote:

...
The next step here then will be for the author to address the naming concern with a proposed change. We can then repeat the check.

I've actually lost track of the various different proposals, because that threads sprawled so much. I'm still leaning towards not changing any names, but I might go back and look. At this point, HP inclusion isn't looking worth the trouble.

Chin up! I read the entire thread yesterday, and there's lots of sensible discussion. Authors simply do not have to respond to every concern, especially when the concerns themselves are in flux. What I would ask everyone to keep in mind is that *we are not aiming for perfection*. The goal is to have a useful library set, that improves on the current situation. Discussion should be framed with this in mind. -- Don

Reply

Sign in to reply online Use email software

Don Stewart

11:25 a.m.

bos:

On Sat, Nov 6, 2010 at 9:41 AM, Don Stewart wrote:

...
The next step here then will be for the author to address the naming concern with a proposed change. We can then repeat the check.

I've actually lost track of the various different proposals, because that threads sprawled so much. I'm still leaning towards not changing any names, but I might go back and look. At this point, HP inclusion isn't looking worth the trouble.

I had a crisis meeting at BelHac. The active members of steering committee (Ian, Duncan, Thomas, Johan) are going to step in (as they should have earlier) to clarify the state of the concerns about naming, and identify what, if anything, is being proposed. Lack of consensus about naming issues for a handful of functions will just be noted, and set aside, and will not prevent 'text' being added. I've asked for a far more active steering committee involvement in the future, as well, to gate the authors and proposers from the flood of libraries@. -- Don

Reply

Sign in to reply online Use email software

Ian Lynagh

2:49 p.m.

On Sun, Nov 07, 2010 at 03:25:47AM -0800, Donald Bruce Stewart wrote:

The active members of steering committee (Ian,

I'm not even an inactive member! Thanks Ian

Reply

Sign in to reply online Use email software

5356

Age (days ago)

5357

Last active (days ago)

Download

9 comments

4 participants

tags

participants (4)

Bryan O'Sullivan
Don Stewart
Ian Lynagh
Ross Paterson