Exporting the canonical null value for pack/unpack Vasilij Schneidermann (20 Nov 2020 11:56 UTC)
|
Re: Exporting the canonical null value for pack/unpack
Amirouche Boubekki
(20 Nov 2020 16:20 UTC)
|
Re: Exporting the canonical null value for pack/unpack
John Cowan
(20 Nov 2020 16:22 UTC)
|
Re: Exporting the canonical null value for pack/unpack
Vasilij Schneidermann
(20 Nov 2020 16:33 UTC)
|
Re: Exporting the canonical null value for pack/unpack
Vasilij Schneidermann
(30 Nov 2020 11:29 UTC)
|
Re: Exporting the canonical null value for pack/unpack
Amirouche Boubekki
(30 Nov 2020 12:11 UTC)
|
Re: Exporting the canonical null value for pack/unpack
John Cowan
(30 Nov 2020 16:17 UTC)
|
Re: Exporting the canonical null value for pack/unpack
Amirouche Boubekki
(30 Nov 2020 16:19 UTC)
|
Exporting the canonical null value for pack/unpack Vasilij Schneidermann 20 Nov 2020 11:56 UTC
Hello everyone, I've experimented with the sample pack/unpack implementation and found that it does define *null* which happens to be a unique cons (created using '(null)). One cannot just use '(null) from their own code using the pack/unpack functionality as that's a different cons, so to make use of it, it needs to be exported and documented as such. I don't think it's a good idea to make the specifics implementation-dependent, so I'm looking for feedback how good of an idea it is to add *null* to the list of exported identifiers for the (srfi 167 engine) library (as (srfi 167 pack) isn't a thing). Bikeshedding for a different library (like (srfi 167 memory) representing the backend) or name (*null* is an unprefixed one, so that could be icky) is welcome. Vasilij