On Tue, 23 Aug 2005, Michael Sperber wrote:

> I want to change the representation ot carry location
> information, possibly to record if parens or brackets were used,
> possibly whether dots appeared in the source code, possibly comments,
> and probably all kinds of other stuff in the future.

Bear with me while I play devil's advocate.

Syntax as lists (or isomorphic to) represents the highest level of abstraction
(on the input) that preserves the meaning of Scheme code.  It is pretty much
the unique interface satisfying this theoretically nice criterion, which IMO
makes it a very valid minimal API for a Scheme macro system.

Runtime symbols, lists, numbers, etc. could also have carried various
annotations, including information useful for runtime error tracking.  In fact,
in Lisp some of them do (property lists) but these were dropped in Scheme for
good reasons, even though Lispers find them very useful.

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?  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.

A minimal level of support for user-access to location would attach location to
identifiers only.  Are there sufficiently many compelling use cases that are
not covered by this?  I'm not sure comments or square brackets qualify ;-)

Note that the SRFI is IMO not meant as another portable syntax-case (although
it does supply the latter as a convenience).  The syntax-as-lists aspect
of the current API indeed seems to be a distinguishing feature attracting
a majority of initial potential users (not just Schemers but also Lispers).

Cheers
Andre