BYU - Spring 2013 - CS 630 - 6/11 - Paper

[Noonan]

Macros that Work Together

Summary: The author starts out by introducing issues of lexical binding in macro expansion, showing that scope is respected in the current macro system of Scheme. He then talks about syntax objects and how racket can use them in conjunction with macros in order to extend the language by sharing compile-time information. The author talks about define syntax and how that can be used in conjunction with syntax-local-value in order to grab the value of bound to the identifier of a member of a struct. The author also talks about how multiple functions are declared in a syntax-declaration (such as accessors on fields). The author also talks about how class declarations are handled in racket and the specifics of what mechanisms are used to process that declaration. The author then talks about internal definitions and how they’re handled. The author then briefly discusses packages in racket. The author then talks about how the debug tool in racket works using syntax objects in order to capture intermediate information about the program instead of fully expanding it. The author then briefly shows the core racket language. The author then outlines the different part of the racket syntax objects and also explains the differences in variable evalutaiton between racket and Lisp. The author then talks about how readers construct syntax objects and how different parts of the syntax object are evaluated. The author defines what some of the expressions he uses are in Lisp, then he talks about how one his model is simpler than the one in Racket or Scheme. The author then outlines the basic parsing algorithm and gives a simple example of the expansion of an expression into a syntax object as well as a basic parsing algorithm using operation he defined. The author then talks about how parse will deal with lexical context information. The next part talks about the expander and how it renames things as it performs the expansion to preserve lexical scope. The author then introduces a simple macro definition and explains how it will be handled. The author then talks about how to expand the simple macro definition to include lexical context and how that is handled by the expander. The author then adds in some machinery so macros can be used more like racket ones, lexpand and lvalue. The author then introduces def-bind and new-defs for making definition contexts and shows examples of how they are used. The author then discusses related work.

Major Contributions: This paper discusses the macro system of racket and more specifically shows how it allows for macros to share information between each other instead of just respecting lexical scope like in a scheme macro.

Something I learned: I learned that racket uses syntax objects for representing macros in order to handle intermediate representations as well as allowing macros to look inside each other.

Something I had difficulty understanding: At the end of page 14, to what model is the author referring? How is it simpler? What is an AST? I tried searching for its definition in adobe acrobat and couldn’t find where the author defined it

[Jay McCarthy]

We'll talk about this in class

> What is an AST? I tried
> searching for its definition in adobe acrobat and couldn’t find where the
> author defined it

An AST is an "abstract syntax tree". It is such a common idea, they
don't define it.

--
Jay McCarthy <j...@cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93

[Andrew Kent]

Macros That Work Together

The purpose of this paper is to specifically articulate the inner workings of Racket. The reason this is interesting and novel and unlike other languages that are functioning and around is because they entire Racket language, as we have discussed, is built “within itself,” using a tower of language additions that create a more and more expressive language at every step. Because all of this work of defining a language entirely within itself at each step is inherently complicated (at least when the details are involved), the macros that make this possible must be very robust and work together very well. This paper emphasizes the various ways these macros work together to accomplish the tasks they set out to tackle.

We begin with some initial examples of macros need and potential and then move into some of the interesting examples of, for instance, how an identifier can be overloaded and thus used in various contexts, all of which make sense in their respective environments (and thus it is more desired to allow this name overloading instead of having a spilled can of worms of names you have to dig through for ever feature). The example they give of this is the “egg” structure. It’s definition creates a number of bindings on accessors and methods that relate the the structure, and the egg name/keyword becomes available both in the pattern matching context and as a constructor when needed.

Another example they gave of this need for overloaded keyword definitions was in the way classes were defined in Racket. The “define” keyword is overloaded here to be allowed to cleanly and intuitively define a class, even though normally the “define” keyword meets something different in other contexts (though the higher level idea is exactly the same, thus the desire for the shared usage). Within this class example they also showed the need for the ability to force expansion of subforms of an expression, which the class requires for it’s forms like “define/public”. This is another unique thing the macro system in Racket provides.

The other example involving define, and the one I could more directly relate to, was the usage of “define” for internal definitions. This is intuitive and clean, but in reality is expanded to a letrec for execution. Define seems to be a prime candidate to illustrate the need for having more flexible keyword expansion that is traditionally found in more limited macro systems.

Packages were presented as an example of names that need compile-time descriptions of contents available so other packages could utilize the hidden definitions within the package.

After all of these examples the paper gets into some of the meat and potatoes of how these various facilities and really how the language tower itself is built. First the core language is introduced: a very limited set of keywords and definitions upon which all other macros can be expanded. It includes some of the basic building blocks: cons, functions, lists, apps, symbols, etc....

After the core language the need and power of syntax objects is introduced. THese contain the actual typed syntax as well as the information surrounding where in the program the syntax was found, where it was bound, etc... It showed the stx-e method, used for unwrapping syntax objects and getting at their parts, and the mk-stx function which creates new syntax objects by borrowing the context of another piece of syntax.

Then the paper really gets into the details of how modeling macro expansion in Racket is done - how the parsing, expansion, bindings and usage of macros occurs and how the system tracks lexical context and allows for compile-time bindings and local expansions.

Modeling Macro Expansion in Racket.

One especially unique aspect of Racket's system is the expander is decoupled from the parser - allowing for local-expands and allowing for the “pervasive use of syntax objects as a basis for program analysis and transformation” - this gives for a higher level of granularity with working with and examining macros than in other Scheme implementations. They do note their model still makes it difficult to determine if marks and renaming actually respects lexical scope as intended. They area they wish to explore further is a model with the syntactic advantages the currently posses with a more obvious relation to what we would normally think of as binding scopes.

[Yu Huang]

Title: Macros that work together

Summary: This paper first uses the example of "or" to show that language extension is possible because of wider compiler API. It then talks about the syntax object and procedure macros. From there, it claims that Racket was built based on them while further expanding the compiler functionality that is available through macros. The language extension can be characterized as macros that cooperate by sharing compile time information. Section 2 introduces many ways for macros to cooperate, including define-struct, class form that leverages define and lambda, and lambda. It uses examples to show that define-struct communicates information about the shape of a structure declaration to the match pattern-matching form, that syntax-case form matches syntax objects, that class form declares its functions and fields. Section 3 models macro expansions in Racket. It introduces the core language, the syntax object extended from the core language, the parsing that converts the syntax object to an AST, and the expander that takes a syntax object for a source program and returns a syntax object for the expanded program. 

Things I understood well: I understood well on most of the concepts of syntax object and procedure macros. Further, I understood well on the ways to cooperate with each macro and the examples to show their usage. 

Things I have trouble understanding: not very clear for the extensions when reading the modeling of macro expansions.