On Wed, 24 Aug 2005, Marcin 'Qrczak' Kowalczyk wrote:

>Andre van Tonder <xxxxxx@now.het.brown.edu> writes:

>> Should I be able to write Scheme code whose meaning depends on
>> page layout, dots, whitespace, or comments?

> Yes, because it's useful to display source location information
> in stack traces, and location is best expressed by line and
> column numbers.

I think there's an abstraction barrier to work with here, There
is an abstraction which is profoundly useful (in fact the basic
tenet of all lispy languages) and your proposal here threatens to
break it.

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.

So, if an evaluation produces an error object and you catch it,
it's fine to have some kind of call on error objects that
*displays* the line and/or column of the error; if the user wants
a stack trace it's fine to have a function to call on a stack
frame that *displays* the line and column of the call that
created it.  But it's not okay to have an accessor applicable to
error objects or stack frames that returns either as a value that
the program can further use.  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.

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.

>> The syntax-as-lists abstraction has the decided advantage of
>> protecting me against these things, which are generally regarded
>> as wrong in the Lisp/Scheme community.

> Well, if a language declares something useful as wrong, then it's an
> argument for choosing a different language.

Only if that useful thing can coexist with all other *more* useful
things.  Lispy languages like Scheme have a *VERY* useful thing in the
code/data isomorphism.  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.

If you propose another "useful thing" that cannot coexist with the
structure/semantics isomorphism, it is quite proper to reject it.

				Bear