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