&optional arguments and complr

[Jon L White <JONL at MIT-MC>]

Functions defined with &optional arguments are automatically turned into
'lexpr's, so that a variable number of arguments may be handled.  The only 
full solution to the "number of arguments" problem during compilation is to 
declare such functions as *LEXPR, in the files which use them.  However, note
that COMPLR's message is merely a warning -- the compiled code is still
correct (albeit somewhat less than optimal since SUBR-type calls to a function 
with LSUBR-calling-sequence cannot have their UUO links 'snapped').

    Date: 12 Nov 1981 1408-PST
    From: MOHAMMED at SRI-KL
	    There is  a  bug in  the  way complr  handles  functions  with
    optional arguments. I've  prepared a dribble  file to demonstrate  the
    problem:
    . . . 
	    1. Despite the  fact that  the function TEST1  is loaded  when
    TEST2 is compiled, complr decides that something is wrong because  the
    function is being called with a different number of arguments.
	    3. It makes no difference whether  the fasl or lsp version  of
    TEST1 is loaded.
Whatever information may be found about TEST1 must be consistent with
that in the intended target environment -- declarations are the only safe
way to give this information, since the compilation environment need not be
(and indeed in many cases is not) consistent with the target.
	    2. When TEST1 is re-compiled in the same complr as TEST2,  the
    problem does not occur.
After the COMPLR compiles a function, it makes the declarations that are
deducible from its definition; in this case, it notes that TEST1 is LSUBR
type in the target environment.
	    4. Declaring TEST1  to be  a *LEXPR in  the TEST2  file is  an
    effective temporary solution to the problem.
Also a long-term solution.