[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue "Eliminate forced consing" re-visited
- To: masinter.PA@Xerox.COM
- Subject: Re: Issue "Eliminate forced consing" re-visited
- From: Scott.Fahlman@B.GP.CS.CMU.EDU
- Date: Wed, 24 Aug 88 11:06:09 EDT
- Cc: trwrb!smpvax1!jrg@ucbvax.Berkeley.EDU, cl-cleanup@sail.stanford.EDU
- In-reply-to: Your message of 23 Aug 88 23:11:02 -0700. <880823-231243-1402@Xerox>
What do you think about the possibility of putting (some/all/most) of the
sequence functions and also the iteration macros in the same category of
"required library"?
I don't see what this suggestion buys us. If these modules are not
required to be provided by every implementation, then they can't be used in
portable code. If they are required, as you are proposing, then the
implementors have to do the work and the library modules are
sitting out there taking up disk space. Implementations are already free
to provide a GC-for-delivery facility that flushes everything not required
by a given application; they are also free to provide an autoload facility
that doesn't load this stuff until someone touches it. All your proposal
does is to replace this autoload with an explicit require, hassling the
user.
Furthermore, I think that if both iteration and sequence libraries are
standardly available, both will be used to some extent and both libraries
will almost always be loaded. The problem is that you don't want to drag
in the version with all the hairy optimizers for obscure cases just because
the user happened to call MEMBER. If you're going to play this
minimal-core game, you want to partition these packages and drag in only
the relevant chunks. I suspect that sooner or later this business of
creating minimal core images for delivery of finished applications will
become an area of competition among the vendors. We don't want to
foreclose their options by mandating a single crude partioning.
My objection to including both a LOOP facility and further extensions to
the sequence functions had nothing to do with core image size; the cost I
was worried about was the added conceptual load on the user of learning two
distinct ways of doing the same thing, both of which are rather complex and
dangerous for the careless.
By the way, I don't really buy Ginder's argument that the :target extension
is good because it will force people teaching Common Lisp to mention
consing issues. I think they will either do that or not, depending on the
interests of the teacher and the goals of the course. Having some obscure
keyword in the language that drags this in will not make a difference in
very many cases. DELETE is already present, so if Ginder were right, the
problem is already solved.
However, I do put some weight on his comments about people preferring to
use the sequence functions even when a good iteration facility is
present, largely because it makes it clear what the program is trying to
do. If others agree with this observation, I'm ready to support this
proposal in principle, though some details need to be fixed up.
-- Scott