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