This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
Andre van Tonder wrote:
The current representation does allow source tracking for compound syntaxobjects. 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 6Obviously 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 per@xxxxxxxxxxx http://per.bothner.com/