[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)
- To: email@example.com
- Subject: Issue: DEFSTRUCT-ACCESS-FUNCTIONS-INLINE (Version 2)
- From: masinter.pa@Xerox.COM
- Date: 7 Jan 89 00:02 PST
- Reply-to: firstname.lastname@example.org
I couldn't resist changing the name of the issue lest we have another
future issue also dealing with DEFSTRUCT-ACCESS-FUNCTIONS.
References: DEFSTRUCT (p. 308)
Edit history: 5-Oct-88, Version 1 by Chapman
6-Jan-89, Version 2 by Masinter
It is left up to the implementation whether or not the DEFSTRUCT access
function is declared inline. Thus, some programmers write:
(PROCLAIM '(INLINE FOO-A FOO-B FOO-C))
(DEFSTRUCT FOO A B C)
in portable code in case the code is run in an implementation where
the INLINE proclaimation is meaningful but not the default for
Make it mandatory that implementations declare access functions inline.
Of course the declaration may or may not mean anything within the
This requirement resolves user ambiguity.
We've not surveyed many implementations, but apparently they
differ as to whether INLINE for defstruct accessors is the default.
Cost to implementors:
Cost to users:
This clarification will give users insurance that the inline declaration
has been made for the access function.
Specified is simpler than not-specified.
Small. Some programs might have different size/space characteristics.
We know of no implementation where such automatic inlining would
be inappropriate, even in cases where INLINE is recognized. Certainly
implementations are free to ignore INLINE proclaimations even
selectively, i.e., ignore INLINE proclaimations only for DEFSTRUCT
accessors. The major impact of this proposal is just to make it clear
that a separate (PROCLAIM '(INLINE ...)) is not necessary.