RE: unlines: the mystery of the trailing \n

[Sigbjorn Finne]

Mark P Jones <[EMAIL PROTECTED]> writes:
> 
> | 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"
> |
> | [... unwords adds space between items, not at the beginning or end;
> | unlines puts a newline after each item, including at the end ...]
> 
> I quite like the fact that the definition for unlines gives us laws
> like:
> 
>   unlines (xs ++ ys) = unlines xs ++ unlines ys
>   unlines . concat   = concat . map unlines
> 
> Of course, the fact that unwords doesn't add a terminating space
> means that we don't get quite such nice laws for unwords ...
> 

Hi Mark,

yes, those laws would be nice to have too. I guess this shows that
treating text as just a list, doesn't give you all the laws you
would like. In my case, prepending some lines to a paragraph should
ideally have resulted in a bigger paragraph (with no trailing newlines.)

Anyway, Pretty gives me the laws I need & is more suitable for
the job. No reason to tweak the defn of unlines.

--sigbjorn

Re: unlines: the mystery of the trailing \n

[Marcin 'Qrczak' Kowalczyk]

Mon, 7 Aug 2000 17:58:40 -0700, Sigbjorn Finne <[EMAIL PROTECTED]> pisze:

> 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"

IMHO it should be that way. Because text files generally do have
the final '\n', but lines don't have a final space. Spaces are word
separators, '\n' are line terminators.

When I map each line of the file, I don't expect dealing with a final
empty line.

unlines a ++ unlines b = unlines (a++b)

> I'd find it a little more useful without the trailing \n
> (esp. considering now that putStrLn is std.)

writeFile "foo" (unlines listOfLines)
Using putStrLn here would be less convenient.

-- 
 __("<  Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
 \__/
  ^^  SYGNATURA ZASTĘPCZA
QRCZAK

RE: unlines: the mystery of the trailing \n

[Mark P Jones]

Hi Sigbjorn,

| 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"
|
| [... unwords adds space between items, not at the beginning or end;
| unlines puts a newline after each item, including at the end ...]

I quite like the fact that the definition for unlines gives us laws
like:

  unlines (xs ++ ys) = unlines xs ++ unlines ys
  unlines . concat   = concat . map unlines

Of course, the fact that unwords doesn't add a terminating space
means that we don't get quite such nice laws for unwords ...

All the best,
Mark

Re: unlines: the mystery of the trailing \n

[Brian Boutel]

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