• wonderlic tests
  • EXAM REVIEW
  • NCCCO Examination
  • Summary
  • Class notes
  • QUESTIONS & ANSWERS
  • NCLEX EXAM
  • Exam (elaborations)
  • Study guide
  • Latest nclex materials
  • HESI EXAMS
  • EXAMS AND CERTIFICATIONS
  • HESI ENTRANCE EXAM
  • ATI EXAM
  • NR AND NUR Exams
  • Gizmos
  • PORTAGE LEARNING
  • Ihuman Case Study
  • LETRS
  • NURS EXAM
  • NSG Exam
  • Testbanks
  • Vsim
  • Latest WGU
  • AQA PAPERS AND MARK SCHEME
  • DMV
  • WGU EXAM
  • exam bundles
  • Study Material
  • Study Notes
  • Test Prep

Answers to Selected Problems

Testbanks Dec 29, 2025 ★★★★★ (5.0/5)
Loading...

Loading document viewer...

Page 0 of 0

Document Text

Solutions Manual to Concepts of Programming Languages Twelfth Edition R.W. Sebesta 1 / 4

17

Answers to Selected Problems

Chapter 1

Problem Set:

  • Some arguments for having a single language for all programming domains are: It
  • would dramatically cut the costs of programming training and compiler purchase and maintenance; it would simplify programmer recruiting and justify the development of numerous language dependent software development aids.

  • Some arguments against having a single language for all programming domains are:
  • The language would necessarily be huge and complex; compilers would be expensive and costly to maintain; the language would probably not be very good for any programming domain, either in compiler efficiency or in the efficiency of the code it generated. More importantly, it would not be easy to use, because regardless of the application area, the language would include many unnecessary and confusing features and constructs (those meant for other application areas). Different users would learn different subsets, making maintenance difficult.

  • One possibility is wordiness. In some languages, a great deal of text is required for
  • even simple complete programs. For example, COBOL is a very wordy language. In Ada, programs require a lot of duplication of declarations. Wordiness is usually considered a disadvantage, because it slows program creation, takes more file space for the source programs, and can cause programs to be more difficult to read.

  • The argument for using the right brace to close all compounds is simplicity—a right
  • brace always terminates a compound. The argument against it is that when you see a right brace in a program, the location of its matching left brace is not always obvious, in part because all multiple-statement control constructs end with a right brace.

  • The reasons why a language would distinguish between uppercase and lowercase in its
  • identifiers are: (1) So that variable identifiers may look different than identifiers that are names for constants, such as the convention of using uppercase for constant names and using lowercase for variable names in C, and (2) so that catenated words as names can have their first letter distinguished, as in TotalWords. (Some think it is better to include a connector, such as underscore.) The primary reason why a language would not 2 / 4

18

distinguish between uppercase and lowercase in identifiers is it makes programs less readable, because words that look very similar are actually completely different, such as SUM and Sum.

  • One of the main arguments is that regardless of the cost of hardware, it is not free.
  • Why write a program that executes slower than is necessary. Furthermore, the difference between a well-written efficient program and one that is poorly written can be a factor of two or three. In many other fields of endeavor, the difference between a good job and a poor job may be 10 or 20 percent. In programming, the difference is much greater.

  • The use of type declaration statements for simple scalar variables may have very little
  • effect on the readability of programs. If a language has no type declarations at all, it may be an aid to readability, because regardless of where a variable is seen in the program text, its type can be determined without looking elsewhere. Unfortunately, most languages that allow implicitly declared variables also include explicit declarations. In a program in such a language, the declaration of a variable must be found before the reader can determine the type of that variable when it is used in the program.

  • The main disadvantage of using paired delimiters for comments is that it results in
  • diminished reliability. It is easy to inadvertently leave off the final delimiter, which extends the comment to the end of the next comment, effectively removing code from the program. The advantage of paired delimiters is that you can comment out areas of a program. The disadvantage of using only beginning delimiters is that they must be repeated on every line of a block of comments. This can be tedious and therefore error- prone. The advantage is that you cannot make the mistake of forgetting the closing delimiter.

Chapter 2

Problem Set:

  • Because of the simple syntax of LISP, few syntax errors occur in LISP programs.
  • Unmatched parentheses is the most common mistake.

  • The main reason why imperative features were put in LISP was to increase its
  • execution efficiency.

  • The main motivation for the development of PL/I was to provide a single tool for
  • computer centers that must support both scientific and commercial applications. IBM believed that the needs of the two classes of applications were merging, at least to some degree. They felt that the simplest solution for a provider of systems, both hardware and software, was to furnish a single hardware system running a single programming language that served both scientific and commercial applications.

  • IBM was, for the most part, incorrect in its view of the future of the uses of
  • computers, at least as far as languages are concerned. Commercial applications are nearly all done in languages that are specifically designed for them. Likewise for scientific applications. On the other hand, the IBM design of the 360 line of computers was a great success--it still dominates the area of computers between supercomputers and minicomputers. Furthermore, 360 series computers and their descendants have been widely used for both scientific and commercial applications. These applications have been done, in large part, in Fortran and COBOL. 3 / 4

19

  • The argument for typeless languages is their great flexibility for the programmer.
  • Literally any storage location can be used to store any type value. This is useful for very low-level languages used for systems programming. The drawback is that type checking is impossible, so that it is entirely the programmer's responsibility to insure that expressions and assignments are correct.

  • A good deal of restraint must be used in revising programming languages. The
  • greatest danger is that the revision process will continually add new features, so that the language grows more and more complex. Compounding the problem is the reluctance, because of existing software, to remove obsolete features.

  • One situation in which pure interpretation is acceptable for scripting languages is
  • when the amount of computation is small, for which the processing time will be negligible. Another situation is when the amount of computation is relatively small and it is done in an interactive environment, where the processor is often idle because of the slow speed of human interactions.

  • New scripting languages may appear more frequently than new compiled languages
  • because they are often smaller and simpler and focused on more narrow applications, which means their libraries need not be nearly as large.

Chapter 3

Instructor's Note:

In the program proof on page 160, there is a statement that may not be clear to all, specifically, (n + 1)* … * n = 1. The justification of this statement is as follows:

Consider the following expression:

(count + 1) * (count + 2) * … * n The former expression states that when count is equal to n, the value of the later

expression is 1. Multiply the later expression by the quotient:

(1 * 2 * … * count) / (1 * 2 * … * count) whose value is 1, to get (1 * 2 * … * count * (count + 1) * (count + 2) * … * n) / (1 * 2 * … * count) The numerator of this expressions is n!. The denominator is count!. If count is equal to n, the value of the quotient is n! / n!or 1, which is what we were trying to show.

  • / 4

User Reviews

★★★★★ (5.0/5 based on 1 reviews)
Login to Review
S
Student
May 21, 2025
★★★★★

With its step-by-step guides, this document made learning easy. Definitely a impressive choice!

Download Document

Buy This Document

$1.00 One-time purchase
Buy Now
  • Full access to this document
  • Download anytime
  • No expiration

Document Information

Category: Testbanks
Added: Dec 29, 2025
Description:

Solutions Manual to Concepts of Programming Languages Twelfth Edition R.W. Sebesta Answers to Selected Problems Chapter 1 Problem Set: 3. Some arguments for having a single language for all program...

Unlock Now
$ 1.00