[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re2: MCL support for MOP
- To: email@example.com
- Subject: Re2: MCL support for MOP
- From: firstname.lastname@example.org (Peter Hendrickson)
- Date: Mon, 11 Jan 93 14:57:30 -0800
- Cc: email@example.com, firstname.lastname@example.org, email@example.com
- In-reply-to: firstname.lastname@example.org's message of Mon, 11 Jan 93 15:57:09 -0500 <9301112057.AA08801@larynx.cs.rochester.edu>
> 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 email@example.com 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
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.