2006 Scheme and Functional Programming Papers, University of

More documents

Recommendations

Info

Derivation ::= (make-mrule Syntax Syntax Derivation) | (make-prim:if Syntax Syntax Derivation Derivation Derivation) | (make-prim:lambda Syntax Syntax Renaming Derivation) | (make-prim:let-syntax Syntax Syntax Renaming DerivationList Derivation) . . . Renaming ::= Syntax × Syntax Figure 8. Derivation structures ExpandTerm ::= visit enter-macro macro-pre macro-post exit-macro ExpandTerm | visit enter-primitive Primitive exit-primitive return Primitive ::= PrimitiveLambda | PrimitiveIf | PrimitiveApp | PrimitiveLetSyntax | ... PrimitiveLambda ::= primitive-lambda rename ExpandTerm PrimitiveIf ::= primitive-if next Expandterm next ExpandTerm next ExpandTerm PrimitiveLetSyntax ::= primitive-let-syntax rename NextExpandTerms next-part ExpandTerm NextExpandTerms ::= ε | next ExpandTerm NextExpandTerms Figure 9. Grammar of event streams Derivation ::= . . . | (make-error-wrapper Symbol Exception Derivation) | (make-interrupted-wrapper Symbol Derivation) Figure 10. Extended derivation datatype PrimitiveLambda/Error ::= primitive-lambda error | primitive-lambda renames ExpandTerm/Error PrimitiveIf/Error ::= primitive-if error | primitive-if next ExpandTerm/Error | primitive-if next ExpandTerm next ExpandTerm/Error | primitive-if next ExpandTerm next ExpandTerm next ExpandTerm/Error Figure 11. Grammar for interrupted primitives PrimitiveLambda ::= primitive-lambda (! ’malformed) renames (? ExpandTerm) PrimitiveIf ::= primitive-if (! ’malformed) next (? ExpandTerm ’test) next (? ExpandTerm ’then) next (? ExpandTerm ’else) Figure 12. Grammar with error annotations 24 Scheme and Functional Programming, 2006
• A potentially interrupted subexpansion is either interrupted and ends the event stream, or it completes successfully and the event stream continues normally. Naturally, we use a macro to elaborate the annotated grammar into the error-handling grammar. This is a nontrivial macro, and we made mistakes, but we were able to debug our mistakes using an earlier version of the macro stepper itself. 5.5 The Middle End: Hiding Macros Once the back end has created a derivation structure, the macro debugger processes it with the user-specified macro hiding policy to get a new derivation structure. The user can change the policy many times during the debugging session. The macro debugger retains the original derivation, so updating the display involves only redoing the tree surgery and re-running the front end, which produces the rewriting sequence. Conceptually, a macro hiding policy is simply a predicate on macro derivations. In practice, the user of the debugger controls the macro hiding policy by designating modules and particular macros as opaque or transparent. The debugger also provides named collections of modules, such as “mzscheme primitives,” that can be hidden as a group. Policies may also contain more complicated provisions, and we are still exploring mechanisms for specifying these policies. We expect that time and user feedback will be necessary to find the best ways of building policies. We refer to the original derivation as the true derivation, and the one produced by applying the macro policy as the synthetic derivation. The datatype of synthetic derivations contains an additional variant of node that does not correspond to any primitive syntactic form. This node contains a list of subterm expansions, where each subterm expansion consists of a derivation structure and a path representing the context of the subterm in the node’s original syntax. The middle end constructs the synthetic derivation by walking the true derivation and applying the policy predicate to every macro step. When the policy judges a macro step opaque, the debugger hides that step and the derivation for the macro’s result, replacing the macro node with a synthetic node. The debugger then searches for expanded subterms within the hidden derivation. While searching through the subterms, it keeps track of the path through the opaque term to the subterms. When it finds an expanded subterm, it adds the derivation for the subterm’s expansion, together with the path to that subterm, to the synthetic node. Figure 13 illustrates one step of the macro hiding process. Suppose that the expansion of let/cc is marked as hidden. The debugger searches through the hidden derivation for subderivations corresponding to subterms of the opaque term. In the example from the figure, there is no subderivation for k, but there is a subderivation for e1 . The macro hiding pass produces a new derivation with a synthetic node containing the derivation of e1 and the path to e1 in the original term. In this case, e1 can be reached in the term (let/cc k e1 ) through the path (-- -- []). If the expansion of e1 involves other opaque macros, then the debugger processes the derivation of e1 and places its corresponding synthetic derivation in the list of subterm derivations instead. As a side benefit, macro hiding enables the debugger to detect a common beginner mistake: putting multiple copies of an input expression in the macro’s output. If macro hiding produces a list of paths with duplicates (or more generally, with overlapping paths), the debugger reports an error to the programmer. Engineering note 1: Macro hiding is complicated slightly by the presence of renaming steps. When searching for derivations for subterms, if the macro hider encounters a renaming step, it must also search for derivations for any subterms of the renamed term that correspond to subterms of the original term. Engineering note 2: Performing macro hiding on the full language is additionally complicated by internal definition blocks. PLT Scheme partially expands the contents of a block to expose internal definitions, then transforms the block into a letrec expression and finishes handling the block by expanding the intermediate letrec expression. 10 Connecting the two passes of expansion for a particular term poses significant engineering problems to the construction of the debugger. 5.6 The Front End: Rewriting Steps Programmers think of macro expansion as a term rewriting process, where macro uses are the redexes and primitive syntactic forms are the contexts. The front end of the debugger displays the process of macro expansion as a reduction sequence. More precisely, the debugger displays one rewriting step at a time, where each step consists of the term before the step and the term after the step, separated by an explanatory note. The macro stepper produces the rewriting steps from the derivation produced by the middle end, which contains three sorts of derivation node. A macro step (mrule) node corresponds to a rewriting step, followed of course by the steps generated by the derivation for the macro’s result. A primitive node generates rewriting steps for the renaming of bound variables, and it also generates rewriting steps from the expansion of its subterms. These rewriting steps occur in the context of the primitive form, with all of the previous subterms replaced with the results of their expansions. For example, given subderivations test, then, and else for the three subterms of an if expression, we can generate the reduction sequence for the entire expression. We simply generate all the reductions for the first derivation and plug them into the original context. We build the next context by filling the first hole with the expanded version of the first subterm, and so on. Opaque macros also act as expansion contexts. The synthetic nodes that represent opaque macros contain derivations paired with paths into the macro use’s term. The paths provide the location of the holes for the contexts, and the debugger generates steps using the subderivations just as for primitive forms. 6. Conclusion Despite the ever increasing complexity of Scheme’s syntactic abstraction system, Scheme implementations have failed to provide adequate tools for stepping through macro expansions. Beyond the technical challenges that we have surmounted to implement our macro stepper, there are additional theoretical challenges in proving its correctness. Macro expansion is a complex process that thus far lacks a simple reduction semantics. We have therefore based our macro stepper on a natural semantics, with an ad hoc translation of derivations to reduction sequences. First experiences with the alpha release of the debugger suggest that it is a highly useful tool, both for experts and novice macro developers. We intend to release the debugger to the wider Scheme community soon and expect to refine it based on the community’s feedback. Acknowledgments We thank Matthew Flatt for his help in instrumenting the PLT Scheme macro expander. References [1] Eli Barzilay. Swindle. http://www.barzilay.org/Swindle. 10 PLT Scheme macros are also allowed to partially expand their subterms and include the results in their output. Scheme and Functional Programming, 2006 25
Page 1: Scheme and Functional Programming 2
Page 4 and 5: 4 Scheme and Functional Programming
Page 6 and 7: 6 Scheme and Functional Programming
Page 8 and 9: • A web browser that plays the ro
Page 10 and 11: and requests. When a client request
Page 12 and 13: above prevents pages from these dom
Page 14 and 15: 14 Scheme and Functional Programmin
Page 16 and 17: 2. Explaining Macros Macro expansio
Page 18 and 19: For completeness, here is the macro
Page 20 and 21: onment is extended in the original
Page 22 and 23: expand-term(term, env, phase) = emi
Page 26 and 27: True derivation (before macro hidin
Page 28 and 29: We assume that the reader has basic
Page 30 and 31: the value of the %eax register by 4
Page 32 and 33: Code generation for the new forms i
Page 34 and 35: we introduced in 3.11. The only dif
Page 36 and 37: the user code from interfering with
Page 40 and 41: mization and on creating efficient
Page 42 and 43: (a) stage (b) fifo (c) split (d) me
Page 44 and 45: This tagging is used later in the c
Page 46 and 47: (let ((clo_25 (%closure (lambda (y)
Page 48 and 49: nb. cycles per element 1400 1200 10
Page 52 and 53: a ∗ ❅ left right · b ❅ a S
Page 54 and 55: T ([spec], w) = { {w}, if w ∈ L([
Page 56 and 57: A([spec]): ✓✏ (where L([spec])
Page 58 and 59: construction commands. It is possib
Page 60 and 61: ; Regular expression for Scheme num
Page 62 and 63: References [1] A. V. Aho, R. Sethi,
Page 64 and 65: (let ((n (cond ((char? var0) ) ((sy
Page 66 and 67: 3. Survey An incomplete survey of a
Page 68 and 69: case monster 10 literals 100 litera
Page 72 and 73: modest programming requirements, an
Page 74 and 75:
development of incomplete subsystem
Page 76 and 77:
the previous request. This method a
Page 78 and 79:
could be run indefinitely. This fun
Page 80 and 81:
programmers reject Scheme without r
Page 82 and 83:
(define interp (λ (env e) (case e
Page 84 and 85:
Before describing the run-time sema
Page 86 and 87:
Figure 5. Cast Insertion Figure 6.
Page 88 and 89:
Figure 7. Evaluation Figure 8. Eval
Page 90 and 91:
catching type errors, as we do here
Page 92 and 93:
[34] J. C. Reynolds. Types, abstrac
Page 94 and 95:
let id (T:*) (x:T) : T = x; The tra
Page 96 and 97:
Figure 3: Regular Expressions and N
Page 98 and 99:
Figure 5: Evaluation Rules Evaluati
Page 100 and 101:
5. Exact Substitution: E, (x = v :
Page 102 and 103:
Figure 9: Subtyping Algorithm Algor
Page 104 and 105:
for most type variables, and that m
Page 106 and 107:
2. miniKanren Overview This section
Page 108 and 109:
3. Pseudo-Variadic Relations Just a
Page 110 and 111:
Replacing run 10 with run ∗ cause
Page 112 and 113:
As might be expected, we could use
Page 114 and 115:
Of course there are still infinitel
Page 116 and 117:
To ensure that streams produced by
Page 118 and 119:
118 Scheme and Functional Programmi
Page 120 and 121:
On the other hand, we can use a hig
Page 122 and 123:
(ev* (Q (lambda (x) (+ x 1)))) # >
Page 124 and 125:
(term ’lam (lambda (x) (if (equal
Page 126 and 127:
a message: there is no guarantee th
Page 128 and 129:
(! (self) 3) (?) =⇒ 1 (?? odd?) =
Page 130 and 131:
(define new-server (spawn (lambda (
Page 132 and 133:
The abstraction shown in this secti
Page 134 and 135:
Erlang Termite List length (µs) (
Page 136 and 137:
Page 138 and 139:
page of j contains the URL of the p
Page 140 and 141:
4. Solution The failed attempts abo
Page 142 and 143:
· ; · ; · :: Store × Frame Stac
Page 144 and 145:
logically creates a sub-session of
Page 146 and 147:
on this work, including Ryan Culpep
Page 148 and 149:
ing application operation. 1 As a r
Page 150 and 151:
such as image glyphs corresponding
Page 152 and 153:
Phone For clarity, this code pr
Page 154 and 155:
A. Porting TinyScheme to Qualcomm B
Page 156 and 157:
Page 158 and 159:
ware installers have to install any
Page 160 and 161:
defines a module named circle-lib i
Page 162 and 163:
Figure 2. Sometimes special cases a
Page 164 and 165:
Considering all of these issues tog
show all

2006 Scheme and Functional Programming Papers, University of

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?