Path: utzoo!censor!geac!jtsv16!uunet!wuarchive!brutus.cs.uiuc.edu!apple!rutgers!aramis.rutgers.edu!bearcat.rutgers.edu!lou From: lou@bearcat.rutgers.edu (Lou Steinberg) Newsgroups: comp.lang.lisp Subject: Re: LISP compiler? Message-ID: Date: 10 Nov 89 18:33:52 GMT References: <5081@internal.Apple.COM> <5031@tekcrl.LABS.TEK.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 38 Cc: lou In article <5031@tekcrl.LABS.TEK.COM> kend@tekchips.LABS.TEK.COM (Ken Dickey) writes: > The key to being able to link an application--rather than GC and save > an image--is not to call EVAL or the compiler. Either of these must > have a full runtime support since arbitrary code may be introduced. > Without them, linking is relatively straight-forward. > > -Ken Dickey kend@mrloog.WR.TEK.COM Yes, but.... Even if you don't call EVAL, your runtimes may have surprising calls to eval in them. E.g. in common lisp, if you use READ, and don't remove the #. read macro (which causes read-time evaluation of the next s-expr read) from your read-table, then the "application maker" can't remove any part of lisp. Worse, what about functions like APPLY? If you just give compiled functions to apply you are OK, but APPLY can also take a LAMBDA expression, i.e. it needs to be able to call the interpreter, depending on the type of argument it is given. It may not be so easy for a compiler to determine whether a given argument will, at runtime, be a lambda expression. And suppose the argument is a symbol as in (apply 'foo ...). How easily can the compiler tell that at runtime foo's definition will be compiled code rather than uncompiled code? Well, suppose we do without APPLY. Unpleasant, but maybe worth it? But then what about all the other functions that take a function as an argument, like MAPCAR and SORT? About the only solution I see is to invent some kind of declaration that lets the programmer inform the compiler / application maker that it can safely remove EVAL. -- Lou Steinberg uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou arpa: lou@cs.rutgers.edu