On Tue, 23 Aug 2005, Michael Sperber wrote:

>Panu Kalliokoski <xxxxxx@sange.fi> writes:

>> The answer in Lisp has been, for 46 years, that syntax objects and lists
>> _are_ the same.

> Sure.  The answer in Lisp has also been that identifiers and symbols
> are the same.  Turns out it was wrong.

I do not believe that this is true.  Why do you?

> Moreover, once that choice is
> made, changing the representation is seriously hindered by the fact
> that the representation wasn't abstract to begin with.

>> 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).

>> Also, comment tracking (and other stuff, too) can be implemented in the
>> same way as source location tracking: with an external hash table.

> Sure.  In fact, records in general can be implemented with an external
> hash table, and some Lisp programmers (of the past?) might think this
> is a good idea.  I don't.

IME, the list structure being code is rock-solid and empowering.
It has helped me build tons of abstractions, by the very fact
of its simple concreteness and easy-to-manipulate nature. I'm
wary of overcomplicating basic structure that works well.

Allowing the changing of representations may cause problems
of *less* abstraction, since code written to implement
hundreds of particular abstractions might not still work.

It's nice to have line numbers with your  errors, but I don't
think that a mechanism for tracking them ought to have any
repercussions or structure that the programmer can see or
has to think about.  Also, it's not at all clear that pairs
are the proper place for such things.  But I think I agree
with Panu that if you are going to change the representation
of pairs for syntax, I'd prefer that *all* pairs, not just
the syntax pairs, use the same routines and constructors.

				Bear