On 13 Jan 2003, Nicolas Neuss wrote:

> > *What* is going on here?
>
> I don't know for sure, but I also observed that declaring something to be
> FIXNUM does not help very much, so I dropped it in many cases.  (It is
> quite clear that it will not help much, because FIXNUMs have a compact
> representation which has only little overhead when being manipulated, but
> it is of course strange that declarations make code slower.  Maybe someone
> else knows more.)

Well, yes, but at least, a LISP system should know that during GC, it
needn't scan the data part of a fixnum array for further pointers.

Furthermore, the compiler should be able to hard-code, say, fixnum
addition, while it has to go through a generic variant of "+" if this
information is not available.

> Some other remarks on your code: First, I would suggest dropping all the
> special macros like i-dotimes (hint: macroexpand dotimes), often CMUCL can
> find out itself if something is a fixnum, especially if you declare types
> more specifically like (integer 0 1000).

In general, LISP cannot (and must not) derive that 1+fixnum is a fixnum.
For applications like these, I cannot and should not set any "natural"
integer limits, but at last, I know that no one will be able to leave the
fixnum range.

>  Second, you should use iteration instead of recursion whenever possible

Why, if I may ask so?

-- 
regards,               [EMAIL PROTECTED]              (o_
 Thomas Fischbacher -  http://www.cip.physik.uni-muenchen.de/~tf  //\
(lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y)           V_/_
(if (= x 0) y (g g (- x 1) (* x y)))) n 1))                  (Debian GNU)


Reply via email to