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 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)
Re: Core lexical syntax John Cowan (25 Sep 2019 14:13 UTC)

Re: Limits, symbols and bytevectors, ASN.1 branding Lassi Kortela 27 Sep 2019 18:28 UTC

> we need an API standard as well as a format standard

Good idea.

> Which is why it's a restartable exception in CL.

I never thought of that. Restartable exceptions could be used for our CL
reader too.

>> I would read |cluser:foobar| as a symbol named "cluser:foobar" in the
>> default package (i.e. the symbol has no package prefix).
>
> The trouble now is that ||s are now semantic instead of just syntactic.
> cluser:foobar and |cluser:foobar| are the same on all systems except CL,
> but different on CL.

I thought cluser:foobar would cause an error when being read into Scheme
(unless the user gives a reader option for what to do about symbols with
packages).

> Maybe we do need a separate type for
> package-qualified symbols, but I'm not personally interested in spending
> time on it, as they mostly appear just in code, never in general data.

Yes, only in code. It's fine by me to have "symbol" and "fancy-symbol"
types. fancy-symbol would grok things like keywords, packages and
uninterned symbols.

>> Again, I'll argue that Lisp can simply give you uninterned symbol
>
> Can you give examples of data that contain them

Just code. CL has read syntax for them.
<http://www.lispworks.com/documentation/HyperSpec/Body/02_dh.htm> lists
"uninterned symbol" and:

[1]> '#:foo
#:FOO
[2]> (symbol-name '#:foo)
"FOO"
[3]> (symbol-package '#:foo)
NIL
[4]> (equal '#:foo '#:foo)
NIL

> I was thinking of UUIDs, but I don't care that much.  Overall I think
> hyphens are more human-readable.

OK, no strong opinion on this one. Let's wait and see.

>> Well, I hate to admit this but base64 is still convenient.
>
> Again because URIs were ASCII-only until fairly recently and are still not
> 8-bit clean.

These "one last holdout of ASCII-dom" instances keep popping up year
after year :)

>> Ah, ok. I'll wait for your #name syntax before evaluating the #u8"".
>
> I talked about this above and you LGTMed it.  The format is # followed by
> name or hexcode, followed by list, string, or bytevector.

I missed that, unless you somehow mean the bytevector syntax.

> Actually there is no loss.  Scheme guarantees that when you read and write
> binary floats as text you don't lose precision, much less get incorrect
> results.  Many libraries now guarantee the same properties (I believe glibc
> does).  There is no exact representation of 1.1 in binary32 floats, but
> there is a particular float that is closer to mathematical 1.1 than any
> other float is, and it may be safely printed as "1.1"

Cool, I didn't know that.

>> The big concern is representing exact quantities of money. Databases
>> have had to deal with this problem for ages; what do they do?
>
> They use integers with decimal scaling factors.  We can do that by
> representing 1.1 as 11/10.  It gets lengthy if the scaling factor is big,
> but not that lengthy.

Ah yes, ratios. I've always just dealt with money as integer cents, but
it's not all that convenient.