using describe on a macro function results in nothing being returned

[Russell Sim]

Fix macro description when called like this:

(describe (macro-function 'cffi:with-foreign-pointer-as-string))

Within SLIME, the apropos mode can't currently handle macros because there is no way to show only the details of the macro's function. SBCL seems to have 2 function associated with a symbol (i don't really understand the complete details, but.. ) the symbol-function is a closure that has a different call signature to the actual macro-function.

The attached patch add's the ability for form returned from %fun-name to be correctly handled by the documentation function to make describe work correctly for macros.

Macro-functions are already handled by describe-function and describe-object, but the documentation string was never being passed back for the macro-function type.

What i currently see is this

CL-USER> (describe (macro-function 'with-locked-hash-table))
#<FUNCTION (MACRO-FUNCTION WITH-LOCKED-HASH-TABLE) {52FBEA0B}>
  [compiled function]

Lambda-list: ((HASH-TABLE) &BODY BODY)
Derived type: (FUNCTION (T T) (VALUES CONS &OPTIONAL))
Documentation:
  T
Source file: SYS:SRC;CODE;TARGET-EXTENSIONS.LISP
; No value

This patch results in this

CL-USER> (describe (macro-function 'with-locked-hash-table))
#<FUNCTION (MACRO-FUNCTION WITH-LOCKED-HASH-TABLE) {52FBEA0B}>
  [compiled function]

Lambda-list: ((HASH-TABLE) &BODY BODY)
Derived type: (FUNCTION (T T) (VALUES CONS &OPTIONAL))
Documentation:
  Limits concurrent accesses to HASH-TABLE for the duration of BODY.
  If HASH-TABLE is synchronized, BODY will execute with exclusive
  ownership of the table. If HASH-TABLE is not synchronized, BODY will
  execute with other WITH-LOCKED-HASH-TABLE bodies excluded -- exclusion
  of hash-table accesses not surrounded by WITH-LOCKED-HASH-TABLE is
  unspecified.
Source file: SYS:SRC;CODE;TARGET-EXTENSIONS.LISP
; No value

[Russell Sim (russell-sim)]

To be clear the following does work, but for consistency in the apropos mode in SLIME it would be best if we could target the macro-function directly. This is the corresponding fix for slime https://github.com/russell/slime/commit/1590cd6cba8a0871364f212eb29c50b73f67d7ba

CL-USER> (describe 'with-locked-hash-table)
SB-EXT:WITH-LOCKED-HASH-TABLE
  [symbol]

WITH-LOCKED-HASH-TABLE names a macro:
  Lambda-list: ((HASH-TABLE) &BODY BODY)
  Documentation:
    Limits concurrent accesses to HASH-TABLE for the duration of BODY.
    If HASH-TABLE is synchronized, BODY will execute with exclusive
    ownership of the table. If HASH-TABLE is not synchronized, BODY will
    execute with other WITH-LOCKED-HASH-TABLE bodies excluded -- exclusion
    of hash-table accesses not surrounded by WITH-LOCKED-HASH-TABLE is
    unspecified.
  Source file: SYS:SRC;CODE;TARGET-EXTENSIONS.LISP
; No value

[Christophe Rhodes (csr21-cantab)]

Something seems wrong to me about your diagnosis. The patch attached doesn't reflect the test cases: it modifies the (LIST (EQL 'FUNCTION)) method of DOCUMENTATION, but the test cases call DOCUMENTATION with a function object (the return value of a call to MACRO-FUNCTION, not a list whose car is MACRO-FUNCTION). At least, as I read it?

[Russell Sim (russell-sim)]

Yes, indeed you are correct, the test is bogus. though it does cover a case that is missing, it seems that feature already existed.

The problem that I'm trying to address, revolves around how the result form %FUN-NAME should be handled by public functions like DOCUMENTATION.

The result from %FUN-NAME is passed to DOCUMENTATION from DESCRIBE. Which is the other place this bug could be addressed. Sorry to confuse, it was late when I authored the patch.

I'll make a new patch for DESCRIBE, I'm pretty new to this, and in retrospect handling internal representations in a public interface is weird way to fix this problem

[Russell Sim (russell-sim)]

OK, I have a patch for the DESCRIBE-FUNCTION function, while authoring it I tried to detect similar bugs with other types, and I found that compiler macros were also effected, so this patch now covers fixing them too.

I think I now know where I got confused with the last patch, it never occurred to me that functions could have lists as names, so I thought that the special case were these %FUN-NAME names, not things like setf. Thanks for taking the time to review