> On the whole I think you should omit all talk of merging and just say that
> it's legitimate for multiple entries in the result to have the same key.
> That means you can't use assq to search for such keys, but again I don't
> think it makes much difference, and it simplifies life in C.

You raise a good point about C. It's not much fun to iterate over
duplicate keys there.

>> By contrast, every time a shell script wants to get another property it
>> has to do a separate grep|sed run on the output.
>
> Hardly.  Bash has had arrays since forever, and hash tables since 2009.
> It's true that not everyone's sh is bash, but that doesn't mean they don't
> *have* bash, unless we are in a busybox environment or something.

Wow, I had no idea bash has hash-tables now!

Anyway, bash is only taken for granted on Linux (and even there, not on
Debian or Alpine). There are still many interesting environments where
bash is not installed by default. Since we're designing a portable SRFI
to make life easy for everyone, those more conservative environments
should be taken into account.

>> 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?
>
> Yes, quite standard.

Thanks. That is good to know.

>> 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.
>
> You don't have to block them in the reader, just say that it's not
> supported to write them.  Scheme won't introduce newlines by default unless
> you actually call a prettyprinter, which makes no sense here.

That may be the right call. It'll be significantly easier to parse
things from C if you only have to check one line and don't need to look
for duplicate keys on other lines. I'm almost sold on that approach. The
only things that worry me are grep, sed and ark which incorporate
duplicate keys by default. If you only test with those, you don't notice
that Scheme and C implementations drop all but the first key.

> BTW, you might need to allow \n in strings, though perhaps semantically
> it's not useful.

True - it should be allowed on Zawinski's Law grounds.