s-expressionists / wscl

Sources of the "Well Specified Common Lisp" specification which is based on the final draft of the Common Lisp standard but is not a new Common Lisp standard.
https://s-expressionists.github.io/wscl/
Other
38 stars 4 forks source link

A specific wording in `INLINE`. #54

Open jcguu95 opened 6 months ago

jcguu95 commented 6 months ago

CLHS: Declaration INLINE, NOTINLINE says

inline specifies that it is desirable for the compiler to produce inline calls to the functions named by function-names [..]

This is a good enough description, but some reader may wonder whether this has effect too on the function object obtained at read time. It would be more accurate to say

inline specifies that it is desirable for the compiler to produce inline calls to the functions named by function-names at the call sites where the function-name is explicitly used [..]

Bike commented 6 months ago

I think that is too restrictive. It would for example be okay for a compiler to inline foo in (funcall 'foo ...), or even in (mapcar 'foo ...). Implementations actually do both of those already, even though there is not a call to foo in the code in a direct sense.

jcguu95 commented 6 months ago

I may be confused with what call sites mean. I thought (funcall 'foo ...) could also be considered a call site of foo. I do intend to include funcall, mapcar, and their friends. Is there a more accurate term for this?

Bike commented 6 months ago

Not sure. "call site" is not a glossary term.

What exactly is it that is not affected by inline in this proposal? The actual semantic effect of inlining is very broad (3.2.2.3):

[The file compiler may assume that a] call within a file to a named function that is defined in the same file refers to that function, unless that function has been declared notinline. The consequences are unspecified if functions are redefined individually at run time or multiply defined in the same file.

The second sentence, in particular, gives the compiler very broad discretion since it doesn't have to worry about redefinition in any context, including use of #'/function.

Is the idea of this proposal to clarify that, for example in

(declaim (inline foo))
(defun foo ...)

(defun bar ... (eq #'foo (fdefinition 'foo)))

the comparison has to be true?

jcguu95 commented 6 months ago

What worries me about the current description is illustrated in the following example.

(declaim (inline foo))
(defun foo () 0)
(defvar bar #'foo)
(defun baz () (funcall #.bar))

Should (funcall #.bar) be inlined? At read-time, it provides the same function object as that pointed by the name FOO. Should (declaim (inline foo)) causes an inlining of that part because it resolves to the same function object, or should it not causes an inlining of that part because that function object at that "code site" isn't obtained from the name foo?

Bike commented 6 months ago

This code seems... unlikely. And even if it did show up somewhere, it's invalid. Without some eval-when, foo is not available at compile time (assuming this is all in one compilation unit). Even with eval-when, it would probably be invalid because the function object referenced by baz is not serializable. And outside of a compilation unit, what does it matter? It's unlikely that a literal function object will ever be inlined, but even if it was, this would be impossible to determine by a user within the standard.