Re: [Gnu-arch-users] Feature suggestion: "tla inventory -0"

[Tom Lord]

    > From: Andrew Suffield <address@hidden>

    > Careful. s-exps may make more sense than tagged strings, but they're
    > still a solution in search of a problem. Do you *really* need your
    > inter-tool data format to be directly human readable? Doing that
    > imposes a hefty performance hit, even if it doesn't matter in trivial
    > scenarios.

    > A good IPC protocol is easy to parse in raw C (*no* libraries) and
    > requires minimal verification - it is frequently easy to create a
    > domain-specific protocol that is simply unable to express invalid
    > data.

    > I'm not convinced it's worthwhile though. There isn't a need for
    > arbitrary unrelated tools to exchange data.


I think most of the issues you raise go under the same tent, really.

Yes, you really do need human readable formats.  For one example, a
handy way to problem-solve is to build up and debug pipelines in
increments.   For another example, sometimes you want to write them by
hand or edit them.   For another example, sometimes you want to read
output without having to through (much) of a report generator.  Not
only do we want s-exps for those reasons -- we want pretty printers.

But yes, you also want fast-loading, fast-writing formats.

These aren't incompatible.  You can have both.

And yes, I agree, simply consing up a domain-specific protocol is at
least _often_ easier to do than solving the larger problem (for any
single budget, not summed over them).  Generators for such protocols
are typically rather anemic in terms of the kinds of data structures
they can handle (compared to s-exps) -- but then so are C run-time
systems.  Yes, I think that working on the IPC problem also implies
working on the C run-time system problem.

As for "arbitrary unrelated tools [exchanging] data" -- well, that's a
debate that's about 30 years old.   I doubt we'll resolve it here but
I can't help but notice what operating system _you're_ running.

-t