<p dir="ltr">Hi,</p>
<p dir="ltr">Did you look at define-compiler-macro as a possible hook mechanism?</p>
<p dir="ltr">Regards,</p>
<p dir="ltr">Erik</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Oct 27, 2016 09:28, "Mark Evenson" <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 2016/10/27 05:18, Alan Ruttenberg wrote:<br>
> I got curious about how I might generate better code for JSS.<br>
><br>
[…]<br>
> The question is: Is there a more elegant way to do this, or a hook already<br>
> built that I could use instead of redefining precompile-function-call<br>
><br>
> If not, would it be reasonable to add a hook in the ABCL source so I don't<br>
> need to patch it to do the optimization.<br>
<br>
A quick grep of the source does not seem to indicate any hooks into the<br>
controlling the behavior/implementation<br>
PRECOMPILER::PRECOMPILE-<wbr>FUNCTION-CALL, supporting your finding of no<br>
currently reasonable mechanism for a user to manipulate.<br>
<br>
Therefore, I agree that creating a hook mechanism would be the<br>
reasonable way forward.<br>
<br>
I worry a little about compiler speed decrease if we do a naive hook<br>
implementation (i.e. something that MAPs APPLY).  Would it be more<br>
reasonable to memoize possible values of PRECOMPILE-FUNCTION-CALL,<br>
providing an API to switch at runtime?<br>
<br>
Since PRECOMPILER isn't a documented ABCL package, it would be best to<br>
define the API in PRECOMPILER, but have hooks that inserts the public<br>
API in the SYSTEM package via the appropriate import and export of the<br>
symbols.<br>
<br>
Cool work!  What sort of efficiency gains do you expect for JSS here?<br>
<br>
--<br>
"A screaming comes across the sky.  It has happened before, but there<br>
is nothing to compare to it now."<br>
<br>
</blockquote></div></div>