[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: loss of abstraction

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.

Andre van Tonder <andre@xxxxxxxxxxxxxxxxx> 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.

> Runtime symbols, lists, numbers, etc. could also have carried various
> annotations, including information useful for runtime error tracking.

Syntax tree has a much higher need of attaching additional information
than runtime lists.

> In fact, in Lisp some of them do (property lists)

Only symbols.

> Runtime error tracking is expected to work behind the scenes. Is
> there a compelling argument against this behind-the-scenes paradigm
> for expand-time tracking, without infecting the syntax representation
> with elements extraneous to its meaning?

Attaching information to numbers behind the scenes puts an
unreasonable burden on the representation of runtime values.
In particular small integers could not be represented by unboxed

> The expander itself can certainly keep track of source location,
> intermediate expansion steps, etc., perhaps even to a higher degree
> than is done with opaque objects, and it can do all this orthogonal
> to the data representation.

It's not orthogonal. If various insteances 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.

   __("<         Marcin Kowalczyk
   \__/       qrczak@xxxxxxxxxx
    ^^     http://qrnik.knm.org.pl/~qrczak/