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