2006 Scheme and Functional Programming Papers, University of

More documents

Recommendations

Info

programmers reject Scheme without realizing how much more it can offer. We can gain much more utility from Scheme, even though the basics have contributed so positively. However, deciding where to spend development time is becoming more difficult. Significant wisdom is needed to understand the relationships between Scheme staples like modules, units, macros, and languages. Such knowledge is essential to the development of formal laboratory tools that could safely be used by people with diverse capabilities. An experienced computer scientist could contribute significantly to these efforts, but personnel in laboratories like ours need to be convinced that computer science can provide more than just programmers and compilers. 9. Future Effort Future effort will include developing formal language layers for the controllers and experiments. Common functions have already been adopted, so a few layers of modules should guarantee common behavior. Automatic optimization of servos and automatic calibration of gimbals pointing are also planned. While tracking stars and satellites, a Scheme program could observe control loop behavior and pointing corrections. From these observations, it could then update servo parameters and pointing models. These tasks are currently done manually. References [1] R. Q. Fugate, Air Force Phillips Lab; et. al. Two Generations of Laser Guidestar Adaptive Optics at the Starfire Optical Range. Journal of the Optical Society of America A II, 310-314 1994 [2] Matt Sottile, sexpr.sourceforge.net [3] Matthew Flatt, Inside PLT Scheme 206.1 [4] Felleisen, Findler, Flatt, Krishnamurthi, How to Design Programs, MIT Press, Section 12.1 80 Scheme and Functional Programming, 2006
Gradual Typing for Functional Languages Jeremy G. Siek University of Colorado siek@cs.colorado.edu Walid Taha Rice University taha@rice.edu Abstract Static and dynamic type systems have well-known strengths and weaknesses, and each is better suited for different programming tasks. There have been many efforts to integrate static and dynamic typing and thereby combine the benefits of both typing disciplines in the same language. The flexibility of static typing can be improved by adding a type Dynamic and a typecase form. The safety and performance of dynamic typing can be improved by adding optional type annotations or by performing type inference (as in soft typing). However, there has been little formal work on type systems that allow a programmer-controlled migration between dynamic and static typing. Thatte proposed Quasi-Static Typing, but it does not statically catch all type errors in completely annotated programs. Anderson and Drossopoulou defined a nominal type system for an object-oriented language with optional type annotations. However, developing a sound, gradual type system for functional languages with structural types is an open problem. In this paper we present a solution based on the intuition that the structure of a type may be partially known/unknown at compiletime and the job of the type system is to catch incompatibilities between the known parts of types. We define the static and dynamic semantics of a λ-calculus with optional type annotations and we prove that its type system is sound with respect to the simply-typed λ-calculus for fully-annotated terms. We prove that this calculus is type safe and that the cost of dynamism is “pay-as-you-go”. Categories and Subject Descriptors D.3.1 [Programming Languages]: Formal Definitions and Theory; F.3.3 [Logics and Meanings of Programs]: Studies of Program Constructs— Type structure General Terms Keywords 1. Introduction Languages, Performance, Theory static and dynamic typing, optional type annotations Static and dynamic typing have different strengths, making them better suited for different tasks. Static typing provides early error detection, more efficient program execution, and better documentation, whereas dynamic typing enables rapid development and fast adaptation to changing requirements. The focus of this paper is languages that literally provide static and dynamic typing in the same program, with the programmer control- Proceedings of the 2006 Scheme and Functional Programming Workshop University of Chicago Technical Report TR-2006-06 ling the degree of static checking by annotating function parameters with types, or not. We use the term gradual typing for type systems that provide this capability. Languages that support gradual typing to a large degree include Cecil [8], Boo [10], extensions to Visual Basic.NET and C# proposed by Meijer and Drayton [26], and extensions to Java proposed by Gray et al. [17], and the Bigloo [6, 36] dialect of Scheme [24]. The purpose of this paper is to provide a type-theoretic foundation for languages such as these with gradual typing. There are numerous other ways to combine static and dynamic typing that fall outside the scope of gradual typing. Many dynamically typed languages have optional type annotations that are used to improve run-time performance but not to increase the amount of static checking. Common LISP [23] and Dylan [12, 37] are examples of such languages. Similarly, the Soft Typing of Cartwright and Fagan [7] improves the performance of dynamically typed languages but it does not statically catch type errors. At the other end of the spectrum, statically typed languages can be made more flexible by adding a Dynamic type and typecase form, as in the work by Abadi et al. [1]. However, such languages do not allow for programming in a dynamically typed style because the programmer is required to insert coercions to and from type Dynamic. A short example serves to demonstrate the idea of gradual typing. Figure 1 shows a call-by-value interpreter for an applied λ-calculus written in Scheme extended with gradual typing and algebraic data types. The version on the left does not have type annotations, and so the type system performs little type checking and instead many tag-tests occur at run time. As development progresses, the programmer adds type annotations to the parameters of interp, as shown on the right side of Figure 1, and the type system provides more aid in detecting errors. We use the notation ? for the dynamic type. The type system checks that the uses of env and e are appropriate: the case analysis on e is fine and so is the application of assq to x and env. The recursive calls to interp also type check and the call to apply type checks trivially because the parameters of apply are dynamic. Note that we are still using dynamic typing for the value domain of the object language. To obtain a program with complete static checking, we would introduce a datatype for the value domain and use that as the return type of interp. Contributions We present a formal type system that supports gradual typing for functional languages, providing the flexibility of dynamically typed languages when type annotations are omitted by the programmer and providing the benefits of static checking when function parameters are annotated. These benefits include both safety and performance: type errors are caught at compile-time and values may be stored in unboxed form. That is, for statically typed portions of the program there is no need for run-time tags and tag checking. We introduce a calculus named λ ? → and define its type system (Section 2). We show that this type system, when applied to fully an- 81
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 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 38 and 39: 38 Scheme and Functional Programmin
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 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:
136 Scheme and Functional Programmi
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:
156 Scheme and Functional Programmi
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?