Issue: EVAL-DEFEATS-LINKER

[edsel!bhopal!jonl@navajo.stanford.edu (Jon L White)]

I think I'll  have to agree generally with your analysis of this problem.
At Lucid, we have spent a good deal of time working on a tool similar to 
what you called COMPRESS-FOR-DELIVERY, and the results are not uniformly 
heartwarming.  Primarly, the mass of data involved in keeping track of all 
the constraints is a quagmire [that perhaps needs an expert system for 
solution?]; so it is not at all as simple a task as it seems at first.

Re: We could get rid of these named functions if, by examining all the
    application code, we could prove any of the following: ... [and]
    Clinger's proposal is to make this proof easier by eliminating a 
    large class of implict symbol-to-function conversions.

I'm just as skeptical as you are about the usefulness of making a 
controversial change in CL semantics just in order to remove one small 
aspect of the many hurdles in front of the impossible proof.  Many of 
the alleged dangers of the symbol-to-function mapping are in fact 
compile-time "harmless"; e.g. (mapc 'list l1 l2) should cause no one 
any more concern than (mapc #'list l1 l2), so why restrict it?  Also I 
like to write code like
     (dolist (fn '(a b c d e f))	
	;; Install the "boot level" versions of these basic functions
	(setf (symbol-function fn)
	      (symbol-function (append-symbols 'boot- fn))))
Rather than throw out the baby with the bathwater, I'd much rather have a 
declaration that said something like "This instance of symbol-function is 
restricted to the set of symbols {a b c d e f boot-a boot-b ... boot-f}".

Somehow, if the "proof" were ever made to be successful, I fear that the 
resultant language would be so much more like Pascal, and so little like 
the classic Lisps that the AI world grew up on, that X3J13 might just as 
well admit defeat and join the FortranADAPascalCModula crowd.


-- JonL --