Subject: Re: benefits of LISP? From: Erik Naggum <firstname.lastname@example.org> Date: 27 Nov 2000 03:49:37 +0000 Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * David Bakhash <firstname.lastname@example.org> | I caught this comment here, and couldn't really decipher exactly what | you meant. Are you saying that somehow Lisp programmers should be | able to write things that they currently cannot, such as special | operators? Or that they should be able to malloc/free memory | directly, such as in C? What kind of behavior, exactly, are you | referring to? New functions that utilize low-level features of the processor and/or the internal representation of objects. E.g., you could write bignum arithmetic that basically store values directly into an unnormalized bignum and process them as integers in machine registers. You could write your own functions that produce inlined instructions to support particular optimizations. Intel has a BSWAP instruction that can be used to convert between network byte order and native byte order, and it really ought to be inlined and available at a very low level when you basically stuff a bignum into a fixed-encoding field in a protocol. Suppose you want a byte rotate function. You can write a fully portable version that no compiler would be smart enough to optimize into a rotate instruction if the processor has one and the byte was supported by the hardware, but it would be nice if you could define the general case portably and optimize into a single instruction when that is possible. This is not particularly hard to do, but it does require intimate knowledge of the compiler in most languages and environments. Allegro CL lets me define and use new "instructions" and new low-level forms to invoke them. Amazingly powerful stuff. I do not think there should be a lower limit to what you can program in a Common Lisp environment. Recall that several operators in Common Lisp were originally instructions in processors of old. Common Lisp has such an unfair reputation for being high-level when it can easily be more low-level than C, with far greater access to the hardware since Lisp does _not_ pretend that certain types are abstract when they aren't and vice versa, like C does. I do not consider allocating and freeing object low-level in this sense, however. Both tasks are very complex and actually high-level due to the many tasks involved. It is a high-level policy decision whether either should be done manually or automatically and whether you need an ownership protocol for all objects. However, once you have an object, regardless of means, how you choose to use it may be low-level, such as playing with the individual bit fields of a boxed floating point number in order to, say, be able to compute logarithms of arbitrarily large integers. #:Erik -- Solution to U.S. Presidential Election Crisis 2000: Let Texas secede from the Union and elect George W. Bush their very first President. All parties, states would rejoice.