1 1 COEN 171 Programming Languages Winter 2000
- Slides: 22
(1. 1) COEN 171 Programming Languages Winter 2000 Ron Danielson
Coen 171 - Fundamentals (1. 2) · Overview of course – syllabus – assignments · Background survey · · · · – language experience – relevant courses Motivation Programming domains and language types Evaluating programming languages Influences on programming language design Translation Programming environments Programming language history
Why Study Programming Languages? (1. 3) · Increased capacity to express programming concepts · Better able to select a language to solve a problem · Better able to learn and use a new programming language · Better able to understand the impact of other features (e. g. , architecture) on a language – and vice versa
Why Study Programming Languages? (continued) (1. 4) · Greater understanding of significant implementation issues · Culture – programming languages have impact on almost everything about computing · Lots of opportunities to design small languages
Programming Domains · Scientific applications – execution efficiency, numerical accuracy · Business applications – decimal data types, I/O editing, record structures · Artificial intelligence – symbol manipulation, programs as data · Systems programming – efficiency, access to hardware features · Very high-level languages – perl, tcl/tk, Power. Builder · Special purpose languages – RPG, GPSS (1. 5)
Basic Models of PL Design · Imperative – command driven, computer oriented – C, Pascal, Ada, etc. – OO (Smalltalk, C++, Java) as a subset · Functional – apply functions to arguments – process oriented – LISP · Declarative or relational – logical description of problem – specification, not process – Prolog (1. 6)
Criteria for Evaluating PLs - Design Reflects Tradeoffs (1. 7) · Readability (understandability) – simplicity » too many features » > 1 feature for same purpose – orthogonality » small number of primitives which can be combined in a relatively small number of ways » learning and use easier » ALGOL 68, LISP – control statements » enough for expressibility, not too many
Criteria for Evaluating PLs - Design Reflects Tradeoffs (continued) · Reliability (continued) – data types and structures » ditto – syntax » uniformity and expressiveness · Writeability – simplicity and orthogonality – abstraction mechanisms – expressibility (1. 8)
Criteria for Evaluating PLs - Design Reflects Tradeoffs (continued) · Reliability – type checking – mechanisms to minimize aliasing – exception handling · Cost – learning – program development » compilation » execution – maintenance – portability (1. 9)
Influences on PL Design (1. 10) · Computer architecture – von. Neumann architecture – parallel and network environments – PROLOG machines · Programming methodologies and paradigms – machine vs. human efficiency – shift from process to data orientation » data abstraction, object-oriented – concurrency
Influences on PL Design (continued) · Trade-offs – reliability vs. cost of execution » bounds checking – writability vs. readability » APL – flexibility vs. safety » strong type checking (e. g. , Ada) (1. 11)
(1. 12) Fundamental Concepts for Describing PLs · Syntax – what is a grammatically correct construct · Semantics – what is the meaning of a PL statement · We separate these for discussion purposes, but they are closely related – the semantics should follow from the syntax – both are often intertwined in translators
Kinds of Translators (1. 13) · Compilers – translate source code into machine code one time and the machine code executes · Interpreters – translate each source code statement every time it executes · Hybrid systems – translate the source code into a simpler form once, then interpret the translated form · Compilers provide code that executes rapidly, interpreters provide flexibility
(1. 14) Compilation Process Source Program Lexical Analysis Symbol Table lexical units Syntax Analysis Syntax parse trees Semantics Intermediate Code Gen int. text Code Generation machine code Object Program Optimization
Lexical Analysis · Breaks input stream into tokens – reserved words – keywords – identifiers – operators – punctuation (1. 15)
Lexical Analysis (continued) (1. 16) · Information about tokens kept in symbol table – may contain » text string, type, location » block » number subscripts, upper/lower bounds – token is then represented as pointer to symbol table – syntax, semantics, code gen all use symbol table – requires easy insertion/deletion, rapid search
Syntax Analysis (1. 17) · Generated from grammar describing PL · Verifies correct syntax, produces internal representation – build parse trees · Two basic approaches – bottom up » start with tokens, reduce to nonterminals, continue until find start symbol » LR(k) – top down » begin with start symbol, guess at production applied, continue until terminal string produced » LL(k)
(Static) Semantic Analysis (1. 18) · Enters information in symbol table · Checks that symbol table information meets constraints of use – type compatibility, number of subscripts, number of parameters · Generate intermediate text – equivalent to assembly language – postfix, n-tuples, abstract parse trees · Associate semantic actions with productions in grammar – like attribute grammar
Optimization and Code Generation · Optimization – can occur on intermediate text or generated code – analyzes » redundant operations » code movement out of loop » unreachable blocks – takes advantage of target architecture » parallelism, superscalar · Code Generation – depends on target machine architecture – find patterns in intermediate text, match with templates, produce corresponding machine code – can produce machine code, assembly, highlevel language (preprocessor) (1. 19)
Programming Environments · · · Editors Debuggers Version control systems File systems Test generators Windows systems (1. 20)
PL History · First wave – Fortran (1957) – Algol-60 (1958 - 62) – Cobol (1960 - 62) – LISP (1958) · Second wave – PL/I (1964 - 65) – Algol-68 (1. 21)
PL History (continued) · Third wave – Pascal (1971 - 73) – C (1972) – Prolog (1971 - 75) · Fourth wave – Smalltalk (1972 - 80) – Ada (1975 - 83) – C++ (1985) – Ada 95 (1988 - 95) – Java (1995) (1. 22)
- Coen 6501
- Coen 311
- Coen 445
- Coen 445
- Coen 445
- Coen 352
- Coen311
- Winter kommt flocken fallen nieder
- Winter kommt winter kommt flocken fallen nieder
- Winter kommt winter kommt flocken fallen nieder
- Lei 171 de 2007
- 171 sayli mekteb
- 171 meaning
- Hazmat material table
- What do salir decir and venir have in common
- 171 sayli mekteb
- 171 nomreli mekteb
- Cs 171 uci
- Nonlinear pricing example
- 171 nomreli mekteb
- Pg 171
- 171 in binary
- Ai 171