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)
|
Re: Exporting the canonical null value for pack/unpack Amirouche Boubekki 20 Nov 2020 16:20 UTC
Le ven. 20 nov. 2020 à 12:56, Vasilij Schneidermann <xxxxxx@vasilij.de> a écrit : > > 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 I think when an immutable object is exported from a library, it must be done as a procedure like eof-object. So in this case, the procedure `engine-null` seems to do the job? -- Amirouche ~ https://hyper.dev