[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue SHARP-COMMA-CONFUSION, version 1
- To: email@example.com
- Subject: issue SHARP-COMMA-CONFUSION, version 1
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 29 Dec 88 09:46 EST
- Cc: KMP@STONY-BROOK.SCRC.Symbolics.COM, firstname.lastname@example.org, cl-compiler@SAIL.STANFORD.EDU
- In-reply-to: <8812291109.AA09875@bhopal>
Date: Thu, 29 Dec 88 03:09:30 PST
From: Jon L White <email@example.com>
The "numbers" on total number of symbols elided from the Cloe window
system are indeed impressive; but there are no numbers on "time
wasted" [is it because the sum total of "wasted" time is a truly a
negligible portion of any application's time?]
I gave you the comparative instruction sequences for the 3600 and 386.
In the case of the 3600, a slower instruction is used. In the case of
the 386, an extra instruction is used. The cost depends on your
application, but people are so benchmark-conscious these days that
I don't think it's something we can ignore.
(1) The proposals are to flush sharp-comma, and replace it with the
non-equivalent LOAD-TIME-EVAL. So far, no one believes that
the proposed new feature cannot suffice for their needs, so
there is no reason to retain the broken sharp-comma.
Right. I was just making the point that the two proposals need some
explicit tie, so it doesn't turn out by quirk of fate that we kill #,
and don't pass LOAD-TIME-EVAL.
(2) The Cloe window system code was surely written with the known
availability of sharp-comma; who's to say what the code would
have looked like had it been written without that availability.
Would it really have used 26000 spurious symbols?
This isn't a fair question. I was addressing only the claim in this
proposal that using defparameter was an adequate workaround. Indeed it
is not, and Cloe would have done something else. My point was that
whatever we'd have done instead would probably be considerably harder to
think up than any of the simple-minded workarounds presented in the
writeup. The writeup needs to either cite serious workarounds or come
out and say "Gosh, you'd be in a real bind if we removed this without
providing something equivalent, like the LOAD-TIME-EVAL proposal. Here
are a few simple things that work sometimes, but in the hard cases
we just don't have any idea what you might try."
... and would
that be the only source of tens of thousands of spurious symbols
To paraphrase some well-known congressman: A few 100K here a few 100K there,
pretty soon it starts to add up to real address space...
[Please! don't even spend 60 seconds trying to answer that].
I know that Lucid Lisp has a step that reclaims several thousand
symbols, very very few of which were used as "temporary
defparameters" (yes, we *have* to do the step, regardless of
sharp-comma); nevertheless, any such "wasted symbols" could
be reclaimed by this kind of technique, after the system had
been completely loaded and "snapped".
This mystifies me. As I understand it, these defparameters can't be snapped
because you can't prove they won't be SETQ'd. So you can't reclaim them as
To reiterate my main point, none of these allegations -- substantiated or
not -- belong in the "Cost to Users" section. At best they should be put
into the discussion section, where they can continue to foster frutiless
debates. This "Cost" section should link to the LOAD-TIME-EVAL issue,
and assess the cost of conversion to that format; I think Sandra has
already done a reasonable job of offering a conversion paradigm that will
fit most cases.
I don't care what allegations in Cost or not. I'd be content for that
section to be smaller -- I just want it to be honest. The workarounds it
cites are fine for a few simple cases, but do not scale up to serious
applications. There is no fair way to say if "most" is an appropriate
way of quantifying the cases where it works. As such, I'd avoid any such
term and just say plainly that the cited techniques aren't adequate for
the general case. Let the reader decide for him- or herself.
Also, I just think as a point of style, we cannot limit the Cost
discussion to the cost of conversion to LOAD-TIME-EVAL unless we have
voted in LOAD-TIME-EVAL. But it's ok with me if we limit the discussion
of the Cost in the other case to a simple sentence: "If LOAD-TIME-EVAL
doesn't pass, of course, doing without #, will be very much harder; no
simple set of workarounds has been suggested which deal with all current
uses of #, in the absence of the new LOAD-TIME-VALUE special form.".