[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
COMPLR bug
- To: JONL at MIT-MC
- Subject: COMPLR bug
- From: Jeffrey P. Golden <JPG at MIT-MC>
- Date: Thu, 3 Sep 81 10:44:00 GMT
- Cc: GJC at MIT-MC, BUG-LISP at MIT-MC, GCOOK at MIT-MC, MACSYMA-I at MIT-MC
- Original-date: 3 September 1981 06:44-EDT
From: JONL@MIT-MC
Date: Wed, 27 Aug 81 04:59:19 GMT
Original-Date: 08/27/81 00:59:19 EDT
Subject:
To: GJC at MIT-MC
CC: (BUG LISP) at MIT-MC, GCOOK at MIT-MC, JPG at MIT-MC,
CC: MACSYMA-I at MIT-MC
I'm aware of the limitation in COMPLR, whereby you can't
nest a local variables with differing declarations.
Apart from the fact that it would be nice if the above bug were fixed,
GJC's first example did not exhibit "differing declarations":
From: GJC@MIT-MC
Date: Wed, 27 Aug 81 03:08:46 GMT
Original-Date: 08/26/81 23:08:46 EDT
Subject:
Let us look at a simple case:
(defun f (x)
((lambda (x)
(declare (flonum x))
(times x ((lambda (x)
(declare (flonum x))
(times x x))
x)))
(sin x)))
The declarations here are the same. But the compiler still gives an error:
(COMMENT **ERROR** (FLONUM G0001)
Local declaration occurs too late in function in function F)
; DATA ERROR - TO PROCEED TYPE $P
I think it would be REALLY nice if THIS bug were fixed. It seems to me
that one would expect a code generator to generate cases involving
consistent declarations, and it is a shame that even that does not
work. This really adds to the burden of the code generator.
Furthermore, the error message given by the compiler involves a G0001.
I don't think that is a good example of human engineering.
(Again, I am not saying there is anything wrong (except in terms of
clarity of code) with "inconsistent nested local declarations" and that
the whole bug shouldn't be fixed. I am just more concerned that the
bug also happens when the declarations are consistent.)