andy@Neon.Stanford.EDU (Andy Freeman) (09/22/90)
In article <1990Sep20.170311@ai.mit.edu> tmb@ai.mit.edu writes: >* It's perhaps OK to prototype an object system as a macro >package, but for production use, an object system (or any >equally complex extension to the language) should be part >of the compiler, for reasons of efficiency and >debuggability. I know that I'd rather debug macros than a compiler. In addition, it isn't necessarily true that sticking something in the compiler makes it more efficient, especially since "in the compiler" may well mean "some expansion that the compiler does before it starts real work". BTW - Which compiler and which object system? Group A may control one, but not the other; does that mean that they shouldn't have an object system? >Much more important to my taste than a standard macro >facility (there exists a de-facto standard anyway), would >be guidelines for a standard foreign function interface >to Scheme (at least for numerical code), and guidelines >for optimization features such as MAKE-MONOTYPE-VECTOR. The people working on macros seem to disagree. Go for it. -andy -- UUCP: {arpa gateways, sun, decwrl, uunet, rutgers}!neon.stanford.edu!andy ARPA: andy@neon.stanford.edu BELLNET: (415) 723-3088