Re: Question: LispWorks IDE with different CL engine?

Hi,

TLDR: I use both Sly and LW IDE. For debugging, visual class browsing, call
hierarchies, profiling, there is no replacement for LW IDE. For everything
else, like daily REPL and code editing and navigation, Sly is very good;
for inspecting values Sly is adequate too.

I doubt you can make LW stepper work with any other lisp. I second Rainer
on Sly (a fork of Slime) - it has "stickers" for debugging. I use Sly and I
prefer it to Slime, and for REPL and editing (but not debugging) - I prefer
Sly even to LW IDE.

I did not try the Sly's stickers, because I use LW's stepper when I need to
put serious effort into debugging. I guess it may be better than (break...)
but worse than LW IDE. Joao, the Sly's author, described the sticker based
debugger here: https://zenodo.org/records/3742759

Slime (and perhaps Sly) has a stepper interface, but I guess it is not
compatible with LW, because LW stepping is so much more sophisticated.
There is a stepper in SBCL that works with Slime, I tried it on simple
examples, but even SBCL maintainers discouraged investing time in it,
apparently not many people are interested in it (caveat: I talked to
someone > 10 years ago).

Other than for debugging and visually browsing class hierarchies and call
hierarchies, Sly (+ helm fuzzy autocomplete + paredit + symbol highlight)
is my daily IDE, for all 3 Lisps I use: LW, ABCL and SBCL. REPL has
incremental search on history and little reader macros like #v1, #v2 that
refer to previous results (or #v3:2 if an expression returned multiple
values) - features that I definitely miss in LW IDE. It has
goto-definition, who-calls etc (but you cannot see nested graphs of
callers). Another feature I have in SBCL and miss in LW (the compiler, not
IDE) is that who-calls in SBCL points to specific places in function code
where calls are present, whereas LW points to the whole function. Also, in
SBCL + Sly, if I compile a single function (not the whole file),
goto-definition takes me correctly to the definition, but in LW Lisp + Sly,
I have a choice to go to the original file or to a temporary emacs buffer
with a weird name that was apparently used to compile the function, and the
list grows with every compilation (it may be a bug in Sly - LW
implementation though).

Cheers,
Piotr




On Tue, Feb 3, 2026 at 9:25 AM Uģis Lācis (as ugis dot lacis at equa dot
se) <[email protected]> wrote:

> Hi,
>
>
>
> Yes, this is sort of what I am doing now, but the positive answer to my
> original question would accelerate the progress.
>
>
>
> Reason is, often when I get LispWorks running state into SBCL, it does
> fail in different place due to reasons which are often very hard to find.
> Point taken about not all warnings and notes addressed, but sadly, due to
> very large code base, this is actually not a good idea (as it is often with
> legacy code bases, it is not clear if that part of code is used and if the
> warning/note patching on that part is even a useful work) ...
>
>
>
> Best,
> Ugis
>
>
>
> *From:* Marco Antoniotti <[email protected]>
> *Sent:* Tuesday, 3 February 2026 10:17
> *To:* Uģis Lācis <[email protected]>
> *Cc:* Tim Bradshaw <[email protected]>; Yuri Davidovsky <[email protected]>;
> [email protected]
> *Subject:* Re: Question: LispWorks IDE with different CL engine?
>
>
>
> Hi
>
>
>
> My suggestion is what others have made.  Get it to run on LW and then pass
> it in SBCL trying to satisfy its often annoying notes and warnings.
>
>
>
> That's the way I work, and it has served me well.  Portability is another
> issue.
>
>
>
> MA
>
>
>
> On Tue, Feb 3, 2026 at 10:07 AM Uģis Lācis (as ugis dot lacis at equa dot
> se) <[email protected]> wrote:
>
> Hi Tim (and everyone who chimed in the discussion),
>
>
>
> Thanks for all the responses, interesting read. What I am doing, really,
> is working in an old closed-source LISP code-base, which we are trying to
> port from ACL 3.0.2 to modern LISP. Our aim is actually to be portable,
> i.e., we hope to be able to use both LispWorks and SBCL (and potentially
> some other LISP) for running our code.
>
>
>
> We have bought LispWorks primarily for the same reason as Paul mentioned,
> ease of use and convenient debugging. This part I have found much harder to
> use in SBCL (I have tried both SLIME and VSCode + Alive extension). What I
> have determined is that SLIME is much more capable than VSCode (at least in
> terms of inspecting CLOS structures), however, tricky to keep as everyday
> tool (I guess EMACS buffers is the culprit ... I just have not had time or
> managed to churn through the workflows there to come up with my own and fix
> a cheat sheet ...). And due to this, my progress with SBCL is lagging
> behind that of LispWorks. Sadly, as code base is quite large, we do not
> have the option to (re)write it in LispWorks and run in SBCL; the fact is –
> the current state does run worse in SBCL compared to LispWorks.
>
>
>
> So this is basically what I want to do – have as good debugging in SBCL as
> I have in LispWorks.
>
>
>
> Regarding basic REPL, tracing, rudimentary breakpoints and annoying
> stepping ... That works out of the box in VSCode + Alive, nothing needs
> implementation there.
>
>
>
> Best,
> Ugis
>
>
>
> *From:* Tim Bradshaw <[email protected]>
> *Sent:* Monday, 2 February 2026 19:48
> *To:* Yuri Davidovsky <[email protected]>
> *Cc:* Uģis Lācis <[email protected]>; [email protected]
> *Subject:* Re: Question: LispWorks IDE with different CL engine?
>
>
>
> The question is not whether you can persuade the LW IDE to talk to SBCL
> but what use is that, and is is worth the candle?
>
>
>
> If you're using the LW IDE you have a high-quality, deeply integrated CL *right
> there*, in the same Lisp image as the IDE.  That gives you most of the
> things people liked about LispMs: the LW IDE is, by margin, the closest
> thing to using a LispM I know of (it's not very like a LispM in interface
> but the all-in-one-image thing is a big deal).  Getting an implementation
> that is sitting at the end of a bit of string to be anything like that nice
> is going to be ... well, good luck with it
>
>
>
> I think we need to know what OP wants to achieve.
>
>
>
> --
>
> Marco Antoniotti, Professor, Director         tel. +39 - 02 64 48 79 01
> DISCo, University of Milan-Bicocca U14 2043   http://dcb.disco.unimib.it
> Viale Sarca 336
> I-20126 Milan (MI) ITALY
>
> REGAINS: https://regains.disco.unimib.it/
>