2006 Scheme and Functional Programming Papers, University of

More documents

Recommendations

Info

True derivation (before macro hiding): ∆ p, E ′ ⊢ e1 ⇓ e1 ′ · · · p, E ⊢ (let/cc k e1 ) → (call/cc (lambda (k) e1 )) p, E ⊢ (call/cc (lambda (k) e1 )) ⇓ expr ′ p, E ⊢ (let/cc k e1 )) ⇓ expr ′ Synthetic derivation (after macro hiding): 〈 (-- -- []), 〉 ∆ p, E ′ ⊢ e1 ⇓ e1 ′ p, E ⊢ (let/cc k e1 ) ⇓ h (let/cc k e1 ′ ) Figure 13. Macro hiding [2] Ana Bove and Laura Arbilla. A confluent calculus of macro expansion and evaluation. In Proc. 1992 ACM Conference on LISP and Functional Programming, pages 278–287, 1992. [3] John Clements, Matthew Flatt, and Matthias Felleisen. Modeling an algebraic stepper. In Proc. 10th European Symposium on Programming Languages and Systems, pages 320–334, 2001. [4] William Clinger and Jonathan Rees. Macros that work. In ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 155–162, 1991. [5] Ryan Culpepper, Scott Owens, and Matthew Flatt. Syntactic abstraction in component interfaces. In Proc. Fourth International Conference on Generative Programming and Component Engineering, pages 373–388, 2005. [6] R. Kent Dybvig, Robert Hieb, and Carl Bruggeman. Syntactic abstraction in Scheme. Lisp and Symbolic Computation, 5(4):295– 326, December 1993. [7] Sebastian Egner. Eager comprehensions in scheme: The design of srfi-42. In Proc. Sixth Workshop on Scheme and Functional Programming, September 2005. [8] Matthias Felleisen. Transliterating Prolog into Scheme. Technical Report 182, Indiana University, 1985. [9] Matthias Felleisen. On the expressive power of programming languages. Science of Computer Programming, 17:35–75, 1991. [10] Robert Bruce Findler, John Clements, Cormac Flanagan, Matthew Flatt, Shriram Krishnamurthi, Paul Steckler, and Matthias Felleisen. DrScheme: A programming environment for Scheme. Journal of Functional Programming, 12(2):159–182, 2002. [11] Matthew Flatt. Composable and compilable macros: you want it when? In Proc. Seventh ACM SIGPLAN International Conference on Functional Programming, pages 72–83, 2002. [12] Matthew Flatt. PLT MzScheme: Language manual. Technical Report PLT-TR2006-1-v352, PLT Scheme Inc., 2006. http://www.plt-scheme.org/techreports/. [13] Matthew Flatt and Matthias Felleisen. Units: Cool modules for HOT languages. In Proc. ACM SIGPLAN 1998 Conference on Programming Language Design and Implementation, pages 236– 248, 1998. [14] Daniel Friedman. Object-oriented style. In International LISP Conference, October 2003. Invited talk. [15] Daniel P. Friedman, William E. Byrd, and Oleg Kiselyov. The Reasoned Schemer. The MIT Press, July 2005. [16] Martin Gasbichler. Fully-parameterized, First-class Modules with Hygienic Macros. PhD thesis, Eberhard-Karls-Universität Tübingen, February 2006. [17] David Herman and Philippe Meunier. Improving the static analysis of embedded languages via partial evaluation. In Proc. Ninth ACM SIGPLAN International Conference on Functional Programming, pages 16–27, 2004. [18] Paul Hudak. Building domain-specific embedded languages. ACM Comput. Surv., 28(4es):196, 1996. [19] Richard Kelsey, William Clinger, and Jonathan Rees (Editors). Revised 5 report of the algorithmic language Scheme. ACM SIGPLAN Notices, 33(9):26–76, 1998. [20] Oleg Kiselyov. A declarative applicative logic programming system, 2004–2006. http://kanren.sourceforge.net. [21] Eugene Kohlbecker, Daniel P. Friedman, Matthias Felleisen, and Bruce Duba. Hygienic macro expansion. In Proc. 1986 ACM Conference on LISP and Functional Programming, pages 151–161, 1986. [22] Henry Lieberman. Steps toward better debugging tools for lisp. In Proc. 1984 ACM Symposium on LISP and Functional Programming, pages 247–255, 1984. [23] Scott Owens, Matthew Flatt, Olin Shivers, and Benjamin McMullan. Lexer and parser generators in scheme. In Proc. Fifth Workshop on Scheme and Functional Programming, pages 41–52, September 2004. [24] PLT. PLT MzLib: Libraries manual. Technical Report PLT-TR2006- 4-v352, PLT Scheme Inc., 2006. http://www.plt-scheme.org/techreports/. [25] Dipanwita Sarkar, Oscar Waddell, and R. Kent Dybvig. A nanopass infrastructure for compiler education. In Proc. Ninth ACM SIGPLAN International Conference on Functional Programming, pages 201– 212, 2004. [26] Olin Shivers. The anatomy of a loop: a story of scope and control. In Proc. Tenth ACM SIGPLAN International Conference on Functional Programming, pages 2–14, 2005. [27] Dorai Sitaram. Programming in schelog. http://www.ccs.neu.edu/home/dorai/schelog/schelog. html. [28] Guy L. Steele, Jr. Common LISP: the language (2nd ed.). Digital Press, 1990. [29] Andrew P. Tolmach and Andrew W. Appel. A debugger for Standard ML. Journal of Functional Programming, 5(2):155–200, 1995. [30] Oscar Waddell and R. Kent Dybvig. Extending the scope of syntactic abstraction. In Proc. 26th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 203–215, 1999. [31] Mitchell Wand. The theory of fexprs is trivial. Lisp and Symbolic Computation, 10(3):189–199, 1998. [32] Andrew Wright and Bruce Duba. Pattern matching for scheme, 1995. 26 Scheme and Functional Programming, 2006
An Incremental Approach to Compiler Construction Abdulaziz Ghuloum Department of Computer Science, Indiana University, Bloomington, IN 47408 aghuloum@cs.indiana.edu Abstract Compilers are perceived to be magical artifacts, carefully crafted by the wizards, and unfathomable by the mere mortals. Books on compilers are better described as wizard-talk: written by and for a clique of all-knowing practitioners. Real-life compilers are too complex to serve as an educational tool. And the gap between real-life compilers and the educational toy compilers is too wide. The novice compiler writer stands puzzled facing an impenetrable barrier, “better write an interpreter instead.” The goal of this paper is to break that barrier. We show that building a compiler can be as easy as building an interpreter. The compiler we construct accepts a large subset of the Scheme programming language and produces assembly code for the Intel-x86 architecture, the dominant architecture of personal computing. The development of the compiler is broken into many small incremental steps. Every step yields a fully working compiler for a progressively expanding subset of Scheme. Every compiler step produces real assembly code that can be assembled then executed directly by the hardware. We assume that the reader is familiar with the basic computer architecture: its components and execution model. Detailed knowledge of the Intel-x86 architecture is not required. The development of the compiler is described in detail in an extended tutorial. Supporting material for the tutorial such as an automated testing facility coupled with a comprehensive test suite are provided with the tutorial. It is our hope that current and future implementors of Scheme find in this paper the motivation for developing high-performance compilers and the means for achieving that goal. Categories and Subject Descriptors D.3.4 [Processors]: Compilers; K.3.2 [Computer and Information Science Education]: Computer science education Keywords Scheme, Compilers 1. Introduction Compilers have traditionally been regarded as complex pieces of software. The perception of complexity stems mainly from traditional methods of teaching compilers as well as the lack of available examples of small and functional compilers for real languages. Compiler books are polarized into two extremes. Some of them focus on “educational” toy compilers while the others focus on “industrial-strength” optimizing compilers. The toy compilers are Proceedings of the 2006 Scheme and Functional Programming Workshop University of Chicago Technical Report TR-2006-06 too simplistic and do not prepare the novice compiler writer to construct a useful compiler. The source language of these compilers often lacks depth and the target machine is often fictitious. Niklaus Wirth states that “to keep both the resulting compiler reasonably simple and the development clear of details that are of relevance only for a specific machine and its idiosyncrasies, we postulate an architecture according to our own choice”[20]. On the other extreme, advanced books focus mainly on optimization techniques, and thus target people who are already well-versed in the topic. There is no gradual progress into the field of compiler writing. The usual approach to introducing compilers is by describing the structure and organization of a finalized and polished compiler. The sequencing of the material as presented in these books mirrors the passes of the compilers. Many of the issues that a compiler writer has to be aware of are solved beforehand and only the final solution is presented. The reader is not engaged in the process of developing the compiler. In these books, the sequential presentation of compiler implementation leads to loss of focus on the big picture. Too much focus is placed on the individual passes of the compiler; thus the reader is not actively aware of the relevance of a single pass to the other passes and where it fits in the whole picture. Andrew Appel states that “a student who implements all the phases described in Part I of the book will have a working compiler”[2]. Part I of Appel’s book concludes with a 6-page chapter on “Putting it all together” after presenting 11 chapters on the different passes of Tiger. Moreover, practical topics such as code generation for a real machine, interfacing to the operating system or to other languages, heap allocation and garbage collection, and the issues surrounding dynamic languages are either omitted completely or placed in an appendix. Muchnick states that “most of the compiler material in this book is devoted to languages that are well suited for compilation: languages that have static, compile-time type systems, that do not allow the user to incrementally change the code, and that typically make much heavier use of stack storage than heap storage”[13]. 2. Preliminary Issues To develop a compiler, there are a few decisions to be made. The source language, the implementation language, and the target architecture must be selected. The development time frame must be set. The development methodology and the final goal must be decided. For the purpose of our tutorial, we made the decisions presented below. 2.1 Our Target Audience We do not assume that the reader knows anything about assembly language beyond the knowledge of the computer organization, memory, and data structures. The reader is assumed to have very limited or no experience in writing compilers. Some experience with writing simple interpreters is helpful, but not required. 27
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 24 and 25: Derivation ::= (make-mrule Syntax S
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

Create successful ePaper yourself

Delete template?

Save as template?