[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: small integers
- To: Harley Davis <firstname.lastname@example.org>
- Subject: Re: small integers
- From: Scott_Fahlman@SEF1.SLISP.CS.CMU.EDU
- Date: Fri, 09 Oct 92 15:05:21 -0400
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- In-reply-to: Your message of Fri, 09 Oct 92 16:58:42 +0000. <9210091558.AA25256@ilog.ilog.fr>
This solution has been used in Le-Lisp for about 10 years. It works
quite well within individual functions and for fixnums in general, but
does not address the crucial boxed float problem across function
Huh? We're talking about integers in this thread, though there have also
been some messages flying around about floats. Let's try not to muddle the
two -- the issues are rather different.
I don't think the call to fix+ or whatever should be masked by a +
Why not? If we're going to have fix+ and int+, hiding them both behind a +
macro with a big compile-time switch seems quite attractive to me. This
makes it easy to live within the default policy you like (overflow-safe or
efficient) and to change that policy easily. You don't have to write the
more verbose (ugly, confusing) forms unless you want to micro-manage
Furthermore, I don't see how to implement such a macro unless
the Dylan macro system allows access to a lot of compiler information.
I haven't looked closely a the macro stuff as yet, but it had better allow
macros to generate different code based on declarations or something like a
compile-time variable setting. Else, it's not good enough.
I think + should check for overflow and fix+ should not, as Fahlman
suggested when he brought up this idea. They are really two different
semantic operations, one working on numbers and the other on
Hmmm... I'm not sure what that means. They both check for overflow of the
fixnum range. One (fix+) signals an error while the other (int+) rolls
into bignum code.