> 5) Since there is no limit on the length of lines (and modern *ix tools
> impose none), you might as well remove support for multi-line
> S-expressions.  This will encourage people to use the "Hacks for lists"
> style, which should be called "Simplifying complex lists".

Indeed, parsers work fine with long lines.

There are two mechanisms here:

1) One S-expression that spans more than one line:

(foo alpha bravo
      charlie delta)

2) Many S-expressions merged into one:
(foo alpha bravo)
(foo charlie delta)
becomes the alist ((foo alpha bravo charlie delta))

Option 1 is easy to read from Scheme since the Scheme reader doesn't
distinguish newlines from other whitespace. So you can do (read-all) and
then (assoc 'foo) to get the properties. If there are duplicates of 'foo
then it misses them.

Option 2 is easy for Unix tools to read. By default, they grab duplicate
values of "foo". Something like `grep '^(foo .*)$'` always gets all
"foo" lines, and it's actually harder to block some of them out than to
include them. E.g. what is the complete value of "foo" in this case:

(foo will the real value)
(foo please stand up)

A naive Scheme implementation would say it's (will the real value).

A naive Unix grep|sed or awk implementation would say it's (will the
real value please stand up).

Since it's generally easier to do extra work in Scheme than in Unix, I
added the auto-merging of the properties. Scheme reads the info once and
then does any number of `assoc` calls on it so it's a one-time cost to
get Scheme behavior that matches the default shell script behavior.

By contrast, every time a shell script wants to get another property it
has to do a separate grep|sed run on the output. All of those would have
to have `| head -n 1` added. I don't even know how to do it in awk; use
a counter variable or call exit()? Are those portable?

Since the merging doesn't depend on any particular S-expression being
multi-line, we could remove the multi-line support. But that would
complicate things for Scheme, where `read` happily reads multi-line
sexprs by default and you have to work harder to block those.

I guess the Scheme-side reader could replace plain `read` with
`(call-with-port (get-input-string (read-line)) read)`. But I'm not sure
whether that would stop people from writing multi-line S-expressions by
accident or purpose. In general, line-oriented formats are dodgy because
newlines are just whitespace so it's easy for things to seem like you
can break lines. Unix tools can't parse multi-line S-exprs but they'll
just miss those properties then.

I don't know what to do about this; I think the current solution of
allowing multi-line sexprs, but discouraging them, is decent. I'm not
sure it's the best solution. Ideally people wouldn't write those things
in the first place, but there may be some scenario where it's the lesser
evil.