Re: why is lisp fast?


I'm not sure if you read my post in another location on this thread
before you sent this one. I will assume not.

Also, I am getting the sense from your attention to alternatives, that
the main thrust of your post is contained in these two places, first
in the next-to-last paragraph here:

(MY-ADD MOST-POSITIVE-FIXNUM MOST-POSITIVE-FIXNUM) is a perfectly
valid call to MY-ADD given the above code, and it should return the
integer which is twice MOST-POSITIVE-FIXNUM. Any other answer is a
conformance bug.

This is true. Every CL that wants to compete with C must have such a
non-conformance. Ours comes (effectively and indirectly) with the
declaration of optimization settings of speed = 3 and safety = 0.

I do not accept this, however. Why do you equate "wanting to compete
with C" with "must deviate from the standard in this respect"? In
particular, why do you reject the possibility of declaring the result
of the addition as a fixnum if the user wishes to inform the system
that there will be no overflow, and the definition of a new operator
if the user wishes to perform signed arithmetic with the natural word
size of the platform?

[and, for the record, I don't know how much Ansi C specifies about its
mudular arithmetic, so I can agree to your "comon C implementations"
modification, below]

(For onlookers -- since I'm sure Duane knows this -- the C standard
makes no guarantees about the behaviour of signed arithmetic overflow,
so competing with C with respect to overflow on signed integers is a
pretty nebulous concept. I'll happily read that as "competing with
common C implementations of addition", though.)

And secondarily, the last sentence of your paragraph, below:

Allegro CL is behaving in exactly the way it is documented to behave.

I apologize for my phrasing, which in the word "misbehaves" was with
reference to standard behaviour and was not intended to imply that
this deviation was accidental nor that it was not useful in some
circumstances. I consider it unfortunate that Allegro CL deviates
from the standard in this way on code that would otherwise demonstrate
the safety advantages of Lisp; I furthermore believe that there are
better ways of expressing the aim of performing hardware arithmetic on
lisp objects.

If this is the case, let me summarize the discussion with two
questions:

1. Given two operations at some nondescript but agreed-upon settings
for speed and safety (you're welcome to choose), and given some
implementation-defined declaration (let's call it
fixnums-remain-fixnums, for argument), are the two functions here
semantically equivalent?

(defun foo (x y)
(declare (optimize speed) (fixnum x y))
(declare (fixnums-remain-fixnum t))
(+ x y))

(defun bar (x y)
(declare (optimize speed) (fixnum x y))
(the fixnum (+ x y)))

2. When you say

better ways of expressing the aim of performing hardware arithmetic on
lisp objects.

are you suggesting continuing to use the + or - operators?

--
Duane Rettig duane@xxxxxxxxx Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
.

Relevant Pages