Your SlideShare is downloading. ×
Maclennan chap5-pascal
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Maclennan chap5-pascal

190
views

Published on

Published in: Education, Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
190
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. CSE 3302 Pascal (Using slides of Tom Rethard)
  • 2. Algol
    • Successful, so …
      • Use the ideas in other languages
      • Algol-like languages
        • List processing
        • String manipulation
        • Systems programming
        • Artificial Intelligence
      • Upgrades to Algol itself
  • 3. PL/I
    • A block-structured COBOL/FORTRAN union (IBM, 1967)
      • Algol block structure
      • COBOL file manipulation
      • FORTRAN syntactic style
    • “ Everything for Everyone”
    • “ The Only Programming Language You’ll Ever Need”
    • Basically, a Swiss Army knife
  • 4. PL/I
    • Characterized by Dijkstra as “a fatal disease” and “a programming language for which the defining documentation is of a frightening size and complexity. Using PL/I must be like flying a plane with 7000 buttons, switches, and handles to manipulate in the cockpit”
  • 5. Extensible Languages
    • Roll-your-own (sort of)
      • Just a language kernel
      • But capable of adding to it if necessary
      • MAD (Michigan Algorithm Decoder)
      • McIlroy’s “syntax macros”
  • 6. Simple Kernel
    • Turned out to be a good idea
    • Frequent choice was an Algol subset with more general data structuring abilities
    • Allowed generalization to an application area, built on a common foundation.
  • 7. Types of Extensions
    • Operator Extension
      • Define new, application-oriented operators
    • Example: symmetric difference (x # y)
      • operator 2 x # y; value x, y; real x,y; begin return abs(x-y) end;
      • The “2” is the precedence of the operator.
  • 8. Types of Extensions
    • Syntax macros
    • real syntax: sum from I = lb to ub of elem; value lb, ub; integer I, lb, ub; real elem; begin real s; s := 0; for I := lb step 1 until ub do s := s + elem; return s end;
    • Total := sum from k = 1 to N of Wages[k];
  • 9. Issues with Extensible languages
    • Usually inefficient
      • Tough to write a compiler for a language that is always changing!
    • Poor Diagnostics
      • The compiler really doesn’t understand what’s going on.
  • 10. Pascal
    • Designed by Niklaus Wirth
      • Previously designed
        • Algol-W (a proposed extension to ALGOL with C. A. R. Hoare)
        • Euler
        • PL360
  • 11. Pascal Goals
    • The language should be suitable for teaching programming in a systematic way.
    • The implementation of the language should be reliable and efficient, at compile-time and run-time, on available computers.
  • 12. History
    • Development started in 1968
    • First working compiler in 1970
    • Pascal-70 Report was 29 pages (cf. Algol’s 16)
    • P-Code based system in 1973
    • Spread quickly on microcomputers in the 70s & 80s
  • 13. Example
    • Program AbsMean (input, output); const Max = 900; type index = 1 .. Max; var N: 0 .. Max; Data: array [index] of real; sum, avg, val: real; i: index; …
  • 14. Example (con’t)
    • begin sum := 0; readln (N); for i := 1 to N do begin readln (val); if val < 0 then Data[i] := val else Data[i] := val end; for i := 1 to N do sum = sum + Data[i]; avg := sum/N; writeln (avg);
    • end.
  • 15. Enumerations
    • Old Way
    • begin integer today, tomorrow; integer Sun, Mon, Tue, Wed, Thu, Fri, Sat; Sun := 0; Mon := 1; Tue := 2; Wed := 3; Thu := 4; Fri := 5; Sat := 6; … today := Tue; tomorrow := today + 1; …
  • 16. Enumerations
    • Pascal Way
    • Type DayOfWeek = (Sun, Mon, Tue, Wed, Thu, Fri, Sat); Month = (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec); var today, tomorrow: DayOfWeek; begin … today := Tue; tomorrow := today + 1; … today = Jan; /* type error …
  • 17. The Enumeration ADT
    • Operations
      • :=
      • succ
      • pred
      • =
      • <>
      • <
      • >
      • <=
      • >=
    • What is succ(Sat)?
      • Undefined
    • What is pred(Nov)?
      • Oct
  • 18. Enumeration Characteristics
    • High Level and Application Oriented
    • Efficient
      • Storage
    • Secure
      • Does not allow meaningless operations
  • 19. Subrange Types
    • var DayOfMonth 1 .. 31;
    • Restricts the range of values for DayOfMonth to the integer subrange of 1..31
    • Can also use in enumerations:
    • Type WeekDay = Mon .. Fri
  • 20. Sets
    • Set of <ordinal type>
    • (enumeration type(char,Boolean),
    • subrange type)
    • Var S, T: set of 1..10;
    • S := [1, 2, 3, 5, 7];
    • T := [1 ..6];
    • If T = [1, 2, 3, 5] then …
  • 21. Set Operations
    • =
    • <>
    • <= subset or equal
    • >=
    • But: no < or > !
  • 22. Arrays
    • Any upper or lower bound
    • Can also use enumeration types as array indices
    • Examples (note base type in #2)
      • var A: array [1 .. 100] of real;
      • var HoursWorked: array [Mon .. Fri] of 0 .. 24;
  • 23. Arrays
    • Var day: Mon .. Fri; TotalHours: 0..120; begin TotalHours := 0; for day := Mon to Fri do TotalHours := TotalHours + HoursWorked[day];
  • 24. Arrays – of Characters
    • Any finite discrete type for index
    • var Occur: array [char] of integer; … Occur[ch] := Occur[ch] + 1; … if Occur[‘e’] > Occur[‘t’] then …
  • 25. More Complex Arrays
    • var M: array [1..20] of array [1 .. 100] of real; or var m: array [1 .. 20, 1 .. 100] of real;
  • 26. Arrays Issue
    • There are some problems
    • Need to be static, not dynamic
        • Must know types at compile time
        • Dimensions are part of the array type
        • Arrays are considered the same type if index types and base types both match
  • 27. Type problems
    • type vector = array [1 .. 100] of real; var U, V, vector; function sum (x: vector): real; … begin … end {sum};
    • Can write
    • var W: array [1 ..75] of real;
    • But cannot write:
    • Sum(W)
  • 28. Type Problems
    • Types of W and of x are not the same because the ranges of the indices are different!
    • This appears to be a violation of the Abstraction Principle.
  • 29. Record Types
    • Heterogeneous data
    • Multiple components
    • Various types
  • 30. Records
    • type
    • person = record name: string; age: 16 .. 100; salary: 10000 .. 100000; sex: (male, female); birthdate: date; hiredate: date; end; string = packed array [1 ..30] of char; date = record mon: month; day: 1 ..31; year: 1900 .. 2100; end; month = (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec);
  • 31. Using a Record
    • To use a record: var newhire: person; just like any other type
  • 32. Getting to the Components
    • var newhire: person; today: date; … newhire.age := 25; newhire.sex := female; newhire.date := today;
  • 33. More Possibilities
    • if newhire.name[1] = ‘A’ then …
    • type employeeNum = 1000 .. 9999; var employees: array [employeeNum] of person; EN: employeeNum;
  • 34. Making it Simpler
    • with newhire begin age := 25; sex := female; date := today end;
  • 35. Storage Groupings
    • Homogeneous
      • Arrays
      • All elements are the same type
      • Computed (dynamic) selector (subscript or index)
    • Heterogeneous
      • Records
      • Elements (components) may be of different types
      • Static selector
  • 36. Variant Records
    • Sometimes records vary from one record type to another.
    • Think of this as a primitive form of subclassing
  • 37. Variant Records
    • type plane = record flight: 0 .. 999; kind: (B727, B737, B747); status (inAir, onGround, atTerminal); altitude: 0 .. 100000; heading: 0 .. 359; arrival: time; destination: airport; location: airport; runway: runwayNumber; parked: airport; gate: 1.. 100; departure: time; end; {plane}
  • 38. What’s Wrong?
    • Not all data has meaning at the same time.
    • Can imply a plane is located at one airport and is parked at another
    • Violates security principle.
  • 39. Variant Records
    • type plane = record flight: 0 .. 999; kind: (B727, B737, B747); case status: (inAir, onGround, atTerminal); inAir:( altitude: 0 .. 100000; heading: 0 .. 359; arrival: time; destination: airport); onGround: ( location: airport; runway: runwayNumber); atTerminal: ( parked: airport; gate: 1.. 100; departure: time); end; {plane}
  • 40. Implementation flight kind status altitude heading arrival destination location runway parked gate departure
  • 41. The Dreaded Pointer
    • There is a problem with pointers and strong typing!
    • Pascal solves this problem by typing pointers
  • 42. Typed Pointers (notPascal)
    • var p: pointer; x: real; c: char; begin new(p); p^ := 3.14159; c := p^; end
  • 43. Typed Pointers (Pascal)
    • var p: ^real; x: real; c: char; begin new(p); p^ := 3.14159; c := p^; {illegal} end
  • 44. Pointers with Records
    • var p: ^plane; begin … p^.plane.parked[1] … … end;
  • 45. Type Equivalence
    • Not as clear as it could have been
    • Revised Pascal Report
      • Specifies assignments are ok if expression and variable have identical type
      • Does not define identical type
  • 46. Interpretations for equivalency
      • Structural equivalence
        • Structural descriptions of the types be the same
      • Name equivalence
        • Names must be same
  • 47. Structural Equivalence
    • var
    • x: record id: integer; weight: real end;
    • y: record id: integer; weight: real end;
    • The above are the same because their structure is the same
  • 48. But… Consider this
    • type person = record id: integer; weight: real end; car = record id: integer; weight: real end;
    • The above are the same because their structure is the same, so: car := person; according to structural equivalency is legal!
  • 49. Name Equivalence
    • var x: record id: integer; weight: real end; y: record id: integer; weight: real end;
    • Is actually ambiguous,
    • Different versions of Name Equivalence Rule differ on this example.
      • If reinterpreted as follows, then they are different
    • type
    • T00029: record id: integer; weight: real end;
    • T00030: record id: integer; weight: real end;
    • var x: T00029; y: T00030;
  • 50. Name Equivalence Issues
    • type age = 0 .. 150;
    • var n: integer; a: age;
    • Is n:= a legal?
      • Pure name equivalence says no
      • Logic says yes
      • Revised Pascal Report says that a subrange of a type is still that type
  • 51. Comparison
    • Name Equivalence generally safer
      • More restrictive
    • Name Equivalence is easier to implement
      • Simply a string comparison
      • Structural equivalence requires a recursive function
    • ISO Pascal specifies name Equivalence
  • 52. Name Structures
    • Pascal provides six types
      • Constant bindings
      • Type bindings
      • Variable bindings
      • Procedure and function bindings
      • Implicit enumeration bindings
      • Label bindings
  • 53. Constant bindings
    • const MaxData = 100;
    • MaxData can be used almost anywhere
      • All declarations
      • Executable statements (for loops, etc.)
      • Expressions
      • BUT , not in other const declarations!
        • const MaxDataMinus1 = MaxData –1; is not allowed
  • 54. Constructors
    • Record constructors
    • Procedure/Function
      • The major scope defining construct
  • 55. Procedures
    • procedure <name> (<formal arguments>); <declarations> begin <statements> end ;
  • 56. A Problem
    • procedure P (...); ... begin ...
    • Q(...) ... end ;
    • procedure Q (...); ... begin ... P(...) ... end ;
  • 57. A Problem Solved
    • procedure Q(...) forward;
    • procedure P (...); ... begin ...
    • Q(...) ... end ;
    • procedure Q (...); ... begin ... P(...) ... end ;
  • 58. Procedure Construction
    • procedure <name> (<formal arguments>); <label declarations> <const declarations> <type declarations> <var declarations> <procedure and function declarations> begin <statements> end ;
  • 59. Pascal eliminates the block
    • Simplifies name structure
    • Complicate efficient use of memory
  • 60. Control structures
    • Reflects structured programming ideas
  • 61. For Loop
    • for <name> := expression { to | downto } <expression> do <statement>
    • Simplified comparing with Algol (overreact to second generation languages)
    • Bounds of the loop are computed once, at loop entry => definite iterator
  • 62. While Loop
    • Also a “Leading Decision Indefinite Iterator”
    • while <condition> do <statement>
    • Checks at top of loop
    • Can use “while true do....” for a loop exiting from the middle (Mid-Decision Iterator)
  • 63. Repeat Loop
    • Also “Trailing Decision Indefinite Iterator”
    • repeat <statement> until <condition>
    • Checks at bottom of loop
  • 64. Unlabeled Case Statement
    • NOT Pascal – modeled according to Fortran computed goto
    • case <expression> of <statement>, <statement>, ... <statement> end case;
  • 65.
    • case I of begin ... S 1 ... end ; begin ... S 23 ... end ;
    • begin ... S 23 ... end ; begin ... S 4 ... end ; end case ;
    • No labels provided.
  • 66. Labeled Case Statement
    • Major contribution of Pascal
    • case <expression> of <case clause>; <case clause>; ... <case clause> end case;
    • Designed by C.A. Hoare: the most important of his many contributions to language design
  • 67. Labeled Case Statement
    • case I of 1: begin ... S 1 ... end ; 2: 3: begin ... S 23 ... end ; 4: begin ... S 4 ... end ; end case ;
    • Some dialects of Pascal add an otherwise case.
  • 68. The labeling principles
  • 69. Parameter Passing
    • Pass by reference
      • Replaces Algol pass by name
      • Intended to allow side effects (ie, I-O parameter usage)
      • Passes only the address
    • Pass by value
      • Intended for input only parameters
      • Side effects not allowed
      • Done by copy-in
  • 70. Pass as Constant
    • Original specification contained this instead of pass by value
    • Similar to C const parameter passing
    • Allowed compiler to pass either address or value
    • Called procedure could not modify it
    • Elimination encourages call by reference
  • 71.
    • Security advantages of value parameters
    • Efficiency advantages of reference parameters
    • But there are some security problems …
    • when aliasing
  • 72.
    • type vector=array[1..100] of real;
    • var A:vector
    • procedure P(x:vextor); *pass by constant
    • begin
    • writeln(x[1]); A[1]:=0; writeln(x[1])
    • end;
    • begin
    • P(A)
    • end;
  • 73. Pass as Constant
    • Two orthogonal issues involved
      • Should copy its value or use its address?
      • Should be I or I-O parameter
    • Approach violates the Orthogonality Principle
  • 74.
    • Write a Pascal fragment that does not use the nonlocal variables, to illustrate the security loophole in parameters passed as constants.
  • 75. Procedural Parameters: Security Loophole
    • Pascal allows passing a procedure or function name as a parameter
      • To restore some of the flexibility lost by omitting name parameters
    • Makes it difficult to determine if the function parameter is properly constructed.
  • 76.
    • Procedure difsq (function f:real; x:real):real
    • begin
    • difsq:= f(x*x) – f(-x*x)
    • end
    • difsq(sin,theta)=sin(theta^2 ) – sin(-theta^2)
  • 77.
    • The arguments of a formal procedure parameter shall be specified
    • Procedure difsq (function f(y:real):real; x:real):real
  • 78. Pascal
    • Actually has lived up to its goals
      • Teaching language
        • Reliability
        • Simplicity
        • Efficiency
      • Wirth: “the principle to include features that were well understood, in particular by implementors, and to leave out those that were still untried and unimplemented, proved to be the most successful single guideline.”
  • 79. Extensions
    • Basis for most modern language design
      • One step past Algol
    • Multiple offshoots:
      • Concurrent Pascal
      • Mesa
      • Euclid
      • Modula-2 (by Wirth)
  • 80. Systems Languages
    • Subsets of PL/I
    • PL/S
    • PL/360
    • PL/M
    • XPL
    • TI Pascal and MPP
  • 81. BCPL
    • Basic CPL
      • Simplified version of CPL – Cambridge Plus London
      • Became popular in the early 70s
    • B
      • Ken Thompson, 1969-70
      • “ BCPL squeezed into 8K of memory and filtered through Thompson’s brain”
      • UNIX on PDP-7
      • Extreme weak typing (only 1 data type!)
      • More like Assembly Language
  • 82. From B We Got
    • C
      • PDP-11 arrived
      • Problem with B’s addressing scheme discovered
      • Dennis M Ritchie started by extending B to contain basic data types (but no type checking)
      • Unions and enumerations added later, but still no type checking
      • Serious problems in porting UNIX to other platforms, so lint (a separate type checker) used to check types
  • 83. C
    • Language attempted to maintain compatibility with older B language
    • The C Programming Language by K&R 1978
    • ANSI Standard C
      • Began 1983
      • Approved 1989
    • Permitted spread within universities and research organizations
    • Also used as the output language for many compilers.
  • 84. C Generational Characteristics
    • 1 st Generation
      • No nested procedures
      • Poor support for modular programming
    • 2 nd Generation
      • Low-level model of arrays and pointers
    • 3 rd Generation
      • Hierarchical data structures
  • 85. C According to Ritchie
    • “ C is quirky, flawed, and an enormous success”
    • Suggests success attributed to
      • Simplicity
      • Efficiency
      • Portability
      • Closeness to the machine
      • Evolution in an environment in which it was used to write practical programs
  • 86. 3 rd Generation Language
    • Emphasis on simplicity and efficiency
    • Data structures
      • Shift emphasis from machine to application
      • Application-oriented constructors: sets, subranges, enumerations
    • Name structures
      • Simplification of Algol’s
      • Add new new binding and scope-defining constructs
    • Control structures
      • Simplified, efficient versions of the 2 nd generation
      • Some new structures, such as a real case
  • 87. Exercises
    • 5-1
    • 5-4
    • 5-8
    • 5-14
    • 5-15
    • 5-17
    • 5-20
    • 5-25
    • 5-26

×