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)
|
On 25/09/2019 20:18, John Cowan wrote: > On Wed, Sep 25, 2019 at 11:44 AM Alaric Snell-Pym <xxxxxx@snell-pym.org.uk> > wrote: > > \When will symbols be used as identifiers in other programming languages? >> Lisp happens to use s-expressions to represent source code so symbols >> are used to represent Lisp identifiers, but that relationship doesn't >> hold for other languages! >> > > No, but in C, for example, it's common to have constants mapping well-known > names into numbers for internal use; these names should have the shape of > identifiers. > Ok, but even if C stub code to interchange between s-expressions and C structs is auto-generated by some schema-aware tool that generates C variable names and #defines and so on, it's not unfair to expect that tool to handle clashes caused by its name-mangling algorithm; it is the nature of name-mangling algorithms to either cause clashes or to have unpleasant-looking output names with some kind of escaping mechanism :-) Now, don't get me wrong, it would be weird to have a format defined on top of core sexprs that defined both "favourite_cheese" and "favourite-cheese" as able to crop up in the same context and having different meaning. And so it might be perfectly valid for a tool that generates C type definitions and parse/unparse code from some kind of "sexpr schema" for such a format to reject schemas that rely on distinguishing _ from - in their symbols. But I don't think that means we should therefore say that the underlying data format should not be able to reliable encode the difference. Flipping it around, if a suite of static analysis tools for various languages used core sexprs for internal communications, would they need to store all the programming language symbols in strings to ensure that they can differentiate between "favourite_cheese" and "favourite-cheese" in the source programs? >> Meta Question: Are we defining a serialisation format for Scheme values >> (modulo some impractical things, like closures and ports) - in which >> case we want to be able to cleanly round-trip as much as possible, in >> general - or a new data format/model that just happens to have a >> correspondence to a subset of Scheme? >> > > Both, I think. 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. > > 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. That sounds like a vote for the latter: not trying to round-trip as much of the Scheme value space as possible... >> 2. In some application that's processing this data with some kind of >> higher-level semantic knowledge. In this case, when it encounters an >> unknown object, it needs to decide whether to skip [...] >> > > That' s what I had in mind. > I guessed, but I wanted to make sure everyone was clear what everyone thought! -- Alaric Snell-Pym (M7KIT) http://www.snell-pym.org.uk/alaric/