In article <30ECBA95.5324CB65@wvlink.mpl.com>,
T. Kurt Bond <tkb@wvlink.mpl.com> wrote:
>Paul Wilson wrote:
>
>> This is the kind of thing the RScheme lexically-scoped syntactic extension
>> facility is designed for. Instead of macroexpanding as a conceptually
>> separate pass, it's integrated right into the compiler in a clean way.
>> The normal SICP-style compile-time environments are extended to handle
>> the funny scoping issues that come up when you write "hygeinic macros",
>> rather than requiring the macroexpander to do a bunch of the same scope
>> resolution work that the compiler already does. (E.g., to notice that
>> lambda does funny things to the meaning of identifiers.)
>
>Is there anywhere one could find out more about RScheme's syntactic extension
>facility?
>--
>T. Kurt Bond, tkb@wvlink.mpl.com
We're in the process of writing a paper about it. The next release (0.6)
will provide the source code. (The current release---0.6---has a much
weaker subset of the system, with source, which supports inline call-by-name
procedures, but isn't powerful enough to handle intentional scope tricks.
That is, you can write things control constructs like OR and COND
using it, but not binding constructs like LETREC and and FOR.)
For starters, have a look at Abelson and Sussman. The basic mechanism
is the compile-time environment structure, which reflects the lexical
nesting at a particular point during compilation. Reifying compile-time
environments (i.e., making them first class and allowing macros to
play with them) is enough to do some neat things, like defining an
object system with encapsulated slots.
--
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)
|