Shubhamkar Ayare

Is this any preferable than `define-compiler-macro`? (Couldn't locate deftransform for funcall; but reading and learning about deftransform and related. Had taken a break from lisp.)

A brief testing suggests that `define-compiler-macro` is good for portable code, but one'd need to take care of cases individually, while `deftransform` handles the cases. `deftransform` seems convenient but comes...

Also, this is not always possible with `apply` due to the last argument being a list, is it?

I see. I see. I see. Checked the discussion. So, we either need a full-type inferencing system, or users need to explicitly declare types using `the`? Yeah, I wanted compiler-macros...

For SBCL itself, I think I'll stick to `sb-c:deftransform` - found a really neat introduction at https://stackoverflow.com/questions/44342104/using-deftransform-defknown-in-sbcl-internals-to-get-the-compiler-to-transform-u

Yeah, that way; added last night; pushed. Perhaps, something similar can be done for other implementations; but I'll stick with this and SBCL for the time being. PS; Perhaps rest...

With SBCL, compiling the following produces the note `lexical environment too hairy, can't inline DEFUN FOO` ```lisp (let ((a 5)) (declare (inline foo)) (defun foo () a)) ``` I wanted...

Ah, so, I want to check if a function is a closure, so I could avoid inlining/optimizing it; and inline only if it is not a closure.

😅 The full story: I'm trying to make [typed-dispatch](https://github.com/digikar99/typed-dispatch) that intends to provide a syntax like ```lisp (define-typed-function my= (a b)) (defun-typed my= ((a string) (b string)) (string= a b))...

Hmm, as of SBCL commit 501633af38d (post SBCL 2.0.8), `(sb-kernel:closurep (let ((a 4)) (lambda () a)))` does return T; although in a recent discussion, stassats did mention that that lambda...