Structure of Programming Languages – Lecture 2A

Structure of Programming Languages – Lecture 2A

Structure of Programming Languages { Lecture 2a CSCI 6636 { 4536 February 4, 2020 CSCI 6636 { 4536 Lecture 2a. 1/19 February 4, 2020 1 / 19 Outline 1 Overview of Languages 2 Language Properties 3 Good or Bad: Fundamental Considerations 4 Homework CSCI 6636 { 4536 Lecture 2a. 2/19 February 4, 2020 2 / 19 Outline The Language Landscape Languages Come in Many Flavors. Possible Design Goals Design Examples Representation Issues CSCI 6636 { 4536 Lecture 2a. 3/19 February 4, 2020 3 / 19 Overview of Languages What is a Program? We can view a program two ways: Developer's view: A program is the implementation of a design (a model) for a piece of software. Coder's view: A program is a description of a set of actions that we want a computer to carry out on some data. Similarly, we can view a language more than one way: High level: It permits us to express a model. Low level: It permits us to define a correct set of instructions for the computer. CSCI 6636 { 4536 Lecture 2a. 4/19 February 4, 2020 4 / 19 Overview of Languages Aspects of a Language. To use a language effectively we must learn these four aspects: Syntax is the set legal forms that a sentence or program unit may take. During translation, if the syntax of a program unit is legal (correct), then we can talk about the semantics of the unit. Semantics is the science of meaning. Operational semantics is the set of actions when a program is executed. Style is a set of human factors. Style guidelines tell you how to make your code readable, debuggable, and maintainable. Usage is how the creator intended programmers to use the language feature, or the ways that the language community has developed to use it effectively. Usage is built upon syntax, semantics, and style. Usage guidelines usually go far beyond the language rules to tell you how to organize and write code and what to avoid. Can is not the same as should! CSCI 6636 { 4536 Lecture 2a. 5/19 February 4, 2020 5 / 19 Overview of Languages Possible Design Goals These apply both to entire languages and to features within a language. 1 Utility. Is the language or language feature often useful? 2 Efficiency. Does it lead to efficient software? 3 Portability. Are program results the same on any machine? 4 Convenience. Is it easy to use? Does it support concise code? 5 Readability. Is it naturally readable? 6 Modeling ability. Will this feature or language help the programmer model a problem more fully, more precisely, or more easily? 7 Simplicity. Is the language design as a whole simple, unified, and general, or is it full of dozens of special-purpose features? 8 Clarity. Does every legal program have one defined, unambiguous, time-invariant meaning? CSCI 6636 { 4536 Lecture 2a. 6/19 February 4, 2020 6 / 19 Overview of Languages Design Examples Scheme was created to clean up the semantics of LISP and make it more true to the underlying mathematical model (Lambda Calculus). C is useful, efficient, simple, and mostly-portable. Some people think it is convenient. Its readability is good ONLY if a programmer uses a disciplined style, but modeling ability is limited. Clarity and portability are damaged by the ambiguous nature of type int and the undefined order of evaluation of expressions. C++ is useful, efficient, convenient, and has excellent modeling ability. Its readability, clarity and portability are about the same as C. It is absolutely NOT a simple language. Java is useful, highly portable, convenient, and has excellent modeling ability and clarity. Its readability is damaged by the length of the identifiers in the standard libraries. It is absolutely NOT a simple language; the API is massive, complex, and confusing. Its efficiency is limited by the fact that it runs inside a virtual machine. CSCI 6636 { 4536 Lecture 2a. 7/19 February 4, 2020 7 / 19 Language Properties Representation Issues Semantic Intent Power Explicit vs. Implicit Coherence Locality Distinct Representation Early vs. Late Binding CSCI 6636 { 4536 Lecture 2a. 8/19 February 4, 2020 8 / 19 Language Properties Semantic Intent A programmer has some idea or model of what he wants and expects the program to do. This is his semantic intent. A program has semantic validity if it carries out the programer's semantic intent. Or... the program works properly, as expected. CSCI 6636 { 4536 Lecture 2a. 9/19 February 4, 2020 9 / 19 Language Properties Language Power A language is powerful to the extent that it permits the programmer to easily and explicitly state his semantic intent, and that intent will be honored and enforced. There are two kinds of power a language can have: 1 The power to do something easily. 2 The power to prevent something you do not want to happen. Example: The template classes in C++ and Collection classes in Java make it very easy to use stacks, queues, maps, trees, etc. The private qualifier in Java or C++ prevents unwanted access to a variable. Often, an emphasis on (1) leads to relatively bad behavior on (2), and vice versa. Example: Python CSCI 6636 { 4536 Lecture 2a. 10/19 February 4, 2020 10 / 19 Language Properties Explicit vs. Implicit The structure of an object can be reflected in a program either Implicitly: the object has structure but nothing in the program (or maybe only the comments) describe that structure. Explicitly: something that is part of the language defines the intended structure. Example: In FORTRAN-77 and in R, a table of objects would be defined as a set of parallel arrays, each storing one property of the objects. In C, the same table can be defined explicitly as an array of structs. CSCI 6636 { 4536 Lecture 2a. 11/19 February 4, 2020 11 / 19 Language Properties Explicit vs. Implicit Typing The type of an object or a function can be either explicit or implicit. Implicit: In C++, you can declare a variable as type auto. Its actual type will be deduced from the context in which it is first used. Implicit: In C, you do not need to specify the return type of a function. If it is omitted, it will default to type int, and return values will be coerced to type int. Explicit: In C, you MAY specify the return type of a function. If it is declared, return values will be coerced to match the declared type. It is misleading, error prone, and unmaintainable when a programmer relies extensively on implicit type declarations. Type auto is included in C++ because, sometimes, it is the only way to handle the types of variables used to implement templates. In other contexts, auto should not be used. CSCI 6636 { 4536 Lecture 2a. 12/19 February 4, 2020 12 / 19 Language Properties Coherence A object, idea, or process is represented coherently if it is represented by a single symbol in the program so that it may be used as a unit. A coherently represented object may have parts that can also be used separately. It does not need to be stored in consecutive memory locations. Examples: The former leaves us in doubt about any relationship among the five symbols. The latter explicitly says that these constants belong together and define a set of alternatives. A C++ vector (Java ArrayList) is a coherent representation of a dynamic array. Internally, it contains a dynamic array and the two integers needed to manage and access it. In C, these are three separate variables. CSCI 6636 { 4536 Lecture 2a. 13/19 February 4, 2020 13 / 19 Language Properties Locality High locality makes it easier to debug, modify, and maintain a program. Locality is high if related things are written together. Locality is low if many lines or pages of code separate a definition from its uses, or if parts of the same object are defined in two or more places. Examples: A C++ class has better locality than a C structure. In C++, data members are bundled together with the functions that use and manage them. In C, the language does not support this kind of bundling. A Java class has better locality than a C++ class. In Java, all parts of a class are defined in the same file. In C++, a class is split into two files: a header and an implementation. CSCI 6636 { 4536 Lecture 2a. 14/19 February 4, 2020 14 / 19 Language Properties Distinct Representation Trouble follows if a language uses a word or construct for two purposes. Examples: In early Basic, each line of code stared with a line number. Line numbers have two, conflicting purposes: To designate the execution order of the code lines. As the targets of GOTO commands. A programmer will often need to add more code between two lines that were written earlier. This can easily force renumbering for a part of the program. But when lines are renumbered, any GOTO's into the renumbered part will go to the wrong place. In C++ the keywords \static" and \virtual" both have two meanings. This causes endless confusion among students. CSCI 6636 { 4536 Lecture 2a. 15/19 February 4, 2020 15 / 19 Language Properties Early or Late Binding This is the single greatest difference between OO languages and functional languages. A language uses early binding when you are required to declare types for variables prior to compilation. (Fortran, C, Forth) Early binding leads to more stable, more efficient, and more maintainable code. A language uses late binding when variables are typeless. Objects have types, but different type objects might be bound to the same variable at different times.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    20 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us