I notice this commit to CFFI:
* commit 743a90251e5a4407147a20bd8354df03a87ca46d
Author: stacksmith <stacksmith(a)users.noreply.github.com>
AuthorDate: Thu Aug 19 06:34:28 2021 -0700
Commit: GitHub <noreply(a)github.com>
CommitDate: Thu Aug 19 14:34:28 2021 +0100
Allow local names in WITH-FOREIGN-SLOTS
It remains compatible with existing code, but accepts additional formats for bindings:
1) (name slot-name) - just like WITH-SLOTS;
2) (name :pointer slot-name) - a pointer version.
On Thu, 16 Apr 2020 15:24:52 +0530 I had propsed a similar patch to Luis
With a slightly different signature.
| https://github.com/enometh/cffi/commit/023676a25128786174bbaa8a5df7fdc1d27c…
| It seems a natural extension to me, though I was not able to
| document it to my satisfaction and I don't know if it would be too
| confusing to others. WDYT - (could clean it up and push it on a
| separate branch if you had comments.)
The doctring from that patch is reproduced here:
--
(with-foreign-slots (bindings ptr type) body) - Now each binding can
be one of these forms:
SLOT-NAME -- binds SLOT-NAME to (FOREIGN-SLOT-VALUE SLOT-NAME)
(:POINTER SLOT-NAME) -- binds SLOT-NAME to (FOREIGN-SLOT-POINTER
SLOT-NAME)
(VAR-NAME SLOT-NAME) -- binds VAR-NAME to (FOREIGN-SLOT-VALUE
SLOT-NAME)
(:POINTER (VAR-NAME SLOT-NAME)) -- binds VAR-NAME
to (FOREIGN-SLOT-POINTER SLOT-NAME)
(VAR-NAME (:POINTER SLOT-NAME)) -- binds VAR-NAME to
(FOREIGN-SLOT-POINTER SLOT-NAME)
---
This proposed syntax is different from what has been implemented by
stacksmith: The last two forms above correspond to the form
(name :pointer slot-name)
Common Lisp bindings follow a standard syntax LHS RHS
and should always be destructurable to a LHS RHS
I believe introducing a nonstandard binding form with 3 elements is
not in the spirit of common lisp syntax and it will only necessitate
unnecessary special-casing for further macrology
I would encourage stacksmith to consider this point and try to adopt
the syntax I proposed for extending with-foreign-slots
Or would it be possible to support both these forms in addition to the
new 3 element binding form
It is still early and perhaps that the syntax can be fixed before it
is cast in stone - I'm hoping Luis can cooperate