Re: Limits, symbols and bytevectors, ASN.1 branding
Lassi Kortela 27 Sep 2019 18:46 UTC
>> I thought cluser:foobar would cause an error when being read into Scheme
>
> No, colon is a perfectly cromulent symbol character in Scheme with no
> special meaning. When Scheme forked from Maclisp, there were no packages
> yet, so colon wasn't special.
OK, I'm so used to reading CL-style symbols I assumed you meant
"cluser:" as a package name all along. But you meant it as an example of
something that looks like a package name but isn't. Even without the
vertical bars.
> Serializing CL code is what I was saying was too big an effort, and we
> shouldn't go there. It would have to handle conditional exclusions (#+ and
> #-) and comments and all kinds of nasty ugly things.
Ugh. You're right.
> Examples: #ratio(11 10), #date"2019-11-11"
These are very nice IMHO.
ISO 8601 strings are probably the best representation for dates. They
put so much work into that standard that we can hardly do better by
trying to be clever with lists and such. Plus YYYY-MM-DD is a pretty
standard thing to grep for in text files.
> #bits[07-EE80] = CL
> #*111011101, where the 07 means that the last 7 bits of the last byte are
> not part of the bitvector.
Does this notation ever become natural to read; is it used somewhere
already?
> I really don't want #bits#u8"07EE00" just to
> avoid square brackets; it's a human readability fail.
I thought you'd want #bits"07EE00" so "#bits" is the things that does
the magic interpretation of the doubld-quoted string. I guess there can
be examples where this gets unwieldy. Maybe it'll be clumsy to implement
even in the case of #bits. Have to think about this.