Philip K.F. Hölzenspies schrieb:
Dear Christian, et al.
Thanks for the summary, Christian. I've given some detailed comments below, but I'll give the gist here.
The ticket has indeed moved on quite a bit. Some more expressive functions were proposed that weren't part of the ticket, but that maybe should have been. Some of the originally proposed functions can be expressed easily in these more expressive ones and, therefore, may not be wanted inclusions any more.
I suggest we get everyone to +1 or -1 on the following list of possible new inclusions (where the slash-separated list of names all represent the same function - for +1s also indicate name preference):
- takeRec / splitAts / groupsOf / segmentsOf :: Int -> [a] -> [[a]] +1
in http://hackage.haskell.org/package/split such a function is called "chunk" and "splitEvery". My preference would be "chunks", but "splitAts", "splits", or "segmentsOf" is fine, too.
- genericTakeRec / genericSplitAts / genericGroupsOf / genericSegmentsOf :: Integral i => i -> [a] -> [[a]] +1
How should the above functions behave for the corner case of the number being less than 1? I see several options: 1. abort (my preference) 2. return the empty list 3. return the singleton list of the input (non-intuitive) 4. return the infinite list of empty lists
- spanRec / spans :: (a -> Bool) -> [a] -> [[a]] - breakRec / breaks :: (a -> Bool) -> [a] -> [[a]] +1
in http://hackage.haskell.org/package/split there is a function called splitWhen. The main point to clarify is how delimiters (determined by the input predicate for breaks) influence the output list. 1. Should delimiters be part of the output? 2. Should consecutive delimiters produce separate sublists 3. Should empty lists be elements of the result list 4. If yes, should leading or trailing delimiters produce leading or trailing empty list elements.
- runs :: (a -> a -> Bool) -> [a] -> [[a]] +1
maybe under a different name: "runBy"
- run :: (a -> a -> Bool) -> [a] -> ([a],[a]) -1
"runs" is similar to "groupBy", therefore I proposed "runBy" for "runs". For groupBy we have no function that's splits off the first group only, therefore (I think) we don't need one for the first run, too. Furthermore, the relation between "runBy" und "run" would be different from the one between "groupBy" and "group". An alternative would be to use "firstRunBy" for "run" and also add a function "firstGroupBy".
- replace :: Eq a => [a] -> [a] -> [a] -> [a] +1
Here also the corner case needs to be clarified, what should happen, if the empty list should be replaced.
- replaceBy :: ([a] -> (b, [a])) -> [a] -> [b] -1
As a recursion scheme that is comparable to iterate or replicate the name is too special. I also just notice that a more general recursion scheme would be: recurse :: (a -> (b, Maybe a)) -> a -> [b] or the given unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr could be used directly in a similar way than my replaceBy. In fact: replaceBy splt = unfoldr (\ l -> if null l then Nothing else Just (splt l)) So replaceBy is not really needed!
The implementations of the chosen functions should, in my mind, be based on profiling results.
Yes.
As an open procedural question: can a proposal track ticket be obsolidated by a new ticket? What is the common procedure for revising a proposal?
I actually don't know. But I would recommend to close this ticket and open a new one (or several new ones) if some agreement is achieved (or none without agreement). Cheers Christian