This isn’t clear from the docs, and you might try to do this and wonder at the output you got:

*Main> groupBy (< =) [3,4,5,3,2,1,4,4,1,1,2,3,4,5,4,5,6,7]
[[3,4,5,3],[2],[1,4,4,1,1,2,3,4,5,4,5,6,7]]

We can redefine groupBy as follows, so that the supplied predicate function compares adjacent elements one-by-one and returns True if they should be grouped together:

> groupBy' :: (a -> a -> Bool) -> [a] -> [[a]]
> groupBy' c []     = []
> groupBy' c (a:as) = (a:ys) : groupBy' c zs
>     where (ys,zs) = spanC a as
>           spanC _  []    = ([], [])
>           spanC a' (x:xs)
>             | a' `c` x   = let (ps,qs) = spanC x xs 
>                            in (x:ps,qs)
>             | otherwise = ([], x:xs)

Now we can use the groupBy function to return a list of ascending lists, like we (probably) wanted:

*Main> groupBy' (< =) [3,4,5,3,2,1,4,4,1,1,2,3,4,5,4,5,6,7]
[[3,4,5],[3],[2],[1,4,4],[1,1,2,3,4,5],[4,5,6,7]]

The functionality is of course the same for groupBy (==).

A function like group is in this category. It’s conceptually very simple, but defining it actually requires a bit of indirection. Here I’ve translated the definition from Data.List to use explicit recursion:

66 > group :: (Eq a) => [a] -> [[a]]
67 > group []     = []
68 > group (a:as) = (a:ys) : group zs
69 >     where (ys,zs) = spanEq as
70 >           spanEq []     = ([], [])
71 >           spanEq (x:xs)
72 >             | a == x    = let (ps,qs) = spanEq xs 
73 >                            in (x:ps,qs)
74 >             | otherwise = ([], x:xs)
75

I think if I were asked to define this having never seen it, the first thing I would think of would be something using foldl1, which wouldn’t work.

EDIT: see also an alternative definition for Data.List.groupBy

First, a little boilerplate…

NEW IMPLEMENTATION:

———————————————————————-

In the previous implementation, to check if the word formed
by adding a one has been seen, we had to iterate through each
of the previous bits in the array, checking words.

For example for words of length 3, finding the 7th bit (?)
by checking if 111 has already been seen:

        /-----\  ==>  111
0 0 0 1 1 1 (1)...
\----/         000 == 111  No
  \----/       001 == 111  No
    \----/     011 == 111  No
      \----/   111 == 111  Yes, so this bit must be (0)

This is extremely inefficient. What we want is to be able to
store all the previous words that we’ve encountered in an easily-
searchable data structure.

In the example above, we would like the three words that we’ve
seen to be stored in what might be called a Trie, so that our
search instead looks like the following:

       /\
      0  1         1 - in tree, go right
     / \  \
    0   1  1       1 - in tree, go right
   / \   \  \
  0   1   1  1     1 - in tree, we've already seen 111,
                       so the last bit must be 0

Our new data structure will look like this:

We’ll need to build a new tree from a list of bits, appending
a final bit (1, except for the initial tree):

Finally, here is our new algorithm. The tree is passed in the
State monad, through the use of mapM. The state monad is a little
tricky sometimes:

With the following function, after we apply it to the word we’re searching
for, it becomes a function :: state -> (val,state), suitable for the
State monad:

Takes a list of the last n-1 Bits (Bools) and traverses a Tree which we’ve
been using to keep track of the words we’ve already seen. We fold the Bit
list into the tree. When we get to the endo of the list, we look for a One.
We return the new bit as well as the new Tree:

We’re at a Zero bit,

…a One bit,

…or else propose a One for the last bit:

TEST FUNCTIONS:

———————————————————————-

This code is copied from the previous post:

We use Bool for bits, where False ==> 0, True ==> 1:

Our garage-door lock model for testing the function:

True means access granted:

Test out our function:

Stay tuned for one more post on these algorithms.

The function listArray is similar except that it assumes that the list is already ordered by index so there is no need to provide tuples of (index, value). Becase listArray actually uses zip internally to produce the tupled list, so the programmer can pass a list to listArray which exceeds the declared bounds of the array and the function will quietly drop the extra list tail:

Prelude Data.Array> listArray (1,3) ['a','b','c',undefined]
array (1,3) [(1,'a'),(2,'b'),(3,'c')]

But when a list that exceeds the specified bound is passed to array, it dies a horrible death:

Prelude Data.Array> array (1,3) [(1,'a'),(2,'b'),(3,'c'),(4,'d')]
array *** Exception: Error in array index

I think the array function should be modified by adding a simple take to automatically drop any excess list elements:

array (l,u) ies
    = let n = safeRangeSize (l,u)
      in unsafeArray (l,u)
                     [(safeIndex (l,u) n i, e) | (i, e) <- take n ies]

This change would bring the function into better alignment with other prelude functions which expect infinite lists and drop tails as needed. It can be argued that the programmer might want to know that he is passing too long a list to his function, in which case I think the safeRangeSize function, etc. should be eliminated.

IMPLEMENTATION:

EXAMPLES AND CONCLUSION: