[Openmcl-devel] should ccl allow ffi callbacks to be defined within closures

[Madhu]

*  Tim McNerney <DF8BD7EE-0DC8-49A2-8EF3-6EC1EE998253 at media.mit.edu>
Wrote on Wed, 22 May 2024 08:59:09 -0400
> If I may pose a rhetorical question: what is your operational goal
> for defining a FFI callback that closes over its lexical
> environment? Is there perhaps a way you can rewrite your code to
> avoid the need for a closure?

I came across this use in the wild, when I was trying to run a package
I found on Github (euclidea) with ccl (that code has other
idiosyncracies and needed much patching, but the defcallback, which
actually uses another 3rd party abstraction --
glfw:def-window-size-callback seemed legit enough to support)

> Speaking for myself, in general, I am okay with expecting top-level
> defining forms to only be allowed at top-level and not inside
> arbitrary Lisp expressions. For example, in my professional Lisp
> work, I have never once needed (defun foo (x) (defun bar (y) (+ x
> y))) to work.  And I it wouldn’t occur to me to write expressions
> like (let ((mumble (defvar *quux* 42))) (zerop mumble))
>
> It is valuable to Lisp implementers that these sorts of top-level expressions rules and conventions go unchallenged by users (programmers) so the implementers can write stable and efficient binary loaders and dumpers (the “fasloader” inside load and the “fasdumper” inside compile-file) and, in this case, CCL‘s already powerful FFI.
>

I am entirely in your camp, and sigh when I come across gratuitous use
of obfuscated opaque closures where inspectable named functions are
straightforward

> One way to think about the legality of this example is to ask
> yourself: what type of value does ccl:defcallback return?
>
> The fasdumper can only write certain types of constants to a binary
> file. This might explain the error message you received.

I thought this might be the case (based on the comment in the source)
but as RG clarified, I don't think this is a problem here.

> I apologize if this message seems adversarial or too much like a
> lecture. I am only trying to offer insights into how a Lisp
> programmer such as myself navigates through the language’s
> restrictions by “thinking inside the box.” Yes, sometimes the “box”
> is not the easiest to “wrap one’s head around.” Initially, it took
> me years to absorb the conventions and unwritten rules.

Not at all.  I violently agree with what you everything you said :)

> The good news is that Lisp offers tremendous opportunity to think
> outside the “boxes” imposed by other programming languages. It makes
> me smile every day.