I'll have a look - thanks. <br><br>Its a fairly high overhaul rather than a few incremental improvements which is why I'm a bit reluctant. SBCL is rather more mature than ABCL①...<br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 4, 2017 at 12:56 PM Luís Oliveira <<a href="mailto:luismbo@gmail.com">luismbo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Jan 4, 2017 at 5:31 PM, Alan Ruttenberg<br class="gmail_msg">
<<a href="mailto:alanruttenberg@gmail.com" class="gmail_msg" target="_blank">alanruttenberg@gmail.com</a>> wrote:<br class="gmail_msg">
> Rather than cluttering up the newer version what do you think of having<br class="gmail_msg">
> slime include the older version and have the swank loader conditionally load<br class="gmail_msg">
> old or new depending on the ABCL version?<br class="gmail_msg">
><br class="gmail_msg">
> There is also slime maintenance cost associated with having it be backward<br class="gmail_msg">
> compatible.<br class="gmail_msg">
<br class="gmail_msg">
FWIW, swank-sbcl.lisp typically accrues conditionals for dealing with<br class="gmail_msg">
older versions until sufficient time has passed (usually years) and<br class="gmail_msg">
said conditionals become a nuisance.<br class="gmail_msg">
<br class="gmail_msg">
Having two different swank implementations for older and newer ABCLs<br class="gmail_msg">
seems worse than conditionals in terms of maintenance costs.<br class="gmail_msg">
swank-sbcl.lisp contains various tricks for making conditionals more<br class="gmail_msg">
manageable. Perhaps some of those practices might help in this case?<br class="gmail_msg">
<br class="gmail_msg">
--<br class="gmail_msg">
Luís Oliveira<br class="gmail_msg">
<a href="http://kerno.org/~luis/" rel="noreferrer" class="gmail_msg" target="_blank">http://kerno.org/~luis/</a><br class="gmail_msg">
</blockquote></div>