I noticed a problem using ECL and custom SETF expanders which does not
occur when using SBCL.
When compiling a file which uses a custom SETF expander, invoking the
SETF function inside functions compiled at the same time work fine.
However, at the REPL, or in interpreted code, an error occurs that the
SETF function doesn't exist.
I here attach:
- The test case (setf-test-1.lisp)
- (setf-test-1.txt) ECL test compiling the file, loading it, testing
that TEST works and then erroring at REPL SETF
- (setf-test-2.txt) ECL test loading the file without compilation,
showing that TEST fails as well as REPL SETF test
- (setf-test-3.txt) SBCL test compiling the file, loading it, testing
that TEST works as well as REPL SETF, where both do
- (setf-test-4.txt) SBCL test loading uncompiled file, testing that
TEST works as well as REPL SETF (where both also work).
- (setf-test-5.txt) ECL and SBCL comparision if inverting the order of
DEFUN and DEFINE-SETF-EXPANDER (in which case SBCL behaves the same
and ECL SETF function finally works, but it doesn't seem to be using
the custom macro anymore).
Another interesting difference is that if I define the SETF expander
before the get/set accessor DEFUNs, in SBCL the same behaviour is
observed, where GET-SETF-EXPANSION shows the unexpanded macros. With
ECL, the code works if I do this inversion, but the GET-SETF-EXPANSION
then seems to show the standard expander without using the custom macro.
A reason wich made me try this is that it should be possible by being
careful to define global macros used by a SETF expansion such that it
also be possible to define lexically scoped custom SETF expansions by
overriding the global macros used in the expansion by MACROLET. This
for instance could be used in performance-critical code to have a
WITH-INLINE-ACCESSORS type macro such that SETF expansion in a block of
code produces inline C access, etc.
Of course an alternative yet less general approach could be using
inline accessor functions, but it appears that despite using DECLAIM
INLINE directives explicit function calls are always occuring. In any
case, it can be a nice feature to allow dynamically scoped custom SETF
expansions, especially with the power this provides using custom macros.