1 / 49

The Evolution of Programming Languages

The Evolution of Programming Languages. Day 1 Lecturer : Xiao Jia xjia@cs.sjtu.edu.cn. In order to …. Understand why PLs are as they are today Predict how they might develop in the future. If this course is successful …. What is a good PL?

asha
Télécharger la présentation

The Evolution of Programming Languages

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. The Evolution of Programming Languages Day 1 Lecturer: Xiao Jia xjia@cs.sjtu.edu.cn The Evolution of PLs

  2. In order to … • Understand why PLs are as they are today • Predict how they might develop in the future The Evolution of PLs

  3. If this course is successful … • What is a good PL? • How should we choose an appropriate PL for a particular task? • How should we approach the problem of designing a PL? The Evolution of PLs

  4. Anomalies The Evolution of PLs

  5. Anomalies • Programs that look as if they ought to work but don’t • Programs that look as if they shouldn’t work but do The Evolution of PLs

  6. Example: Assignments • v := E • v is a variable • E is an expression • a[i] := E • r.f := E • v := top(stack) // get the top • CANNOT: • top(stack) := 6 // replace the top The Evolution of PLs

  7. Exercise • top(stack) := 6; • Explain why the asymmetry exists. • Can you see any problems that might be encountered in implementing a function like top? The Evolution of PLs

  8. Example: Parameters & Results • PLs are fussy about the kinds of objects that can be • (i) passed as parameters to a function, or • (ii) returned as results by a function The Evolution of PLs

  9. Example: Parameters & Results • C: • an array can be passed to a function (only by reference) • a function cannot return an array The Evolution of PLs

  10. Example: Parameters & Results • Pascal: • Arrays can be passed to a function • (i) either by value • (ii) or by reference • A function cannot return an array The Evolution of PLs

  11. Example: Parameters & Results • Most PLs do NOT allow types to be passed as parameters • void sort (type t, t a[]) { … } • sort(float, scores) The Evolution of PLs

  12. Exercise • Suppose you added types as parameters to a language • What other changes would you have to make to the language? The Evolution of PLs

  13. Exercise • C++ provides templates • Is it equivalent to having types as parameters? The Evolution of PLs

  14. Example: Data Structures and Files • (Conceptually) There is NOT a great deal of difference between a DS and a file • (Accidentally) DS’s live in memory and files live in a disk • PLs treat DS’s and files in completely different ways B+ Tree on disk The Evolution of PLs

  15. Exercise • Explain why most PLs treat DS’s and files differently The Evolution of PLs

  16. Example: Arrays • C/Pascal: size is fixed at compile-time • Algol 60: size is not fixed until run-time • (Algol is even older than C and Pascal) • What difference does this make to • (i) the implementer of the PL • (ii) the programmers who use the PL The Evolution of PLs

  17. Example: Arrays • 2D array: a • Access a component: a[i,j] (or a[i][j] in C) • Access a row: a[i] • Access a column: a[,j] • Why can’t we do this in C/Pascal? The Evolution of PLs

  18. Example: Arrays • Easy to declare rectangular arrays in most PLs • Why no provision for … arrays? • (i) triangular • (ii) symmetric • (iii) banded • (iv) sparse The Evolution of PLs

  19. Exercise • Suggest ways of declaring … arrays • (i) triangular • (ii) symmetric • (iii) banded • (iv) sparse The Evolution of PLs

  20. Example: DS’s and Functions • Pascal/C provide data aggregation • (i) record in Pascal • (ii) struct in C • A record looks like a small program • (i) it contains data declarations • (ii) cannot contain function declarations The Evolution of PLs

  21. Exercise • Suggest some applications for records with both data and function components The Evolution of PLs

  22. Example: Memory Management char *money (intamt) { char buf[16]; sprintf(buf, “%d.%d”, amt/100, amt%100); return buf; } The Evolution of PLs

  23. Exercise • What’s wrong with the function money ? • Why is it difficult for a C function to return a string? The Evolution of PLs

  24. Example: Factoring • In algebra:A x + B x  (A + B) x • In PLs:z = A * x + B * x;  z = (A + B) * x; The Evolution of PLs

  25. Example: Factoring • Most PLs:if (x > PI) y = sin(x) else y = cos(x) • A few PLs:y = if (x > PI) then sin(x) else cos(x); • Very few PLs:y = (if (x > PI) then sin else cos)(x); The Evolution of PLs

  26. Example: Returning Functions • Suppose we allow this: typedefintintint(int); intintaddk (int k) { int f (int n) { return n + k; } return f; } int add6 (int) = addk(6); printf(“%d”, add6(4)); The Evolution of PLs

  27. Exercise • It would be fairly easy to change C so that a function could return a function. The Evolution of PLs

  28. Exercise • It would be fairly easy to change C so that a function could return a function. • TRUE or FALSE ? The Evolution of PLs

  29. Exercise • It would be fairly easy to change C so that a function could return a function. • TRUE or FALSE ? • You can represent the function itself by a pointer to its first instruction. The Evolution of PLs

  30. Example: Functions as Values if (x > PI) f = sin else f = cos; f(x); The Evolution of PLs

  31. Exercise if (x > PI) f = sin else f = cos; f(x); • Why are statements like this permitted in C (with appropriate syntax) but not in Pascal? The Evolution of PLs

  32. Example: Constraint Functions • The function Add(x,y,z) attempts to satisfy the constraint x+y=z • Add(2,3,n) assigns 5 to n • Add(m,3,5) assigns 2 to m The Evolution of PLs

  33. Example: Logic Computation • It would be convenient if we could encode logical assertions forall (inti = 1; i < N; i++) a[i-1] < a[i] exists (inti = 0; i < N; i++) a[i] == k Is it convenient? Find an application? The Evolution of PLs

  34. Example: Implicit Looping • It is well known that … • we can rewrite programs with loops as programs using recursive functions • (?) eliminate the recursion as well The Evolution of PLs

  35. Example: Implicit Looping • Eliminate the recursion: typedef TYPE … intfac (int n, TYPE f) { if (n <= 1) return 1; else return n * f(n-1, f); } printf(“%d”, fac(3, fac)); The Evolution of PLs

  36. Example: Implicit Looping • Eliminate the recursion fac(3,fac) = 3 * fac(2,fac) = 3 * 2 * fac(1,fac) = 3 * 2 * 1 = 6 The Evolution of PLs

  37. Exercise typedef TYPE … intfac (int n, TYPE f) { if (n <= 1) return 1; else return n * f(n-1, f); } printf(“%d”, fac(3, fac)); • Complete the definition of TYPE HOMEWORK The Evolution of PLs

  38. PLs affect the way we think • It would not occur to most programmers to write programs in the style of the preceding sectionsbecausemost PLs do NOT permit these constructions The Evolution of PLs

  39. Theoretical Issues The Evolution of PLs

  40. Syntactic & Lexical Issues • Fact: C++ is not context-free • Exercise: • Give examples to demonstrate the difficulties that the C++ preprocessor causes in a program development environment HOMEWORK The Evolution of PLs

  41. Semantics • Axiomatic • Denotational • Operational The Evolution of PLs

  42. Type Theory • A function declaration: • T f(S x) { B; return y; } • If there’s a type theory associated with the PL, we should be able to prove a theorem: • If x has type S then the evaluation of f(x) yields a value of type T. The Evolution of PLs

  43. Type Theory • Theorem: If x has type S then the evaluation of f(x) yields a value of type T. • If we can do this for all legal programs in language L, then L is statically typed The Evolution of PLs

  44. Type Theory • If L is indeed statically typed: • (i) A compiler for L can check the type correctness of all programs. • (ii) A program that is type-correct will not fail because of a type error when it is executed The Evolution of PLs

  45. Exercise • Give an example of an expression or statement in Pascal or C that contains a type error that the compiler cannot detect. HOMEWORK The Evolution of PLs

  46. Regular Languages • sequence • choice • repetition The Evolution of PLs

  47. REs and Control Structures The Evolution of PLs

  48. REs and Data Structures The Evolution of PLs

  49. still more … • come back tomorrow The Evolution of PLs

More Related