[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


For the record, I generally like the spirit of the current proposal.
I have a couple of specific comments on the wording that I hope can be
addressed before it comes to an actual vote because I think they will
make the proposal clearer and easier for others to evaluate, but they
don't affect my actual vote:

 * The opening of the proposal is awkwardly worded. Just about any wording
   would be better. As a straw man...

    ``Clarify that to define a function FOO which is not INLINE by default
      but for which (DECLARE (INLINE FOO)) will make FOO be locally inlined,
      the proper definition sequence is:''

 * The test cases don't illustrate the problem you're trying to solve.
   Change "(defun f4 ...)" to:

    (defun f4 (b) (f3 b))			;F3 is not inline.
    (defun f5 (c) (declare (inline f3)) (f3 c)) ;F3 is locally inline.
    (defun f6 (c) (f3 c)) 			;The local effect is not persistent.

   The surrounding descriptive text must be changed to be consistent, of course.

As an aside, I would also like to see the following issue addressed.
Perhaps it's enough different that it should be done via a separate
issue, but I'll just mention it here and let you sort out what to do:

You describe the effect of PROCLAIM INLINE as two-fold -- (a) set up for
the definition of function to record extra info and (b) enable inlining.
I think it would be nice if (a) were "used up" by the next definition,
so that

 (DEFUN F (X) X)
 (DEFUN F (X) (+ X 1))

would leave you with a NOTINLINE definition of F. You'd have to do

 (DEFUN F (X) X)
 (DEFUN F (X) (+ X 1))

to get F to keep being inline. Note that (b) would not be used up, so you could do

 (DEFUN F (X) X)

all you wanted without losing the inline info for F. The main feature would be
that you could write:

	   (DEFUN ,FN ,BVL ,@FORMS)))

and then do


and have doing

 (DEFUN F (X) X)

later on not wind up with F being accidentally inline.