|
From: David L. <da...@li...> - 2012-10-24 18:25:12
|
Hi,
Quoting Zach Beane (xa...@xa...):
> I get this:
>
> ; caught STYLE-WARNING:
> ; SB-EXT:QUIT has been deprecated as of SBCL 1.0.56.55. Use
> ; SB-EXT:EXIT or SB-THREAD:ABORT-THREAD instead.
>
> Although it's not *too* difficult to do it manually, it might be nicer
> to provide a date rather than a version number.
I would like to follow up on this (by now rather old) discussion with a
(possibly) controversial opinion:
Can we please un-deprecate QUIT?
My rationale is as follows:
- QUIT has existed at least since CMUCL times -- it is inconvenient
for users to switch away from it.
- It is not hurtful to have both EXIT and QUIT. While I wouldn't
personally have advocated adding a second such function, now that
they exist, it is easiest to keep them both. In fact, it could make
it easier for users to switch between CMUCL/SBCL and other Lisps
using the name EXIT, in the sense of a compatibility function.
- If we do not keep them both, we should retain the older name, not
a newer one.
- As far as I understand (please correct me if I'm wrong), the
reasoning against QUIT is that, at some point during SBCL's
development, its (originally per-process) semantics got
re-interpreted to do certain things with regard to threads, which
ultimately turned out to be problematic. So what is deprecated is
not the original per-process meaning, but rather the incompatible
per-thread meaning affecting callers in multithreaded scenarios.
Hence, if we change QUIT to work like EXIT, we're actually restoring
a meaning rather close to what QUIT used to do in SBCL and CMUCL in
the past.
- And now that the old semantics have been deprecated for a few
releases, any users actually depending on the per-thread usage have
been warned, so it's not too hurtful to them if QUIT reverts to a
per-process meaning.
Specifically, my suggestion is to leave QUIT's keyword arguments as-is,
but remove the special case of (not (main-thread-p)) from its body.
d.
|