Andre van Tonder <xxxxxx@now.het.brown.edu> writes:

> Syntax as lists (or isomorphic to) represents the highest level of
> abstraction (on the input) that preserves the meaning of Scheme code.

I would not call lists a higher level of abstraction than
distinguished types for syntax.

> Runtime symbols, lists, numbers, etc. could also have carried various
> annotations, including information useful for runtime error tracking.

Syntax tree has a much higher need of attaching additional information
than runtime lists.

> In fact, in Lisp some of them do (property lists)

Only symbols.

> Runtime error tracking is expected to work behind the scenes. Is
> there a compelling argument against this behind-the-scenes paradigm
> for expand-time tracking, without infecting the syntax representation
> with elements extraneous to its meaning?

Attaching information to numbers behind the scenes puts an
unreasonable burden on the representation of runtime values.
In particular small integers could not be represented by unboxed
values.

> The expander itself can certainly keep track of source location,
> intermediate expansion steps, etc., perhaps even to a higher degree
> than is done with opaque objects, and it can do all this orthogonal
> to the data representation.

It's not orthogonal. If various insteances of the syntax representing 5
are indistinguishable, it's impossible to attach different information
to them.

It would be a pity if the implementation could not report a compile
time warning for (3 4) with source location only because it was passed
through a macro.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/