Email list hosting service & mailing list manager

Core lexical syntax Lassi Kortela (25 Sep 2019 10:15 UTC)
Re: Core lexical syntax John Cowan (25 Sep 2019 14:09 UTC)
Machines vs humans Lassi Kortela (25 Sep 2019 14:25 UTC)
Re: Core lexical syntax Alaric Snell-Pym (25 Sep 2019 15:44 UTC)
Re: Core lexical syntax John Cowan (25 Sep 2019 14:13 UTC)
Re: Core lexical syntax John Cowan (25 Sep 2019 19:18 UTC)
Mechanism vs policy Lassi Kortela (25 Sep 2019 19:58 UTC)
Re: Mechanism vs policy Arthur A. Gleckler (25 Sep 2019 21:17 UTC)
Re: Mechanism vs policy Lassi Kortela (26 Sep 2019 07:40 UTC)
Re: Mechanism vs policy John Cowan (25 Sep 2019 22:25 UTC)
Re: Mechanism vs policy Arthur A. Gleckler (26 Sep 2019 01:34 UTC)
Limits, symbols and bytevectors, ASN.1 branding Lassi Kortela (26 Sep 2019 08:23 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding Alaric Snell-Pym (26 Sep 2019 08:56 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding John Cowan (27 Sep 2019 02:38 UTC)
ASN.1 branding Lassi Kortela (27 Sep 2019 14:56 UTC)
Re: ASN.1 branding Alaric Snell-Pym (27 Sep 2019 15:24 UTC)
Re: ASN.1 branding Lassi Kortela (27 Sep 2019 18:54 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding John Cowan (27 Sep 2019 01:57 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding Lassi Kortela (27 Sep 2019 16:24 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding John Cowan (27 Sep 2019 17:37 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding Lassi Kortela (27 Sep 2019 18:28 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding John Cowan (27 Sep 2019 18:39 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding Lassi Kortela (27 Sep 2019 18:46 UTC)
Re: Limits, symbols and bytevectors, ASN.1 branding John Cowan (27 Sep 2019 21:19 UTC)
Re: Mechanism vs policy Alaric Snell-Pym (26 Sep 2019 08:45 UTC)
Implementation limits Lassi Kortela (26 Sep 2019 08:57 UTC)
Re: Implementation limits Alaric Snell-Pym (26 Sep 2019 09:09 UTC)
Re: Implementation limits Lassi Kortela (26 Sep 2019 09:51 UTC)
Meaning of the word "format" Lassi Kortela (26 Sep 2019 10:31 UTC)
Stacking it all up Lassi Kortela (26 Sep 2019 11:05 UTC)
Brief spec-writing exercise Lassi Kortela (26 Sep 2019 11:46 UTC)
Re: Brief spec-writing exercise John Cowan (26 Sep 2019 15:45 UTC)
Standards vs specifications Lassi Kortela (26 Sep 2019 21:24 UTC)
Re: Standards vs specifications John Cowan (27 Sep 2019 04:29 UTC)
Re: Standards vs specifications Lassi Kortela (27 Sep 2019 13:47 UTC)
Re: Standards vs specifications John Cowan (27 Sep 2019 14:53 UTC)
Re: Meaning of the word "format" John Cowan (26 Sep 2019 20:59 UTC)
Re: Meaning of the word "format" Lassi Kortela (26 Sep 2019 21:09 UTC)
Re: Meaning of the word "format" John Cowan (27 Sep 2019 02:44 UTC)
Length bytes and lookahead in ASN.1 Lassi Kortela (27 Sep 2019 13:58 UTC)
Re: Length bytes and lookahead in ASN.1 John Cowan (27 Sep 2019 14:22 UTC)
Re: Length bytes and lookahead in ASN.1 Alaric Snell-Pym (27 Sep 2019 15:02 UTC)
Re: Length bytes and lookahead in ASN.1 hga@xxxxxx (27 Sep 2019 15:26 UTC)
(missing)
Fwd: Length bytes and lookahead in ASN.1 John Cowan (27 Sep 2019 16:40 UTC)
Re: Fwd: Length bytes and lookahead in ASN.1 Alaric Snell-Pym (27 Sep 2019 16:51 UTC)
Re: Fwd: Length bytes and lookahead in ASN.1 John Cowan (27 Sep 2019 17:18 UTC)
Length bytes and lookahead in ASN.1 hga@xxxxxx (27 Sep 2019 16:58 UTC)
Re: Length bytes and lookahead in ASN.1 John Cowan (27 Sep 2019 17:21 UTC)
Re: Mechanism vs policy John Cowan (27 Sep 2019 03:52 UTC)
Re: Core lexical syntax Alaric Snell-Pym (26 Sep 2019 08:36 UTC)

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.