I think I would prefer adding this without any dependencies. Additional
dependencies make the testing process more cumbersome. So just putting
it in separate file(s) and using reader macros for the implementations
is probably the right thing to do.
But I'm open to counter-arguments.
On 26 Aug 2025, at 14:58, Q H wrote:
Hi there,
It has long been a known problem that ITERATE, as a code-walking
macro, might confuse CL implementation's source tracking facility,
preventing the debugger from locating the accurate form for runtime
error (e.g. it often jumps to the top level iterate form, which is
often not helpful). My recent patch
https://gitlab.common-lisp.net/iterate/iterate/-/merge_requests/24
partially addresses this, but it's only guaranteed to work for simple
function calls.
Recently I have discovered an IMO much better way: in fact, on my
local branch I can get *perfect* debugger source tracking on SBCL and
Clozure CL for virtually any forms inside ITER, relying on just a
single implementation-dependent interface:
(note-source-transformation ORIGINAL-FORM NEW-FORM)
Indicate that ORIGINAL-FORM is transformed to NEW-FORM.
This implementation dependent interface is really needed, because in
standard CL there's no way to express such information. The interface
already exists in Clozure CL, and I have a working polyfill for SBCL.
Believe me, the source tracking it brings is so good that you, as a
ITERATE user, will want it! The question is given that currently
ITERATE is purely ANSI CL with no ASDF dependency, how should we go
about adding this?
I see two options:
1. Include the implementation-dependent note-source-transformation
code in ITERATE itself. We can split non-portable code into a
different file from iterate.lisp. The advantage is the ITERATE system
stays free from ASDF dependency.
2. I can publish a separate NOTE-SOURCE-TRANSFORMATION system, and
update ITERATE to use it. The advantage is non-portable code is
factored into another system (quite common practice nowadays given the
proliferation of TRIVIAL-* systems), and the interface can be used by
other code-walking macros.
What do people think?
Best,
@kchanqvq
