Email list hosting service & mailing list manager

Request for review of my binary encoding proposal John Cowan (17 Sep 2019 22:39 UTC)
Re: Request for review of my binary encoding proposal Lassi Kortela (18 Sep 2019 00:35 UTC)
Re: Request for review of my binary encoding proposal Alaric Snell-Pym (18 Sep 2019 10:09 UTC)
Re: Request for review of my binary encoding proposal John Cowan (18 Sep 2019 23:48 UTC)
Re: Request for review of my binary encoding proposal Arthur A. Gleckler (18 Sep 2019 23:51 UTC)
Data type registry Lassi Kortela (19 Sep 2019 16:47 UTC)
Re: Data type registry John Cowan (19 Sep 2019 20:21 UTC)
Re: Data type registry Arthur A. Gleckler (19 Sep 2019 21:37 UTC)
Symbol registry Lassi Kortela (19 Sep 2019 21:46 UTC)
Re: Symbol registry Arthur A. Gleckler (19 Sep 2019 21:48 UTC)
Why ASN.1 is not, like, actually evil John Cowan (18 Sep 2019 12:24 UTC)
Re: Why ASN.1 is not, like, actually evil hga@xxxxxx (18 Sep 2019 13:43 UTC)
Re: Why ASN.1 is not, like, actually evil John Cowan (18 Sep 2019 21:13 UTC)
Re: Why ASN.1 is not, like, actually evil Lassi Kortela (19 Sep 2019 17:01 UTC)
Re: Why ASN.1 is not, like, actually evil John Cowan (19 Sep 2019 18:27 UTC)
Re: Why ASN.1 is not, like, actually evil Lassi Kortela (19 Sep 2019 21:53 UTC)
Re: Request for review of my binary encoding proposal John Cowan (18 Sep 2019 23:29 UTC)
Re: Request for review of my binary encoding proposal Lassi Kortela (19 Sep 2019 16:08 UTC)

Data type registry Lassi Kortela 19 Sep 2019 16:47 UTC

>> (Arthur, would you in fact be amenable to maintaining my spreadsheet
>> permanently if and when the time comes?  It would just mean adding rows
>> when new SRFIs specified that they should be serializable to a binary
>> format.)
>
> Certainly.  It doesn't sound like a lot of work, and if Scheme
> implementers decide to support your design, having a registry will be
> helpful.

This is a good idea.

In a similar spirit, I suggested that symbols registry a while back but
it didn't receive a warm welcome :) Perhaps because new symbols can be
added to the enumerations used by existing SRFIs, where as new data
types are not added after the fact.

As usual, I'd be in favor of cross-Lisp-dialect cooperation here. We
could do a review of all data types in all current Lisp dialects. I'd
guess not many are missing from John's spreadsheet.