[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
&optional arguments and complr
- To: MOHAMMED at SRI-KL
- Subject: &optional arguments and complr
- From: Jon L White <JONL at MIT-MC>
- Date: Sat, 14 Nov 81 19:38:00 GMT
- Cc: BUG-MACLISP at MIT-MC
- Original-date: 14 November 1981 14:38-EST
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
. . .
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.