[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
issue SHARP-COMMA-CONFUSION, version 1
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: issue SHARP-COMMA-CONFUSION, version 1
- From: Jon L White <jonl@lucid.com>
- Date: Thu, 29 Dec 88 03:09:30 PST
- Cc: sandra%defun@cs.utah.edu, cl-compiler@SAIL.STANFORD.EDU
- In-reply-to: Kent M Pitman's message of Tue, 27 Dec 88 16:42 EST <881227164231.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
re: [Statistics] I just wasted over an hour of my very valuable time
dredging them up. This had better close discussion on this issue:
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?] On the other hand,
as I said before, the whole question is moot:
(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.
(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? and would
that be the only source of tens of thousands of spurious symbols
[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".
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.
-- JonL --