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 <andre@xxxxxxxxxxxxxxxxx> 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 \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/