[Openmcl-devel] slet/rlet with C functions?

[Gary Byers]

On Thu, 17 Aug 2006, Phil wrote:

> And here I was thinking that this mechanism was for Obj-C sends
> only... thanks, that worked and was what I needed to know.
>
> A couple of followup questions (one OpenMCL specific and the other,
> more general Lisp):
>
> 1) Would it be possible/feasible to modify sletify as the last test
> before failure to do a (inverse?) lookup, if it is an external call,
> on the function in question via the interfaces to determine if the
> function returns a structure and if so, what kind of structure?

I don't know (I haven't looked).

SLET basically looks at each initform to determine whether or not
it's a "structure-returning form".  This sort of thing can easily
be fooled - "(PROGN (CCL::MAKE-RECT ...))" might not look as much 
like a structure-returning form as "(CCL::MAKE-RECT ...)" does,
and I assume that that means that only simple cases are recognized
and the type of structure and the primitive that makes it have to
be apparent.

A call like (#_CGRectIntegral r2 r) has already been transformed (no
later than read-time) so that the structure-return syntax has been
replaced with the structure-pointer-as-first-argument and that
argument's been made explicit.  The expansion of the form returned by
the reader macro is:

(EXTERNAL-CALL "_CGRectIntegral" :ADDRESS R2 :<CGR>ECT R :VOID)

and there isn't much information there that SLET could use to determine
that the :ADDRESS R2 was introduced to to hide the structure return.
If the introduction of that first argument was more explicit - maybe
something like

(EXTERNAL-CALL "_CGRectIntegral" (:ADDRESS-FOR-STRUCTURE-RETURN :<CGR>ECT) R2 :<CGR>ECT R :VOID)

it'd be easier for SLET to see that a structure-return was involved.  (The 
(:ADDRESS-FOR-STRUCTURE-RETURN :<CGR>ect) would presumably get macroexpanded
down to something simpler if this wasn't inside an SLET.)

Unless that sort of annotation happened, I'm not sure that SLET could
reasonably recognize/provide sugar for structure-returning ff-calls.



>
> 2) I tried to track down the answer the first question myself but
> didn't get very far as I lacked the knowledge to effectively get to
> find the appropriate entry points in the source code.  I'm familiar
> with static analysis tools like XREF and am looking for pointer on
> good tools or techniques to perform dynamic analysis of code?  For
> example,  given an arbitrary lisp expression, is it possible to see
> step-by-step how the expression is being processed by the reader from
> a reader macro and/or macroexpansion standpoint?  I know I can pass
> it through macroexpand or macroexpand-1 for full or single-step
> macroexpansion, respectively.  But that doesn't help with reader
> macros and seems rather tedious when dealing with an expression which
> has many levels of macroexpansion (i.e. it seems most important to
> see the progression of ns-make-rect...->:<NSR>ect...->%stack-block...
> rather than the minutia in the end result)  Maybe the way I'm going
> about things is wrong... if so please let me know as I'm looking for
> pointers on the most effective way to get to the bottom of questions
> like this when one doesn't have detailed knowledge of the code behind
> an expression.

I don't know of a good way to trace the expansion of reader-macros,
but you're supposed to be able to build macro-tracing facilities via
the use of *MACROEXPAND-HOOK*.  I don't think that I've ever done
anything useful with it, but I'm almost sure that people have done
so; Paul Graham's book or other tutorials might contain interesting
examples of its use.

You can see the first-level result of a reader-macro just by quoting
it:

? '(#_CGRectIntegral r2 r)
(DARWIN32::|CGRectIntegral| R2 R)

but that doesn't tell you too much about what the reader-macro did to
produce that.  (In this case, it interned a symbol in the target OS
package; it also gave that symbol a macro definition ...)