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/