BYU - Spring 2013 - CS 630 - 6/04 - discussion

[Noonan]

Summary:  We started by saying the big problem with macros is the error occurs far from where it was actually introduced. We talked about all the different ways let can yell at you if you mess up that were presented in the the paper. We then talked about how Lisp ignores extra parameters. We then discussed that most compilers want to define let as a macro, so an advantage of macros is there’s inherently less that the compiler has to check. Intel does something similar with their chips. Complex instructions translated into less complicated ones. the template is what the macro expands to.  We talked about syntax-parse. A major innovation is the usage of elipses and in contrast the name changes involved in using syntax-rules in order to get the same behaviour as ellipses is very complicated. We then went over a syntax-rules example. We talked about how MBE only protects against a one of the types of errors. One way to protect against other errors is a guard. Guards are predicates that run against a pattern variable. The purpose of the guard is to look inside the pattern variables and ensure they have appropriate shape. Guards are bad because the error message doesn’t tell you which guard failed and why. We then went over an example where guards duplicated code. We learned that sometimes the pattern only binds so much, so you need to look inside of it and then look at its pieces and that causes duplicate code. We then showed a simple example of how people avoid guard feature. If it’s a good feature, then people will use it. Then we had an example of what it takes to get good error messages using a guard. Most of the code was digging through the pattern. We then had a discussion about how syntax-case helps users isolate errors. Jay has no sympathy for users who make mistakes. Jay likes the idea of showing the user all the information in a sorted way when an error occurs or what patterns it should have matched and how they were off of each pattern. We had a random discussion about how a lot of ideas in CS have actually been around for a while but lost. We then had a discussion about how to internalize macros by viewing them as a prolog program, instead of as a parsing problem. We went over the example of how the errors are generated by syntax-parse.  We then talked about the syntax patterns that are recognized by the syntax-patterns when syntax-parse is parsing. We then talked about the action patterns that are used to keep compiling or backtracking. We then talk about head patterns that keep track of multiple patterns. then we went to the racket pattern page and looked at the different patterns used with syntax-parse.

Something I learned: The prolog problem vs the parsing problem. I didn’t internalize thinking about macros in terms of a prolog proof until Jay said that until today.

Lingering questions: So do people generally use syntax-rules or syntax-parse to declare macros in racket? I thought I heard you say that most people still use syntax-rules. Why aren’t they using syntax-parse?

[Jay McCarthy]

syntax-rules is the most common because it is so tight for a single pattern:

(define-syntax-rule (let ([var rhs] ...) body)
((lambda (var ...) body) rhs ...)

vs

(define-syntax let
(syntax-parser
[(_ bs:distinct-bindings body:expr)
(syntax/loc stx
((lambda (bs.var ...) body) bs.rhs ...))]))

The big thing is that we shouldn't use syntax-case, except in the code
that is used to make syntax-parse.

Jay


--
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

[Yu Huang]

Title: Fortifying Macros 

Summary: We started with the discussion about the problem of the existing macro system. We followed the example of let in this paper to illustrate many ways that let macro can make errors. Macro writers, eager to move on as soon as “it works,” will continue to write sloppy macros like these unless their tools make it easy to write robust ones. MBE is such an tool where macros are specified in a notation close to the initial informal equation, and the parsing and transformation code is produced automatically. When discussing about guard effects, guard forces us to duplicate code since it must match patter which is sometimes terrible. It is not easy for macros to robust with easy understanding specification. We also talked about the example of ellipsis in the Racket structure. It is different in the syntax between using e ... and ee ... because ee ... asks two same things first. We then shows several example with syntax-parse.

Things I learned: the feature of MBE, guards, etc.