[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loss of abstraction



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