[Openmcl-devel] slet/rlet with C functions?
gb at clozure.com
Fri Aug 18 05:15:07 UTC 2006
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
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
(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
? '(#_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 ...)
More information about the Openmcl-devel