bear <xxxxxx@sonic.net> writes:

> It's fine to signal errors that show the line and column of the
> evaluation that created them, or display stack traces that show
> line and column information for each invocation.  But it is *NOT*
> fine for the program to be able to *use* that information for any
> purpose; that would create a situation where someone could change
> the semantics of a program by doing things that have nothing to
> do with the structure; inserting blank lines, indenting the code
> differently, or writing list structure differently, I think that
> violates a fundamental principle that ties semantics in lisps to
> list structure rather than to surface syntax.

In theory you are right. But pragmatically it's useful to expose that
information, and rely on sane programs to not do antything more fancy
with it than to format and dump it, or log it, or send it somewhere.

There is a language subset which doesn't use that information at all,
and its semantics is specified in terms of a list structure with
symbols. But real programming languages are more than Turing machines
or executable lambda calculi.

> Or at least if such an accessor exists, and your program behaves
> differently (apart from displaying wrong locations) when calls to
> it are replaced with calls to a random number generator, then your
> program is wrong.

I agree.

> Since it's not (or at least IMO *shouldn't*) be part of the
> program's usable data, I think it's entirely reasonable to
> keep line/column information outside the data structure of
> the pairs and symbols and stack frames rather than inside.

It doesn't follow. Keeping them directly attached to the abstract
syntax tree is the most natural representation, and it doesn't have
to give up source locations of literals without identity.

> Lispy languages like Scheme have a *VERY* useful thing in the
> code/data isomorphism.

I never valued this. I'm not a typical Lisper/Schemer. I use these
languages only as the source of inspiration for my language.

> That a Lisp program reads as data and the data is isomorphic to the
> parse tree of the program itself, is the central and fundamental
> liberating factor that removes so many restrictions from lisps and
> makes lispy macrology possible.

It's not necessary for powerful macrology at all. The important point
in Lisp and Scheme macros is that they are defined in terms of the
abstract syntax tree rather than in terms of strings or opaque
intervals of code. But in Scheme it's not essential for the abstract
syntax tree to use the same types as used to store lists and symbols
used for regular runtime data, and modern Scheme already has abandoned
this in the case of identifiers.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/