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)

Mechanism vs policy Lassi Kortela 25 Sep 2019 19:58 UTC

> The core S-expression and its corresponding binary format
> are for communication between Lisps, but more importantly between Lisps and
> non-Lisps, and simplicity is everything.  I'm talking here about a JSON
> data model plus integers, symbols, and bytevectdors.

I like that set of data types for the simple version of the format.

I'd just like to avoid arbitrary limits on the range of values within
each data type. Things like numerical limits, or limits on what
characters can appear in symbols. In order for the text format to have a
simple correspondence with its dual binary format, it should do a little
extra work to be able to represent things like symbols with weird chars.

And the reason the text and binary formats should have 100% equal data
models, is simplicity for users - the proper aim of abstraction. Rich
Hickey had a point about Clojure, that it often sits between external
systems, and users should be able to get some data from an external
system, frob only part of it, and pass on the rest to some other system.
Without being concerned about the contents of the data they are not
frobbing. He said that he doesn't like static typing because it's
obsessed with dictating the type of all data, including data that's just
along for the ride and that his code doesn't care about.

I'd like to have 100% text/binary equivalence and a rich set of data
types for the same reason. Just simple (read) and (write) with a choice
of text and binary, no need to be concerned with other options, and
being able to trust that towards end of a long workday, I can just toss
some data to them without keeping in mind idiosyncrasies like what kinds
of symbols can be represented as text and what kind can be represented
as binary, or whether improper lists can be represented or not. The
point of much of Lisp culture is to obviate concerns like that.

So I would like the formats to provide "mechanism, not policy". I don't
care about guiding people to use particular kinds of data by restricting
the format. That can be an important goal, but I don't see a reasonable
way of tackling it. Empirically, when you try to restrict the range of
data types, people do even stupider workarounds, or switch to richer
formats (which often have baroque syntax and other problems).

A simple format in the ballpark of JSON is supremely useful for
implementation reasons: it makes little sense to demand that a Scheme
sitting on a little IoT device relaying sensor readings should support
arbitrary-precision floats or ordered sets or something. But other than
that, I would work a little extra to avoid restrictions and dictating
policy to users. Not because policy sucks an I'm unsympathetic to it,
but because it seems like an intractable problem, and attempted
solutions are likely to be a hassle without fixing things.

> The binary format I'm developing, of which the core binary format is a
> small subset, is for serialization and Lisp-to-Lisp communication (though
> of course other languages can implement it, and a subset of it can be used
> to talk to other ASN.1 implementations).  I'd like to leave full
> S-expressions for communication between identical or similar Lisp
> implementations (R5RS, R6RS, R7RS-small, CL) and not try to standardize
> them at this late date.  The binary format is probably simpler to implement
> anyway.

I like the range of your kithcen-sink binary format.

But why would it be particularly difficult to design an equivalent
S-expression format? I don't think the point is standardizing
S-expressions in general, but specifying _one_ flavor of S-expressions
that can carry everything. Preferably a simple and extensible one, with
most of the dodgy stuff implemented as extensions.

Would it appease you if we include all the dodgy stuff but using
sharpsign syntax so they act like third-party user extensions instead of
bloating up the lexical core of the syntax?

> technology was made for people, not people for technology.

It's not that simple :) But we can strive to act as if it is so.