I’ve written a few posts about features of the Lisp language that a newcomer arriving from C++ might not have encountered. I’m going through them alphabetically, so here is a summary page of the functions beginning with the letters T, U, V, and W:
update-instance-for-different-class
update-instance-for-redefined-class
I’ve written a few posts about features of the Lisp language that a newcomer arriving from C++ might not have encountered. I’m going through them alphabetically, so here is a summary page of the functions beginning with the letter S:
The next feature we’ll discuss is the with-standard-io-syntax macro. This is probably underused in many contexts, and its absence can lead to some mysterious behaviour in certain circumstances.
You’ll recall that there are dynamic variables that modify the behaviour of the Lisp writer, as we discussed in several articles related to printing. We also saw variables that modify the behaviour of the Lisp reader, the most obvious of which is the *read-table* dynamic variable.
When writing a function that writes and/or reads, if that function might be called from an unknown context it is strongly recommended that with-standard-io-syntax is used to wrap those input/output operations. This macro sets the control variables to a set of well-defined defaults. The programmer can always embed further let forms to tweak these as necessary, but it’s important to start in a known state.
One can imagine the potential for weirdness if a library that manipulates data files with write were called with the *print-base* variable set to, say, 8.
We recently covered the with-accessors macro. That allowed the programmer to create a lexical environment in which a symbol substituted for a call to an accessor in a particular instance. The with-slots macro is essentially the same, but rather than using one of the class’ accessors, it expands into a slot-value call. We’ve discussed when slot-value is recommended, those considerations also apply, naturally, to with-slots.
The with-package-iterator macro gives access to the symbols in one or more packages, optionally filtering by whether the symbols are external, internal, or inherited. The macro allows the programmer to retrieve essentially the same information available with do-symbols, but with a different API.
Frankly, the presence of this macro is a bit surprising to me. I don’t see how it adds any behaviour that can’t be easily reproduced with a simple application of do-symbols, and the Lisp standard does demonstrate fairly good orthogonality, so I don’t really understand what with-package-iterator is doing as part of the standard. If anybody can enlighten me in the comments, that would be nice.