1. CS 152: Programming Language Paradigms February 10 Class Meeting Department of Computer Science San Jose State University Spring 2014 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 2 FORTRAN IV Syntax  What is the output of this program? I = 0 SUM = 0.O DO 10 I=1,5 10 SUM = SUM + I WRITE (6, 20) SUM 20 FORMAT ('THE SUM IS ', F5.2) PAUSE STOP END

3. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 3 FORTRAN IV Syntax, cont’d  FORTRAN IV had no reserved words!  What is the output of this program? I = 0 DO = 0.O DO 10 I=1,5 10 DO = DO + I WRITE (6, 20) DO 20 FORMAT ('THE SUM IS ', F5.2) PAUSE STOP END

4. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 4 FORTRAN IV Syntax, cont’d  Spaces within a FORTRAN IV statement were ignored, except inside of a character string. In fact, spaces were optional!  What is the output of this program? I=0 DO=0.O DO10I=1,5 10 DO=DO+I WRITE(6,20)DO 20 FORMAT('THE SUM IS ',F5.2) PAUSE STOP END

5. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 5 FORTRAN IV Syntax, cont’d  What is the output of this program?  What enabled this programming error? Lack of reserved words. Spaces are not used to delimit keywords. Variable declarations are optional. I=0 DO=0.O DO10I=1.5 10 DO=DO+I WRITE(6,20)DO 20 FORMAT('THE SUM IS ',F5.2) PAUSE STOP END DO10I is a real variable set to value 1.5

6. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 6 Regularity  Regularity refers to how well the features of a language are integrated.  Greater regularity implies: Fewer restrictions on the use of particular constructs. Fewer strange interactions between constructs. Fewer surprises in general in the way the language features behave.  Languages that satisfy the criterion of regularity are said to adhere to the Principle of Least Astonishment. _

7. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 7 Regularity, cont’d  Regularity involves three concepts: Generality Orthogonal design Uniformity  Otherwise classify a feature or construct as irregular. _

8. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 8 Causes of Irregularities  Many irregularities are case studies in the difficulties of language design. Example: The extra semicolon problem in C++ was a byproduct of the need to be compatible with C. Example: The irregularity of primitive types and reference types in Java is the result of the designer’s concern with efficiency.  Do not to focus too much on a particular goal. Example: Algol 68 met its goals of generality and orthogonality, but this led to an obscure and complex language.  For a sample Algol 68 program, see https://www2.informatik.uni- erlangen.de/staff/schneider/gesch-bsp/Ex-Algol68.pdf _https://www2.informatik.uni- erlangen.de/staff/schneider/gesch-bsp/Ex-Algol68.pdf

9. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 9 Example Algol 68 Procedure

10. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 10 Security  Closely related to reliability. Discourages programming errors. Allows errors to be discovered and reported.  Reliability can be affected if restrictions are not imposed on certain features.  Example: Pointers Pascal: Pointers are restricted to point to objects of specific types and are therefore very safe. Java: Pointers are implicit and very safe. C: Pointers are less restricted but prone to misuse and errors, especially with pointer arithmetic. _ FORTRAN IV was not a very secure language!

11. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 11 Security, cont’d  Types, type-checking, and variable declarations resulted from a concern for security.  Exclusive focus on security can compromise the expressiveness and conciseness of a language Don’t force the programmer to laboriously specify as many things as possible in the code.  A semantically safe language prevents a programmer from compiling or executing any statements or expressions that violate the language definition. Example: Java incompatible types  Caught at compile time or at run time. _

12. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 12 Extensibility  An extensible language allows the programmer to add features to it. Example: Define new data types and new operations in the form of functions or procedures. Example: New releases of the language extend the built-in features of the language, such as Java’s collection classes.  Very few languages allow additions to their syntax and semantics. Example: Lisp allows new syntax and semantics via a macro.  macro: A piece of code that expands to some standard code at compile time. _

13. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 13 Computational Paradigms  Recall the different computational paradigms: Functional  Lisp, Scheme, ML, Haskell, F# Logic  Prolog Object-oriented  Java, C++  These languages evolved to support their paradigms. Each language is based on a model of computation that is different from the von Neumann model. _

14. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 14 Functional Programming  Provides a uniform view of programs as functions.  Treats functions as data.  Prevents side effects.  Simpler semantics.  A simpler model of computation suited for Rapid prototyping Artificial intelligence (AI) applications Mathematical proof systems Logic applications _

15. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 15 Functional Programming, cont’d  Today, functional languages are very attractive for general programming. They lend themselves very well to parallel execution. They may be more efficient than imperative languages on multicore hardware architectures. Their application libraries have grown more mature.  Functional programming has strong mechanisms to control complexity and to structure code. However, they are more abstract and mathematical. Not as easily mastered by the majority of programmers. _

16. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 16 Functional Programming, cont’d  Functional programming techniques have become part of many more common programming languages. Recursion Functional abstraction Higher-order functions  Today, you can choose a functional language to implement a complex system. Example: A Web application  You get: Short development time. Clear, concise code. Predictable runtime behavior.

17. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 17 Programs as Functions  Consider a program to be a “black box” that transforms some input data into output results.  Recall that in mathematics, a function f is a rule that associates a value x from some set X of values, with a unique value y from some set Y of values: y = f (x) f : X  Y Set X is the domain of the function. Set Y is the range of the function. Variable x is the independent variable of the function. Variable y is the dependent variable of the function. or:

18. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 18 Programs as Functions, cont’d  A functional definition describes how a value is to be computed using its formal parameters. Formal parameters: Parameters specified in the function definition.  A functional application is a call to a defined function using actual parameters. Actual parameters: Parameters passed by the call to the function. During a call, the formal parameters of the function assume the values of the corresponding actual parameters. _

19. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 19 Variables: Imperative Language vs. Math  Imperative programming language Example: FORTRAN  A variable represents a memory location that can store a value.  An assignment statement stores a new value into the memory location represented by a variable.  Mathematics A variable always represents a value. There is no concept of memory locations or assignments Meaningless statement in mathematics: x = x + 1 _

20. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 20 Variables: Imperative Language vs. Math, cont’d  Functional language A variable is bound to a value, not a memory location.  The mathematical notion of a variable. Once a variable is bound to a value, the variable’s value cannot change. Eliminate assignment as an available operation. A purely functional program takes a strict mathematical approach to variables. It does not use variables and assignments as would a program in an imperative language.  Without assignments, loops are impossible. Loops require control variables. Replace looping with recursion.

21. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 21 Programs as Functions, cont’d

22. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 22 Programs as Functions, cont’d  The recursive program form of gcd is closer to its mathematical definition:  There is no notion of the internal state of a function. Its value depends only on the values of its arguments (and possibly nonlocal variables).  A function’s value cannot depend on the order of evaluation of its arguments. An advantage for concurrent applications. _ gcd(u, v) = uif v = 0 gcd(v, u mod v)otherwise { if (v == 0) return u; else return gcd(v, u%v)

23. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 23 Referential Transparency  Referential transparency: A function’s value depends only on the values of its variables (and possibly nonlocal variables). Examples:  The gcd function is referentially transparent.  The random number rand function is not because it depends on the state of the machine and on previous calls to itself.  Referential transparency and the lack of assignment make the semantics straightforward. _

24. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 24 Lack of State  Lack of local state in functional programming makes it the opposite of object-oriented programming.  Object-oriented programming Computation proceeds by changing the local state of objects. _

25. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 25 First-Class Data Objects  In a functional language, a function is a first-class data object.  You can manipulate functions in arbitrary ways. No restrictions Orthogonality  A function is itself a value. Pass a function as a parameter to another function. Return a function as a value of another function. _

26. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 26 Higher-Order Functions  Higher-order function: A function that Has parameters that are themselves functions, or Produces a function as its return value. Or both.  Composition: An operation where a function Takes two functions as parameters. Produces another function as its return value. Similar to the mathematics composition operator ○ If f : X  Y and g : Y  Z, then g ○ f : X  Z is ( g ○ f )(x) = g( f(x) )

27. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 27 Lisp  Developed in the late 1950s and early 1960s. Team led by John McCarthy at M.I.T. Based on the lambda calculus of mathematician Alonzo Church.  First language that embodied features of modern functional languages. Uniform representation of programs and data using a single general list structure. Language definition using an interpreter written in the same language. Automatic memory management by the runtime system.  Garbage collection “Metaprogramming”  To be defined later.

28. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 28 Lisp, cont’d  Lisp was designed to manipulate symbols rather than numbers. People think mostly in terms of symbols. Lisp is popular in the field of artificial intelligence. _

29. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 29 Lisp, cont’d  Two major dialects of Lisp. Common Lisp  Developed by a committee in the early 1980s. Scheme  Developed by a group at M.I.T. in the mid 1970s.  We will use Scheme in this class. Download and install the free Petite Chez Scheme interpreter and development environment: http://www.scheme.com/http://www.scheme.com/ Good Scheme tutorial: http://www.ccs.neu.edu/home/dorai/t-y- scheme/t-y-scheme-Z-H-1.htmlhttp://www.ccs.neu.edu/home/dorai/t-y- scheme/t-y-scheme-Z-H-1.html

30. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 30 Scheme is a Simple Language  A rough estimate of the complexity of a programming language is the number of pages in its standard. Curious: This table is bracketed (parenthesized?) by two dialects of Lisp. _ Common Lisp> 1000 COBOL810 FORTRAN 77430 Ada340 C220 Pascal120 Scheme50

31. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 31 Scheme Language Elements  All programs and data in Scheme are expressions. Two types of expressions: atoms and lists  Atom Lowest level element Constant (number, string, character, boolean) Symbols (identifiers)  List One or more expressions separated by spaces. All surrounded by a set of parentheses. _

32. SJSU Dept. of Computer Science Fall 2014: February 10 CS 152: Programming Language Paradigms © R. Mak 32 Scheme Language Elements  Atoms  Lists 42 an integer value 2.1 a real value alpha a symbol "hello" a string value #\a the character ‘a’ #T the Boolean value true (2.1 2.2 2.3) a list of real numbers (+ 2 3) a list of the symbol + and two integers (* (+ 1 2) (- 3 4)) a list containing two sublists