[plt-scheme] Syntax Reader and Macros
> The first problem is that
> when I use read-syntax to get a syntax object representing the
> expression, I can find no way to attach it to the correct
> lexical environment. I get errors on anything I do, since it
> seems to be attached to an empty lexical environment, with not
> even #%app, #%datum, or #%top defined.
That last statement is correct: `read-syntax' produces syntax objects
without context.
> How can I attach an
> already built syntax object to a particular lexical environment?
If `ctx' is a syntax object containing the context you want, and if
`content' is the read-syntax' result:
(let loop ([content content])
(cond
[(pair? content)
(cons (loop (car content))
(loop (cdr content)))]
[(null? content) null]
[else
(let ([v (syntax-e content)])
(datum->syntax-object
ctx
(cond
[(pair? v)
(loop v)]
[(vector? v)
(list->vector (loop (vector->list v)))]
[(box? v)
(box (loop (unbox v)))]
[else
v])
content
content))]))
WARNING: The above code doesn't handle cycles in `content'. (Well, I
took the code from the implementation of `include', which means that I
need to fix `include'...)
> Also, when I read characters and expressions from a syntax
> object converted into a string, I read one character per logical
> character in the string. In the code, however, a character such
> as a newline can be represented as a newline directly in the
> input, \n, \12, \012, \xA, or \x0A. This makes it rather
> difficult to predict how many characters in the input file
> correspond to one character in the string, which makes it hard
> to calculate offsets for highlighting and error reporting in
> various parts of that string. Is there any way to tell how many
> characters one character in a string corresponded to originally?
Not currently.
> Would it be possible to attach some table to string syntax
> objects that tells you which characters in that string
> correspond to multiple characters in the source?
That's an interesting suggestion, but I wonder where to stop. For
example, symbols and numbers can have many different concrete
representations, too. At some point, I wonder whether it isn't best to
re-read the source to extract additional, special-purpose information.
Matthew