Re: Standards vs specifications
Lassi Kortela 27 Sep 2019 13:47 UTC
>> point I've been trying to make today is that we don't have the political
>> clout to create standards with the kind of force you explain.
>
> And yet, when I file a bug against an R7RS implementation saying it doesn't
> conform to the spec, it's remarkable that it almost always gets fixed. Or
> if not, it's explained to me that it's inherent in the implementation (e.g.
> Chicken doesn't support rename-on-export from R7RS libraries) and can't be
> fixed without great pain. And then I say, "By all means, just note it in
> the docs as a deviation from R7RS." And they do. Obviously there is no
> question of coercion, even economic pressure, here.
That's a situation where the data on disk (your Scheme source files) are
conforming but the interpreter isn't.
Programs are reasonable to fix in many cases but data is more difficult.
The reason HTML was such interoperability disaster was that zillions of
people kept making non-standard files and spreading them around the
world. Then it doesn't help to fix interpreters to conform to the
standard (in many cases that kind of diligence would have made the
things worse).
With a data format you don't get many chances to get it right before it
spreads. The same is true (but to a much lesser degree) of APIs.
> LInux is a product, not a standard, but it does conform to lots of
> standards very thoroughly. I routinely move from Cygwin to Linux to BSD
> without even noticing. Linux distros also conform to higher-level
> standards.
Linux is many things. I don't think "product" characterizes it very
well, and "standard" may actually be more accurate (depending on which
of the many meanings of "Linux" is under discussion). It's a very strong
de facto standard to the point that many programmers would like to
abandon all support for other Unix systems, and are apathetic about
things not working on non-Linux platforms.
Windows also has never been a formal standard, yet is stronger in lots
of ways than many formal ones.
>> But as HTML shows, people who honor unreasonable requests are going
>> to be more popular than people who are strict.
>
> Popular with whom? With the authors of crap HTML editors, and with people
> who want to write HTML by hand without learning.
In other words, basically the entire world. The lesson is not to make
things difficult unless you like obscurity.
This discussion has diverged quite a bit from the technical details of
our encodings. In practice, any binary format we'll come up with from
our current understanding and opinions is going to be reasonable from
the point-of-view of easy implementation and interoperability. We'll
probably make a reasonable text format, too, judging by the way it's
going. But there we have to be careful.