I've seen and read several references to "inlined" functions and
"open-coded" functions. People seem to draw a somewhat subtle (to me)
distinction between the two, in that the compiler will "inline" a
user-defined function, but "open-code" a compiler-defined function
(e.g. car or cdr).
The HyperSpec has this to say about an inlined function:
<quote>
[...] the code for a specified function-name should be integrated into
the calling routine, appearing ``in line'' in place of a procedure
call.
</quote>
Have I understood the "inline" vs. "open-coded" distinction, vis-a-vis
user-defined vs. compiler-defined functions? Or do most people use
"inline" and "open-coded" synonymously and I've read in something they
didn't mean?
I Googled for several combinations of "inline" and "open-code" and
e.g. "compiler", and "definition". Nothing I read defined "open-code"
explicitly. This leads me to believe that the term "open-coded" is
probably a standard term in the art of compiler writing, training in
said art I rather lack.
Thank you for any light you can shed on this.
-- Larry
······@theclapp.org (Larry Clapp) writes:
> I've seen and read several references to "inlined" functions and
> "open-coded" functions. People seem to draw a somewhat subtle (to
> me) distinction between the two, in that the compiler will "inline"
> a user-defined function, but "open-code" a compiler-defined function
> (e.g. car or cdr).
I don't mean anything different about these two although I probably
use the term inline when referring to user code to remind people that
this is triggered by an INLINE declaration. It is beyond the scope of
the document what a compiler will do with primitive operations and
whether they will go through INLINE declarations.
A similar problem exists for compiler optimizers since we provide
compiler macros in portable code, but implementations are permitted to
run optimizers of other kinds at various phases of compilation. Some
work on source code and some work on an annotated source tree, for
example. I don't think we provide good verbs for this, so you don't
see the distinction, but if you did you might find people clung to
terms near "compiler macroexpand" when talking about stuff the user
could reasonably expect to simulate and we were more free-form about
which verb we used when we were talking about what implementations
could do on their own.
Still a third case would be "dynamic variables" vs "special
variables". We often use dynamic variables when emphasizes their
non-static character, but we use SPECIAL when trying to remind you of
the declaration you need to make, whose name is historically chosen.
> The HyperSpec has this to say about an inlined function:
>
> <quote>
> [...] the code for a specified function-name should be integrated
> into the calling routine, appearing ``in line'' in place of a
> procedure call.
> </quote>
>
> Have I understood the "inline" vs. "open-coded" distinction,
You have almost certainly correctly discerned the pattern of word
usage in informal speech, but there is no formal distinction of this
kind made by the language definition itself.
> vis-a-vis user-defined vs. compiler-defined functions? Or do most
> people use "inline" and "open-coded" synonymously and I've read in
> something they didn't mean?
I think they are completely synonymous to the level the language
defines. Because the INLINE facility is presented by showing a
functional spec as a "pattern" and then asking the compiler to perform
a transform into place, while the effect of something like EQ is
included in place by rules that might involve more of a Turing machine
trying to accomplish a goal, there are differences in patterns of
usage.
> I Googled for several combinations of "inline" and "open-code" and
> e.g. "compiler", and "definition". Nothing I read defined
> "open-code" explicitly. This leads me to believe that the term
> "open-coded" is probably a standard term in the art of compiler
> writing, training in said art I rather lack.
Or just a cultural difference in teaching. For example, when I
learned to program (in languages like FORTRAN, BASIC, and PL/1) I was
taught that in a function defined by something like f(x,y)=x+y, x and
y are "formal arguments", and in a call to that function f(a,b) the a
and b are expressions to evaluate yielding "actual arguments". At
least, I was taught that by some people. Other people taught me that
x and y are "parameters" and that a and b are "arguments". In Lisp,
which I studied several times from different instructors, I was
sometimes taught x and y were "lambda variables" and that a and b were
"arguments". Mostly this just shows that when talking about
extralingual things, notation varies.
It's just something that teachers and writers do. I interleaved my
work on the standard between corporate representative (where I was
allowed to advocate changes in technical position) and editor (where I
was not allowed to change any technical detail in the definition
unless voted upon by committee). On days when I had my Project Editor
hat on, I had to just do what the committee said in terms of how it
affected running programs, but I still fudged around with the
terminology for _describing_ ANSI CL when I thought better terminology
would improve understanding. (The two changes that caused the most
stir were the introduction of the concept of designators and the
reorganizing of the terms boolean and generalized boolean; the latter
case surprised a bunch of people because they had not realized the
actual technical change was made by Steele in CLTL, not by me in ANSI
CL. Steele's terminology was so subtle they'd missed it. Shifts in
wording make things sometimes clearer but they also create community
splits, and create confusion in people who thought they understood
things and then suddenly see a new term they need to hook up to...)
My belief is that inlining and open-coding were again just attempts to
describe the same phenomena with different metaphors. Lisp picked up
one of these terms and incorporated it into the language, giving it
distinguished status, and so the other term was still used, but more
"in the shadows".
But my understanding is based, as is yours, on statistical observance
of use. I haven't ever heard a discussion on the subject that I can
recall...
······@theclapp.org (Larry Clapp) writes:
> I've seen and read several references to "inlined" functions and
> "open-coded" functions. People seem to draw a somewhat subtle (to me)
> distinction between the two, in that the compiler will "inline" a
> user-defined function, but "open-code" a compiler-defined function
> (e.g. car or cdr).
I think that any such real distinction is a matter of conversational
style.
> The HyperSpec has this to say about an inlined function:
>
> <quote>
> [...] the code for a specified function-name should be integrated into
> the calling routine, appearing ``in line'' in place of a procedure
> call.
> </quote>
>
> Have I understood the "inline" vs. "open-coded" distinction, vis-a-vis
> user-defined vs. compiler-defined functions? Or do most people use
> "inline" and "open-coded" synonymously and I've read in something they
> didn't mean?
>
> I Googled for several combinations of "inline" and "open-code" and
> e.g. "compiler", and "definition". Nothing I read defined "open-code"
> explicitly. This leads me to believe that the term "open-coded" is
> probably a standard term in the art of compiler writing, training in
> said art I rather lack.
>
> Thank you for any light you can shed on this.
I view "inlined" and "open-coded" as synonyms. What I think you may
be trying to distinguish are the various ways that inlining can be
achieved:
1. The compiler has information about the function which allows it
to inline it by default.
2. On compilers which obey it, the INLINE declaration can be given to
do substitution of the body of a user-defined function in-line.
3. The code which is written can be in the form of a macro, which
is expanded in-line at compile-time.
4. A compiler-macro can be written for a function which the compiler
may macroexpand at compile time.
All of these techniques must be overridable by a NOTINLINE declaration.
The real difference is actually not in the kind of inlining done, but
in who does it.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)