Changes between Version 4 and Version 5 of Proposals/split

Show
Ignore:
Timestamp:
09/24/12 17:44:19 (2 years ago)
Author:
byorgey (IP: 2607:f470:8:1050:d5aa:9d01:9566:5db5)
Comment:

update split proposal with discussion and information about new 0.2.1.0 release

Legend:

Unmodified
Added
Removed
Modified
  • Proposals/split

    v4 v5  
    2323Development repo: 
    2424 
    25   darcs get http://code.haskell.org/~byorgey/code/split 
     25  darcs get http://hub.darcs.net/byorgey/split 
    2626 
    2727= Rationale = 
     
    8888Bryan O'Sullivan [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17675 pointed out] that the text package has an existing function, essentially identical in functionality to splitEvery, called chunksOf.  In the interest of consistency with an existing HP package, I have renamed splitEvery to chunksOf (and deprecated and pruned splitEvery, just like the other synonyms as explained above). 
    8989 
    90 = Open issues = 
    91  
    9290== Use of GHC.Exts == 
    9391 
    94 At the request of a user, the 0.1.4.3 release switched from defining its own version of the standard 'build' function, to importing it from GHC.Exts.  This allows GHC to do more optimization, resulting in reported speedups to uses of splitEvery, splitPlaces, and splitPlacesBlanks.  However, this makes the library GHC-specific.  If any reviewers think this is an issue I would be willing to go back to defining build by hand, or use CPP macros to select between build implementations based on the compiler. 
    95  
    96  * Henning Thielemann [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17650 suggested]: 
     92At the request of a user, the 0.1.4.3 release switched from defining its own version of the standard 'build' function, to importing it from GHC.Exts.  This allows GHC to do more optimization, resulting in reported speedups to uses of splitEvery, splitPlaces, and splitPlacesBlanks.  However, this makes the library GHC-specific.  I outlined the options [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17759 in a message to the libraries mailing list].  Several suggestions were made, including this [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17650 suggestion by Henning Thielemann]: 
    9793 
    9894  You could provide two private modules with the same name in 
     
    10399  this purpose. 
    104100 
    105 I have a patch which implements this proposal, which can be seen in the [http://code.haskell.org/~byorgey/code/split-build split-build] repo.  I am not sure whether the benefit outweighs the extra complication. Opinions welcome. 
     101This looks like it could work, but it adds a lot of complication for not much benefit. 
     102 
     103In the end, in the interest of simplicity and full Haskell2010 compliance, I simply went back to defining build manually. [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17760 Henning also suggested] that there ought to be a package providing 'build' in a generic way, so that you get the right version depending which compiler you are using.  If this ever happens I would be happy to depend on that package. 
     104 
     105= Open issues = 
    106106 
    107107== Missing strategies ==