This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
On Wed, 24 Aug 2005, Marcin 'Qrczak' Kowalczyk wrote: >Andre van Tonder <andre@xxxxxxxxxxxxxxxxx> 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