This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 are here. Eventually, the entire history will be moved there, including any new messages.
On Mon, Aug 22, 2005 at 06:09:26PM +0200, Michael Sperber wrote: > > But let me ask. Suppose you are using a typical Scheme implementation > > in which CAR and CDR operate only on plain pairs. You are then > > constrained to implement compound syntax objects as lists. You have > > lost the ability to use some other abstraction. As a practical > > matter, what impact does that have on you? What would you like to be > > able to do with a syntax object abstraction that you'd not be able to > > do if you've lost that abstraction? > Change its representation. Actually, it's not clear which of the approaches -- syntax objects as lists, or syntax objects with their own API -- is more "abstract". Rather, we should ask which abstraction is more _useful_: gathering these data types under the same procedural interface because of their similarities, or separating them because we want multiple implementations of syntax objects. The answer in Lisp has been, for 46 years, that syntax objects and lists _are_ the same. It might well turn out that this is wrong and syntax objects are something slightly or altogether different. But clearly, the burden of proof is on the one who claims that we need more opaque syntax objects. The possible extensions you mention -- tracking comments, different kinds of brackets, and whether pairs were entered in dotted or list form -- all break the barrier between (eval) and (read). If Scheme was to do such things, we would have to redefine those procedures, or to define that programs are not necessarily read in via (read). I think that, rather than bringing programs further from being data, s-expressions should be augmented in whatever ways needed to not lose this crucial abstraction: data as programs, programs as data. It also turns out that none of your concerns, including source location tracking, needs opaque syntax objects. For comments, you can have a "comment" object that is embedded in the s-expression. If you want two kinds of brackets, you can define there to be two kinds of lists. It strikes me as highly unlikely that these extensions to s-expressions would benefit programs but would not benefit any other kind of data. Also, comment tracking (and other stuff, too) can be implemented in the same way as source location tracking: with an external hash table. Panu -- personal contact: atehwa@xxxxxx, +35841 5323835, +3589 85619369 work contact: panu.kalliokoski@xxxxxxxxxxx, +35850 3678003 kotisivu (henkkoht): http://www.iki.fi/atehwa/ homepage (technical): http://sange.fi/~atehwa/