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)
|
> 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.