Thomas wrote: > Hm, how about a corresponding "symcall" defmacro? You cannot entirely get > rid of it, I fear, but this is perhaps the best you can get - unless you > start defining your own language which is compiled to lisp first, then to > machine code.
LOL! defining my own language (PPL = Proof Programming Language, it's rather similar to ML) is actually what I did with LISP. The abstract machine is based on Henderson's SECD and Cardelli's FAM. Overhead of the generated byte code is about 30-50% compared to LISP. Still too much for the rewrite engine which consumes 50-90% of the theorem prover's time. But I'm getting off-topic. > I won't call this an intrinsically bad thing - at least, the Linux kernel > to my understanding isn't C as well, but GCC-language, and I must admit to > occasionally write CMUCL code instead of Lisp code. But you must be well > aware when you write Lisp code and when not. Sure. I don't care if I'm adhering fully to the standard. If I have to add some #+cmu's and CMU is faster than the other LISP's (that's what I've heard) I don't care. I just don't want to rewrite and debug code from scratch, that I've written more than 5 years ago. But seriously: Couldn't defining f as a macro that simply calls (symbol-function f) be the solution? Can macros be redefined? Or does this have the same restrictions that symbol-function slots? Seems that's another idea to try, if the workaround does not work fully (I'm still trying to sort the foreign function bug out. Before that works I cannot do any meaningful experiments, since rewrite rules have to be parsed). Anyway, thanks all for the ideas. Gerhard
