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.
 
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.
 
1. In an editor that lets you navigate subexpressions in a smart way,
like emacs+paredit; it would benefit from knowing that #SYMBOL{EXPR...}
is a subexpression without needing to special-case certain values of
SYMBOL. Sure, it might well special-case some things that it has special
behaviour for, but it can ignore any unknown type tags and fall back on
a more simple "I can just find the delimiters" mode.

Sure.  That wasn't what I had in mind, though.
 

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.
 
This is a human, not technological, problem :-)

(a) the Curse of Lisp, (b) technology was made for people, not people for technology.



John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
He made the Legislature meet at one-horse tank-towns out in the alfalfa
belt, so that hardly nobody could get there and most of the leaders
would stay home and let him go to work and do things as he pleased.
    --H.L. Mencken's translation of the Declaration of Independence