Re: Bignum support

Hrvoje> So you plan to disallow any bignums smaller or equal to Hrvoje> most-positive-fixnum? That never crossed my mind, Hrvoje> probably due to exposure to Python. I don't think he'd necessarily want to _disallow_ them. I may be wrong, but I seem to remember that Common Lisp assumes that bignums will be automatically canonicalized (but that might just be rationals, complex, quaternions, etc). Anyway, it's an intuitive extension of the canonicalization idea. However, I've been thinking about the annoying CCL interface for a while. There is _zero_ reason why the CCL interface is infix; it could just as easily, with some care, be a restricted Lisp dialect. (It wouldn't just be arithmetic expressions because loop control, I/O, and some complex functions are necessary.) But once you have that, you could do (setq result (declare-arithmetic (let ((i 0) (result 0)) (while (< i bound) (setq result (+ i result)) (setq i (1+ i)))))) Of course when interpreted declare-arithmetic would just eval its argument (you could even have JIT compiling, I suppose), but when compiled you could compile to CCL. The Lisp-CCL compiler could generate two kinds of exceptions, one would be errors for code that isn't legal arithmetic, and the other would simply force the compiler to restart with Emacs Lisp byte-code. In that context, it might be useful for declare-arithmetic to take an argument like :domain 'bignum (arbitrary precision arithmetic) or :domain 'fixnum (error on overflow). The current CCL interpreter neither supports bignums nor (IIRC) does bounds checks, but one can dream, right? Hrvoje> lower the fixnum size without visible penalty. (Why would Hrvoje> we want that? Perhaps to reintroduce small conses.) And BASKIN_ROBBINS_CHAR! Hrvoje> Here it would be nice to have compiler support for that, Hrvoje> so that the compiler can generate fixnum-only opcodes Hrvoje> where it can prove that fixnums are used. But that's not Hrvoje> really possible without lexical scoping, so we can forget Hrvoje> it. Way ahead of me, I see. But you could go the declaration route. Then you would only incur overhead on all-fixnum calculations, and that would be linear in the number of arguments. Presumably that would be worthwhile in many important cases. Hrvoje> With a little cleverness, the all-fixnum case might remain Hrvoje> as fast as it is now. I don't see why would have to be clever, since fixnums aren't lrecords and bignums would have to be. You'd have to decide whether you want marker conversions (eg) or bignum recognition to be faster, but that's it. Hrvoje> OK, you've convinced me. Me too. May I provisionally put "experimental bignum support by Yoshiki Hayashi" in the proposal I'm drafting for the next release? That would mean that you'd like to try to have it ready for a September release. It doesn't mean you promise (I know about the time constraints of first year grad students), you can always withdraw the proposal if you decide it's not feasible. And of course the board would decide whether to accept the proposal, I can't promise it would be in. But it looks very good so far. (N.B. "Experimental" refers to "builder must explicitly configure", not my estimate of quality / stability of the code.) -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."