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.
bear <bear@xxxxxxxxx> 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 \__/ qrczak@xxxxxxxxxx ^^ http://qrnik.knm.org.pl/~qrczak/