[klibertp]

In most of those implementations (certainly in SBCL) it's either you break or step; you can't start stepping from a breakpoint. SBCL got some support for that this year, see https://news.ycombinator.com/item?id=43791709. It, however, doesn't allow stepping into any functions called after the break.

Also, the compilers are allowed to make the code unsteppable in some cases, depending on optimization declaration: generally, debug needs to be >=2 and > speed/compilation-speed/space. In some circumstances, you land in decompiled/macroexpanded code, which is also quite unhelpful.

Anyway, it's not that source-level stepping isn't there at all, it's just quirky and somewhat inconvenient. A fresh implementation that does comparatively little optimization and is byte-code based can probably support debuggers better. I hope such support won't go away later when the native code compiler is implemented.

[WalterGR]

Thanks!

If I recall correctly, there are macros to control the level of code optimization? And some implementations can turn it off entirely for interactive use?

Or am I off-base?

[klibertp]

> If I recall correctly, there are macros to control the level of code optimization?

Yup, you can either `(proclaim (optimize (debug 3) (speed 1)))` somewhere, which will take effect globally, or you can `(declare (optimize ...))` inside a particular function. It sounds great in theory - and it is great, in some respects - but this granularity makes it harder to ensure all interesting code is steppable when you need it.