issue SHARP-COMMA-CONFUSION, version 1

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: Thu, 29 Dec 88 03:09:30 PST
    From: Jon L White <jonl@lucid.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
dead symbols.

    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.".