Andre van Tonder wrote:
>  The current representation does allow source tracking for compound syntax
>  objects.  One would make the reader put the location of each node (pair or
>  vector) in a hash table.

As pointed out, this causes complications wrt life-time and garbage
collection.  The overhead of "weak references" for each pair might be
excessive for a normal read.  However, if should not be difficult to
maintain a hacktable *only* when in "parse Scheme code mode".  In that
case one could maintain a hash table as a dynamic parameter.  Note that
an s-expression passed to eval might have been read by "plain read" so
may not have source position information.

Btw, Kawa *does* have a PairWithPosition class that inherits from Pair.
The read routine creates PairWithPosition instances, so we have source
location information, even for the arguments to eval.

There is one ambiguity when associting positions with pairs: Consider a
list:
(A B C)
1234567 ; column numbers.
This returns 3 pairs:
P3 = (A . P2) ; column 1 or 2 ???
P2 = (B . P1) ; column 4
P1 = (C . ()) ; column 6
Obviously P2 and P1 have columns 4 and 6 - i.e. the column of the car
parts.  For consistency, perhaps P3 should get column 2.  But the column
of the entire list is 1.  Which column should be used in (say) an error
message isn't always clear.  Perhaps best is to always use the column of
the car part, and if you need the column of the entire list you get that
from the context - presumably the car of an out list or the top level.
--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/