Re: Compiler Excised

[egdorf@zaphod.lanl.gov (Skip Egdorf)]

      We have an application that takes full advantage of the dynamic nature of
      Lisp.  It allows a non-programmer user to interact with the app and add
      intelligence to a knowledge base.  In order to do this the app has to do
      defclasses on the fly.  Unfortunately, to do this most efficiently, the app
      should be created without the compiler excised contrary to the licensing
      literature included with MCL[...]

   I too have run into this problem in both MCL and ACL 2.0 (formerly ACL/PC).

   I have thought of five possible workarounds:
   (If anyone can think of other approaches, please let me know!)
     (1) write your own compiler in MCL and provide it along with your app.
     (2) figure out an efficient interpretive way to do the language-processing
	 you actually want in your app.  I'd bet there are much more efficient
	 ways to do most things than calling EVAL.
   (1+2) compile to an intermediate form that you can then interpret rapidly
	 (using precompiled Lisp functions that you write).
     (3) Convince Apple's lawyers you really won't be putting out a competitive
	 product if they just let you use compile for your set of special cases.
     (4) Have your users buy a full MCL license.

   When (3) and (4) are impractical, I believe (1+2) is

I have been using (4), but this is a bit hard. (RE: the discussion on
comp.lang.lisp regarding what it takes to convince a company to go
with Lisp rather than C for that new product...)

The two major things folks do that cause this are:

1. Use general eval. Usually bad. Slap the user's hand. Not the vendor's problem.

2. Use (eval '(defclass ...)) because nobody has agreed on the part of the
metaobject protocol for portable runtime class creation. Is it ensure-class?
Perhaps it is (make-instance 'standard-class)?  Perhaps its...
This could be fixed by the vendors. Unfortunatly it takes agreement on just
whose mechanism to use. So we can lump it in with our dreams for a standard
defsys and FFI. ... And a few more turn to C++ and Visual Basic...

					Skip Egdorf
					hwe@lanl.gov