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: xxxxxx@iki.fi, +35841 5323835, +3589 85619369
work contact: xxxxxx@helsinki.fi, +35850 3678003
kotisivu (henkkoht):	http://www.iki.fi/atehwa/
homepage (technical):	http://sange.fi/~atehwa/