Hi all,
All this talk about "the" has left me wondering about the way declare
and declaim work in general.
Say I have a function foo in "foo.lisp" which is
(declaim (ftype (function (double-float) double-float) foo))
(defun foo (x)
(declare (double-float x))
(+ x 42d0))
If I use foo later in "foo.lisp", the ftype declaration should allow
the compiler to avoid boxing both the arguments and the return value,
right? I'm wondering...
Unfortunately, I can redefine foo at any point, which could make the
box/unbox assumptions later in the code invalid, so maybe the compiler
can't actually unbox anything.
If this is true, what good is the "ftype" declaration? Does it help
me at all on the top level? I can see that if I define functions in a
labels statement, the compiler can be assured that they won't be
changed, so it can optimize them properly. However, that is, well,
unpleasant from the point of view of debugging and modularity.
How does the package system interact with this? I presume that, since
other programs can change even un-exported elements in a package, the
compiler cannot assume values won't change.
If the declaim lets me avoid boxing the return value within
"foo.lisp", what happens if I use the function foo in another source
file "bar.lisp"? Would I have to declaim foo there as well?
Thanks for any light you can shed on this subject,
- Johann
Johann Hibschman <······@astron.berkeley.edu> writes:
>
> Say I have a function foo in "foo.lisp" which is
>
> (declaim (ftype (function (double-float) double-float) foo))
>
> (defun foo (x)
> (declare (double-float x))
> (+ x 42d0))
>
> If I use foo later in "foo.lisp", the ftype declaration should allow
> the compiler to avoid boxing both the arguments and the return value,
> right? I'm wondering...
Yes, but I'm not aware of any compiler that will do so. Using some
extensions in CMUCL, you can get this to happen, but not because of
the declaim. (See extensions:start-block in the user manual.)
>
> Unfortunately, I can redefine foo at any point, which could make the
> box/unbox assumptions later in the code invalid, so maybe the compiler
> can't actually unbox anything.
Well, if you make foo different later, your declaim is a lie, and
lying to the compiler is bad.
>
> If this is true, what good is the "ftype" declaration? Does it help
It's quite useful for CMUCL. The argument types may not help much,
but the return type is very useful for CMUCL. CMUCL is told foo
returns a double-float, so it can generate code assuming that foo can
only be a double-float. That means much less consing and much faster
execution. Without the declaim (or the function definition), CMUCL
must assume foo can return anything, and must generate code
accordingly.
> If the declaim lets me avoid boxing the return value within
> "foo.lisp", what happens if I use the function foo in another source
> file "bar.lisp"? Would I have to declaim foo there as well?
I think so. Otherwise the compiler must assume foo returns anything
in bar.lisp.
Ray
In article <··············@astron.berkeley.edu>,
Johann Hibschman <······@astron.berkeley.edu> wrote:
>Unfortunately, I can redefine foo at any point, which could make the
>box/unbox assumptions later in the code invalid, so maybe the compiler
>can't actually unbox anything.
If you redefine a function that has been declared with an FTYPE
declaration, the new definition has to satisfy the declaration, or you have
to recompile all the callers. CLtL2, p.686 says:
The compiler may assume that the signature (or "interface contract") of
functions with FTYPE information available will not change.
There's an equivalent statement in the ANSI spec.
>How does the package system interact with this? I presume that, since
>other programs can change even un-exported elements in a package, the
>compiler cannot assume values won't change.
Correct. However, as a software provider, you're generally allowed to
assume that customers won't be modifying the internals of your software;
you certainly can't be expected to support them if they change how your
software works. So you're allowed to provide declarations, make functions
inline, etc. It would be like replacing the engine in your car and then
bringing it in to the original dealer for warranty service.
See section 25.1.3 of CLtL2, or section 3.2.2.3 of the CLHS
<http://www.harlequin.com/education/books/HyperSpec/Body/sec_3-2-2-3.html>,
for the list of assumptions that the compiler is permitted to make.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.