loss of abstraction
Andrew Wilcox
(22 Aug 2005 15:46 UTC)
|
||
Re: loss of abstraction
Michael Sperber
(22 Aug 2005 16:09 UTC)
|
||
(missing)
|
||
(missing)
|
||
Re: loss of abstraction
bear
(23 Aug 2005 18:37 UTC)
|
||
(missing)
|
||
(missing)
|
||
Re: loss of abstraction
Andre van Tonder
(23 Aug 2005 15:08 UTC)
|
||
Re: loss of abstraction
Marcin 'Qrczak' Kowalczyk
(23 Aug 2005 15:54 UTC)
|
||
Re: loss of abstraction Andre van Tonder (23 Aug 2005 16:19 UTC)
|
||
Re: loss of abstraction
Andre van Tonder
(23 Aug 2005 15:55 UTC)
|
Re: loss of abstraction Andre van Tonder 23 Aug 2005 16:19 UTC
On Tue, 23 Aug 2005, Marcin 'Qrczak' Kowalczyk wrote: > Andre van Tonder <xxxxxx@now.het.brown.edu> writes: > >> Syntax as lists (or isomorphic to) represents the highest level of >> abstraction (on the input) that preserves the meaning of Scheme code. > > I would not call lists a higher level of abstraction than > distinguished types for syntax. What I meant was that you get a higher level of abstraction by ignoring details (location, comments, etc.) that do not affect the meaning. When you ignore precisely all these details, you get something that is isomorphic to a list, every time. > It's not orthogonal. If various instances of the syntax representing 5 > are indistinguishable, it's impossible to attach different information > to them. > > It would be a pity if the implementation could not report a compile > time warning for (3 4) with source location only because it was passed > through a macro. As an example of what I mean, invoking syntax-error in the reference implementation will display the complete backtrace of all intermediate expansion steps back to the original offending source expression, for which a source location can be displayed with reader support. While I am not advocating any particular mechanism now, I personally find this more useful than just a source location, as some Schemes do, and it is orthogonal to the syntax-object representation, since nothing needs to be attached to the syntax data. Cheers Andre