APPLY* vs SPREADAPPLY* vs CL:FUNCALL

[rmkaplan]

What's the difference between these functions?

CL:FUNCALL and SPREADAPPLY* seem to (byte)-compile in the same way: Just the APPLYFN opcode

APPLY* compiles as the sequence CHECKAPPLY* APPLYFN. What does the CHECKAPPLY* do? Is it important?

Of more significance, SPREADAPPLY* does not actually have a function definition, only compiler optimizations. So you can't debug any interpreted code that has a call to SPREADAPPLY* (and FDEVOP and other dispatch macros go to SPREADAPPLY*).

So: Should there be a MOVD somewhere of CL:FUNCALL TO SPREADAPPLY*? Or should SPREADAPPLY* be systematically replaced by CL:FUNCALL everywhere?

[nbriggs]

I can’t speak to CL:FUNCALL vs SPREADAPPLY* differences. The CHECKAPPLY* opcode does: #define OPCHECKAPPLY \ do { \ register DefCell *defcell; \ defcell = (DefCell *)GetDEFCELL68k(TOPOFSTACK & POINTERMASK); \ if (!(defcell->ccodep && \ (((TOPOFSTACK & SEGMASK) == 0) || (GetTypeNumber(TOPOFSTACK) == TYPE_NEWATOM)) && \ ((defcell->argtype == 0) || (defcell->argtype == 2)))) \ goto op_ufn; \ } while (0)

…

On Jun 30, 2022, at 7:35 PM, rmkaplan ***@***.***> wrote: What's the difference between these functions? CL:FUNCALL and SPREADAPPLY* seem to (byte)-compile in the same way: Just the APPLYFN opcode APPLY* compiles as the sequence CHECKAPPLY* APPLYFN. What does the CHECKAPPLY* do? Is it important? Of more significance, SPREADAPPLY* does not actually have a function definition, only compiler optimizations. So you can't debug any interpreted code that has a call to SPREADAPPLY* (and FDEVOP and other dispatch macros go to SPREADAPPLY*). So: Should there be a MOVD somewhere of CL:FUNCALL TO SPREADAPPLY*? Or should SPREADAPPLY* be systematically replaced by CL:FUNCALL everywhere? — Reply to this email directly, view it on GitHub <#809>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6DAWOCNUUPCMRZMIQCE5DVRXLFZANCNFSM52KD5NCQ>. You are receiving this because you are subscribed to this thread.

[masinter]

The differences seem to be in the handling of Interlisp NLAMBDA spread (NLAMBDA (A B C) ...) and nospread (NLAMBDA U ...) functions. The bytecompiler and relative optimizations around this predate the implementation of common lisp. CL:FUNCALL's definition comes late in the loadup.

I'm not sure how to tell what the UFN is for the CHECKAPPLY* opcode.

It would seem safe to MOVD?(CL:FUNCALL CHECKAPPLY*) when debugging.
If the point is to allow interpreted calls to FDEV functions, it's safe to assume that no FDEV operation will be a NLAMBDA Interlisp function so you could change them to call APPLY* (which is defined early in the loadup (but the "fetch" calls require DWIM expressions).

Systematically changing ALL calls to CHECKAPPLY* to CL:FUNCALL might make it more difficult to debug MAKEINIT problems.

[rmkaplan]

With respect to debugging, I think just putting a (MOVD? ‘APPLY* ’SPREADAPPLY*) in LLINTERP is good enough. If you think it is a bad idea to have that floating around in the released system, it could be in a (DONTCOPY (EXPORTS …)) so it only ends up in EXPORTS.ALL.

…

On Jul 2, 2022, at 11:29 AM, Larry Masinter ***@***.***> wrote: The differences seem to be in the handling of Interlisp NLAMBDA spread (NLAMBDA (A B C) ...) and nospread (NLAMBDA U ...) functions. The bytecompiler and relative optimizations around this predate the implementation of common lisp. CL:FUNCALL's definition comes late in the loadup. I'm not sure how to tell what the UFN is for the CHECKAPPLY* opcode. It would seem safe to MOVD?(CL:FUNCALL CHECKAPPLY*) when debugging. If the point is to allow interpreted calls to FDEV functions, it's safe to assume that no FDEV operation will be a NLAMBDA Interlisp function so you could change them to call APPLY* (which is defined early in the loadup (but the "fetch" calls require DWIM expressions). Systematically changing ALL calls to CHECKAPPLY* to CL:FUNCALL might make it more difficult to debug MAKEINIT problems. — Reply to this email directly, view it on GitHub <#809 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJLLDI5BBMSIWRY6OTTVSCC7NANCNFSM52KD5NCQ>. You are receiving this because you authored the thread.

[nbriggs]

There should be a big warning and explanation about why that would be there and under what circumstances it's OK to do that. It doesn't make me feel comfortable.

[rmkaplan]

I’m not sure what the issue is. It’s a function-name that is called only from system code, and it isn’t clear to me why APPLY* or CL:FUNCALL wouldn’t have worked just as well in those internally-defined situations. I am using CL:FUNCALL in the external format interface, should I have been using SPREADAPPLY* ? But the nuisance problem is that that SPREADAPPLY doesn’t actually have a definition, only a compiler optimizer, and so you can’t debug interpreted code without knowing that you have to define it. Does it matter whether it shares a definition with either APPLY* or CL:FUNCALL, for debugging? It would still compile as it does now?

…

On Jul 2, 2022, at 12:23 PM, Nick Briggs ***@***.***> wrote: There should be a big warning and explanation about why that would be there and under what circumstances it's OK to do that. It doesn't make me feel comfortable. — Reply to this email directly, view it on GitHub <#809 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKDBOO6STXJ6CTXXWDVSCJLRANCNFSM52KD5NCQ>. You are receiving this because you authored the thread.

[johnwcowan]

cl:funcall's signature is (cl:funcall function-expression arg ...)

cl:apply's signature is (cl:apply function-expression arg ... list-of-args)

[masinter]

we need a Medley Common Lisp Implementation guide

[masinter]

in (1988) medley/internal/ABC there's a (P (MOVD? 'APPLY* 'SPREADAPPLY*))

I've been using SYSEDIT and not updating ABC.
I'd suggest adding the MOVD? to SYSEDIT and obsoleting ABC

[nbriggs]

There are a few differences in the variables set up in ABC and SYSEDIT -- we should review them to see exactly what is different and whether we have any understanding of why and which things ought to be set going forward...