Here is a concern:
At present, a final \n in lines' input is optional, because a line is
ended by either a \n or the end of the string. Consequently lines "a"
and lines "a\n" have the same value ( ["a"] ). This seems a desirable
feature that is worth preserving.
Consider the composition lines.unlines, and what happens when the last
line is empty. unlines ["a", ""] is "a\n\n", and lines correctly
reconstructs the two lines from this.
With this suggestion, unlines ["a", ""] becomes "a\n", which, unless you
change its behaviour, lines interprets as representing a single line
["a"], and lines.unlines is no longer the identity function.
--brian
Sigbjorn Finne wrote:
>
> Here's a Prelude inconsistency that's been irking me once
> in a while for a loong time - today it came up again, so here goes:
>
> unlines ["a","b"] ==> "a\nb\n"
> unwords ["a","b"] ==> "a b"
>
> I like that
>
> unwords (ls1 ++ [unwords ls2]) == unwords (ls1 ++ ls2)
>
> but not that 'unlines' doesnt' obey the same rule, i.e.,
>
> unlines [line1, unlines [line2,line3]] /= unlines [line1,line2,line3]
>
> Is this by design? I notice that 'unlines' mirrors Miranda's 'lay', but
> I'd find it a little more useful without the trailing \n (esp. considering
> now that putStrLn is std.)
>
> The current defn of 'unlines' doesn't keep me up at night, but still.
>
> --sigbjorn
