10. Language Paradigms

1. 10. Language Paradigms • Programming languages. • Language paradigms. • World view of imperative languages. • World view of functional languages. • World view of relational languages. • Imperative vs. Declarative world views. • Referential transparency. • Genealogy of programming languages.

2. Programming Languages • What is a programming language? • A language for instructing a computer to solve a problem. • Basic requirements for a programming language : • Universal : Turing machine equivalent. • Natural : Suited to solving the problems we want solved. • Implementable : Can be executed on a computer. • Efficient : Isn’t too slow or too memory hungry to be useful.

3. Basic Characteristics Of Programming Languages • Syntax : • Grammar rules. • How to construct a valid program. • Semantics : • Meaning rules. • What a valid program will do when run. • Languages with similar syntax can have very different semantics (and vice versa). • C vs Java. • SQL vs. PROLOG. • SISAL vs. Haskell. • Style of semantics defines paradigm of language.

4. Declarative Paradigms Major Language Paradigms • Paradigm º type. • Each of the major paradigms is based on one of the mathematical models of computation. • Imperative : Von Neumann machine. • Functional : Lambda calculus. • Relational : Predicate calculus (Horn clauses). • So far as I know there is no paradigm based on the most famous mathematical model of them all : the Turing machine. • The Von Neumann model is the easiest one to build in hardware. • Von Neumann machine is essentially a single processor computer. • Most programming languages are imperative.

5. Paradigms & Computational Models • Each paradigm has its own computational model. • World view. • Its model of what computation actually is. • To understand a paradigm you must understand its world view. • Why do we want to understand different programming paradigms? “If all you have is a hammer, then every problem looks like a nail”. -- Baruch’s observation. • No one paradigm has the best world view for all problems. One aim of this course is to help you decide which paradigm is best suited to the problem at hand.

6. Processor input output bytes Memory World View Of Imperative Languages • Processor executes instructions stored in memory. • Instructions modify memory contents, read input and / or write output. • Contents of memory + input not yet read + output written so far = state.

7. World View Of Imperative Languages II • Imperative world view is based on state. • Imperative program = sequence of instructions which modify state (i.e. statements). • Result of computation is state after the computation has terminated. • Most computers are Von Neumann machines. • Have the same world view as imperative languages. • Little translation overhead. • Imperative languages run efficiently on them. • Imperative languages tend to use Von Neumann hardware as efficiently as possible. • Imperative languages tend to use programmer time as inefficiently as possible.

8. program input output World View Of Functional Languages • Usually written : output = program input • The program is a function which is applied to the input to calculate the output. • No notion of a state which can be modified so no statements. • No memory in the model so no variables to assign to. • Functional programs do have variables but they are mathematical variables (n.b. Backus’ FP). • Similar to constants in imperative languages. Cannot be changed, can only be redefined (i.e. redeclared). Have a constant value in a given scope.

9. World View Of Functional Languages II • Example : functional (Haskell) program to compute a factorial. factorial n = foldl (*) 1 [1..n] • Program defines what a factorial is. Does not explicitly tell a Von Neumann computer how to compute it by state modifications. • Instructive to compare the above with the equivalent imperative code (e.g. for C). • Functional program a lot shorter because there is no consideration of memory. • Functional program a lot less efficient (on a Von Neumann machine) because there is no consideration of memory.

10. program input output World View Of Relational Languages • Usually written : program(input, output) • The program is a relation which holds between the input and the output. • No notion of a state which can be modified so no statements. • No memory in the model so no variables to assign to. • Relational programs do have variables but they are logical variables. • Logical variables take on the values required to make the relations containing them hold.

11. World View Of Relational Languages II • Example : relational (PROLOG) program expressing some facts about things I like. likes(dave, functions). likes(dave, history). likes(dave, cricket). likes(dave, beer). likes(dave, fags). likes(dave, sci-fi). likes(dave, anoraks). likes(dave, X) :- likes(X, functions), likes(X, cricket), likes(X, sci_fi), likes(X, history). • Program defines what some of the things I like are. Does not explicitly tell a Von Neumann computer how to decide whether I like something by state modifications.

12. World View Of Relational Languages III • Instructive to compare the above with the equivalent imperative code (e.g. for C). • Relational program a lot shorter because there is no consideration of memory, input and output. • Relational program a lot less efficient (on a Von Neumann machine) because there is no consideration of memory, input and output. • Relational program also shorter and much less efficient than the equivalent functional program. • Relational paradigm is a lot further from the Von Neumann model than functional one. • One obvious abstraction from Von Neumann and Lambda calculus models: no real distinction between input and output. • There is no real notion of input or output.

13. World View Of Relational Languages IV • Can run a relational program backwards : give the program the output and it returns the input. • Running the program forwards we could type the query likes(dave, X) which would produce something like [ functions, history, cricket, beer, fags, sci-fi, anoraks, dave ] • Running the program backwards we could type the query likes(X, cricket) which would produce something like [ dave ] • Relational programs are bi-directional.

14. Imperative vs. Declarative World Views • Very simplistic view : • In an imperative program we must tell the computer exactly how to solve the problem. • In a declarative program we only need to tell the computer what the problem is. The computer works out how to solve the problem itself. • Simplistic, and inaccurate. • More sophisticated view : • In an imperative program variables are bound to store locations. • In a declarative program variables are bound to values. • Major consequence : declarative programs exhibit referential transparency; imperative programs don’t. • Referential transparency is a good thing.

15. Referential Transparency • Variables cannot be changed (although variables can be re-declared). • Value of a variable cannot change within a given scope. • Declarative language variable » imperative language constant. • Programs are easier to understand / reason about / prove. • Correctness preserving program transformation. f(x) + g(x) Û g(x) + f(x) • Can’t guarantee this in an imperative language. • Allows fold / unfold transformation (a.k.a. b-transformation). • A variable can always be replaced by its definition. • Prolog is not truly declarative (b-transformation doesn’t always work).

16. Pure & Impure Languages • A pure language is one which exhibits the characteristics of only one major paradigm. • Purely imperative languages include COBOL, FORTRAN, C, PL/1, Pascal and Algol. • Purely functional languages include Haskell, Miranda, Gofer, Hugs, Hope and KRC. • There are no purely relational languages (so far as I know). This is largely because the concept of I/O cannot really exist within the relational model. • Impure languages exhibit the characteristics of two or more major paradigms. • PROLOG is imperative and relational. • LISP and ML are imperative and functional. • POPLOG is imperative, functional and relational.

17. Minor Language Paradigms • The minor paradigms are extensions to / adaptations of the major paradigms. • Concurrent : imperative, functional and relational. • Computation (and state) is partitioned between processes. • Multiple execution images of a particular process can be created. • Object oriented : imperative only although functional and relational OO languages are claimed to exist. • Computation and state is partitioned between classes. • Classes may inherit attributes from other classes. • Classes may re-define the behaviour of operations upon them (overloading). • Multiple instances (i.e. objects) of a particular class can be created.

18. Minor Language Paradigms II • Dataflow : usually functional although the most famous example (LUCID) has an imperative style syntax. • Data flows through parallel nodes which apply functions to it to produce results. • 4GLs : essentially imperative (occasionally relational). • Basically, programming environments for specialist applications. • Usually produce imperative language programs as output (often COBOL or these days, C). • Interface programming : essentially imperative. • Reactive programming : computation is partitioned between buttons and dialog boxes.

19. Minor Language Paradigms III • Real-time : usually imperative although some lunatics have created functional (e.g. Ruth) and relational (e.g. Partlog) real-time languages. • Time expressibility is required : language constructs to talk about when things happen as well as what things happen. • Many other minor paradigms could be identified. • Largely a matter of taste whether a group of languages with similar characteristics is classified as a minor paradigm. • Note that many languages can be categorised as being in more than one minor paradigm. • Lustre is a real-time, dataflow language. • Ada is a concurrent, object-oriented, real-time language.

20. Purity & The Minor Paradigms • Most minor paradigm languages satisfy the definition of purity : they only exhibit characteristics from one major paradigm (usually the imperative paradigm). • Concurrent languages include Ada, occam, Modula-2, Modula-3, PARLOG, Concurrent PROLOG, PFL and CAML. • Object oriented languages include Ada, C++, Java, Smalltalk, Eiffel and Simula. • Dataflow languages include LUCID, Lustre, Signal and Esterel. • 4GL languages include Visual Basic and Javascript. • Interface languages include HTML, TK/TCL, Visual Basic, Java. • Real-time languages include Lustre, Ada, VxWorks C, Coral-66.

21. Health Warning • The classifications into major and minor paradigms and into pure and impure languages are personal ones. • Could argue that the minor paradigms are as fundamental as the major ones. • Could have some other definition of purity. • Could be argued that structured programming deserves inclusion as a minor paradigm. • Could be argued that heuristic methods deserve inclusion as a major paradigm. • For the purposes of this course my classifications have two major strong points : • They are based on mathematical principles and so are easy to defend. • I mark the exam papers.

22. 1950 FORTRAN LISP ALGOL 60 COBOL 1960 Simula PL/1 ALGOL 68 Pascal 1970 Smalltalk PROLOG C ML Ada 1980 Miranda C++ Eiffel 1990 Haskell/Gofer Java Genealogy Of Programming Languages

23. Summary • Programming language must be universal, natural, implementable and efficient. • Style of semantics of language defines paradigm. • Major paradigms : • Imperative : Von Neumann machine. • Functional : Lambda calculus. • Relational : Horn clause predicate calculus. • Imperative : variables bound to store locations. • Efficiency (on Von Neumann machines). • Declarative (i.e. functional or relational) : variables bound to values. • Referential transparency.

24. Summary II • Minor paradigms : • Concurrent. • Object oriented. • Dataflow. • 4GLs. • Interface programming. • Real-time. • Could identify many others. • Most minor paradigm languages fit in more than one minor paradigm.