[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: (BUG LISP) at MIT-ML
- To: GJC at MIT-MC
- From: KWC@MIT-ML
- From: Jon L White <JONL at MIT-MC>
- Date: Thu, 28 Aug 81 18:32:50 GMT
- Date: Thu, 27 Aug 81 04:59:00 GMT
- Cc: BUG-LISP at MIT-MC, GCOOK at MIT-MC, JPG at MIT-MC, MACSYMA-I at MIT-MC
- Original-date: 08/28/81 14:32:50 EDT
- Original-date: 27 August 1981 00:59-EDT
Yes, George, I'm aware of the limitation in COMPLR, whereby you can't
nest a local variables with differing declarations. In fact,
in case it had slipped your notice, that is ****precisely**** one of the
limitations for which GENTEMP had to be invented (but before you go
on, remember that there are ***inherent*** limitations in the local
declarations scheme which necessitate GENTEMP anyway).
Still, that isn't GCOOK's problem.
Date: 26 August 1981 23:08-EDT
From: George J. Carrette <GJC at MIT-MC>
JONL, you should know as well as any of us that there are known
bugs in COMPLR in the handling of LAMBDA binding and declarations.
These are what show up in GCOOK's code, not lack of using "SI:GEN-LOCAL-VAR"
. . .
Ok, where did the gensym come from? Not from any macros!
Didn't TRANSL generate the code for him with GENSYM names in it? Or do
MACSYMA programmers generally use local variable names like G0017 and G0018?
Take another case: . . .
Here your compiler confuses the two names "X" in the DO-LOOP, generating:
(COMMENT **ERROR** ((IFIX X) NOT-OF-TYPE FLONUM)
First item in list is an argument somewhere, but is of the wrong
type in function F)
See above comment on "nest"ing of local variables.
JONL, I really do understand lambda binding, and GENSYM, and GENTEMP,
so it is foolish for you to play your game assuming otherwise.
You may go on of course as you wish, but you risk a great deal in doing so.
If you do understand it, then you'll start converting many of your
macros and other automatic-source-code-writers to use SI:GEN-LOCAL-VAR,
or something like it, as appropriate. Since you haven't . . .
Because it does take the interaction of ***two*** lambda-producing
code writers to get into the binds mentioned above, and since it seems
unlikely that you'll be able to figure out where to get rid of the
GENSYM calls in TRANSL, then I changed one more part of the COMPLR
souce-code-rewriting which was using GENSYM instead of its own version
of SI:GEN-LOCAL-VAR (LOCAL-VAR, which is perfectly adequate and existed
even before GENTEMP) so that at least GCOOK's problem will go away.
But that won't stop TRANSL's bad interaction with other code writers,
like macro packages etc.