Changes between Version 1 and Version 2 of Proposals/split

Show
Ignore:
Timestamp:
07/23/12 16:04:50 (21 months ago)
Author:
byorgey (IP: 2607:f470:8:1050:7a2b:cbff:fea1:42be)
Comment:

update split proposal with discussion

Legend:

Unmodified
Added
Removed
Modified
  • Proposals/split

    v1 v2  
    5656proper parsing package. 
    5757 
     58= Discussion = 
     59 
     60Initial discussion of the proposal can be [http://thread.gmane.org/gmane.comp.lang.haskell.libraries/17649/ found here]. 
     61 
     62= Resolved issues = 
     63 
     64I have made some changes to the package as a result of discussion, 
     65explained below.  The changes can be seen in the 
     66[http://code.haskell.org/~byorgey/code/split darcs repository]; a new 
     67version of the package has not yet been released. 
     68 
     69== Use of GADTs/ExistentialQuantification == 
     70 
     71Henning Thielemann [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17650 asked] whether the GADTs extension is really necessary.  Twan van Laarhoven [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17659 suggested] a way around it.  I have adopted a variant of Twan's proposal, and the package is now fully Haskell 2010 compliant. 
     72 
     73== Synonyms == 
     74 
     75[http://article.gmane.org/gmane.comp.lang.haskell.libraries/17653 Roman Cheplyaka] and others expressed distaste at the presence of synonyms for several functions in the library, arguing that it unnecessarily complicates the API and makes it harder to read others' code. 
     76 
     77Following a [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17669 suggestion from Simon Hengel], I have adopted the solution of 
     78 
     79 * marking the synonyms as deprecated; 
     80 * passing the "prune" option to haddock so they are not documented as part of the API. 
     81 
     82This effectively does away with any confusion the synonyms may cause, 
     83WITHOUT breaking any existing code, since the synonyms are still 
     84exported.  Note, however, that I do plan to bump the major version number, as [http://www.haskell.org/haskellwiki/Package_versioning_policy#Deprecation recommended by the package versioning policy]. 
     85 
    5886= Open issues = 
    5987 
     
    6189 
    6290At 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. 
     91 
     92 * Henning Thielemann [http://article.gmane.org/gmane.comp.lang.haskell.libraries/17650 suggested]: 
     93 
     94  You could provide two private modules with the same name in 
     95  different directories, one that re-exports 'build' from GHC.Exts and 
     96  one with a custom definition of 'build' for non-GHC compilers. Then 
     97  set 'Hs-Source-Dirs' in Cabal according to the impl(ghc). No CPP 
     98  needed, only Cabal. One could even think of a separate package for 
     99  this purpose. 
     100 
     101I am currently investigating whether this can be made to work (and how 
     102it affects building the test suite). 
    63103 
    64104== Missing strategies ==