Changes between Version 1 and Version 2 of Proposals/split

07/23/12 16:04:50 (5 years ago)
byorgey (IP: 2607:f470:8:1050:7a2b:cbff:fea1:42be)

update split proposal with discussion


  • Proposals/split

    v1 v2  
    5656proper parsing package. 
     58= Discussion = 
     60Initial discussion of the proposal can be [ found here]. 
     62= Resolved issues = 
     64I have made some changes to the package as a result of discussion, 
     65explained below.  The changes can be seen in the 
     66[ darcs repository]; a new 
     67version of the package has not yet been released. 
     69== Use of GADTs/ExistentialQuantification == 
     71Henning Thielemann [ asked] whether the GADTs extension is really necessary.  Twan van Laarhoven [ suggested] a way around it.  I have adopted a variant of Twan's proposal, and the package is now fully Haskell 2010 compliant. 
     73== Synonyms == 
     75[ 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. 
     77Following a [ suggestion from Simon Hengel], I have adopted the solution of 
     79 * marking the synonyms as deprecated; 
     80 * passing the "prune" option to haddock so they are not documented as part of the API. 
     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 [ recommended by the package versioning policy]. 
    5886= Open issues = 
    6290At the request of a user, the 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. 
     92 * Henning Thielemann [ suggested]: 
     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. 
     101I am currently investigating whether this can be made to work (and how 
     102it affects building the test suite). 
    64104== Missing strategies ==