Re2: MCL support for MOP

[ph@netcom.com (Peter Hendrickson)]

> Brent Benson   writes...
> I'm not convinced that it is hard to tree shake code that does not
> contain calls to eval.  I would appreciate it if someone could tell me

Then Ben Hyde writes ...
> More generally any interning can create symbols that can then have
> symbol-function applied to them.  I.e. parsing user input can lead to
> difficulties knowning what the domain over which intern can operate.
> This is can be handled by disallowing intern, and find-symbol.  The
> application writer must then implement his own find-symbol/intern if
> he desires this functionality.

Bob Kerns says ...
> In fact, in my coding style, I avoid symbol-function.  I tend
> to write macros that define functions, and then store the function
> itself in a data-structure, or write #'foo instead of 'foo.

> If you use symbol-function, who knows what you might end up
> running?  ;=)

Then miller@cs.rochester.edu states...
> On the flip side, I couldn't live without symbol-function. When I
> incrementally redefine a function symbol in a file (e.g. defun of foo),
> I don't want to go have to recompile every #' mention of the function, I
> want the newest version always. Sure, it loses in the face of a macro,
> but that's just another reason to try to avoid macros (or at least get
> them right the first time :-).

How about a tree shaker that warns you that symbol-function or
eval calls prevent it from shaking everything out? Then the
developer can decide whether he or she wants a small application
or symbol-function.

I'd be happy to gimp the functionality of Lisp from time to time
if it meant I could have an application which fit onto a single
diskette. I have not yet heard a convincing explanation of what
makes this hard.

For simple or even moderately complex applications, I suspect the
lavish amounts of disk space and memory consumed by MCL are mostly
unused. (Please enlighten me if you know better.)

I like MCL and I think the people who have worked on it over the
years have done a great job. But, I'd like it even more if I could
confidently compete with C programmers using it.

Peter Hendrickson
ph@netcom.com