Q&A Assignment #10 Chapter 8 Review Questions & Problem Set

Name : Vina Melinda

NIM  : 1801380106

Untuk kali ini saya akan menjawab Assignment #10 Problem Set dan Review Questions dari Chapter 8 dari Sebesta.

Review Questions:

6. Q: What is unusual about Python’s design of compound statements?

A:  Python uses indentation to specify compound statements. For example,if x > y :
x = y
print “case 1″
equally indent statements are grouped as one compound statement.

7. Q: Under what circumstances must an F# selector have an else clause?

A: If the expression returns a value, it must have an else clause

8. Q: What are the common solutions to the nesting problem for two-way
selectors?
A: The common solution to the nesting problem is to use alternating means of forming a compound statements.

9. Q: What are the design issues for multiple-selection statements?

A:
1. What is the form and type of the expression that controls the selection?• How are the selectable segments specified?
2. Is execution flow through the structure restricted to include just a single selectable segment?
3. How are the case values specified?
4. How should unrepresented selector expression values be handled, if at all?

10. Q: Between what two language characteristics is a trade-off made when
deciding whether more than one selectable segment is executed in one
execution of a multiple selection statement?

A: The C# switch statement differs from that of its C-based predecessors in two ways. First, C# has a static semantics rule that disallows the implicit execution of more than one segment. The rule is that every selectable segment must end with an explicit unconditional branch statement: either a break,which transfers control out of the switch statement, or a goto, which can transfer control to one of the selectable segments (or virtually anywhere else).
As with C, if there is no break at the end of the selected segment, execution continues into the next segment.

Problem Set:

6. Q: Analyze the potential readability problems with using closure reserved
words for control statements that are the reverse of the corresponding
initial reserved words, such as the case-esac reserved words of
ALGOL 68. For example, consider common typing errors such as transposing
characters.

A: There's not really a readability problem, it's simply something you get used to, and after some experience the problems falls out of the process. Similar to how many Lisp users "don't see" the parentheses. They simply don't stand out in the general case for the experienced reader.
You have to recall the time of Algol, notably the "68" part, as in 1968.The bright side of the fi, esac, and od is that they clearly indicate what kind of block they're terminating, and they do it with a single token. Esac is no less clear than }, which is a meaningless bracket until you know otherwise. The {} have the benefit of consistency, while less wordy than Pascals begin - end generic block sequence.Finally, consider how dominant the English language is in computer language design, and while folks who don't speak english may have some initial issues with the languages, that clearly passes over time.So, it's a short hurdle that falls away quickly with use.

7. Q: Use the Science Citation Index to find an article that refers to Knuth
(1974). Read the article and Knuth’s paper and write a paper that summarizes
both sides of the goto issue.

A: Considering the time frame of the early to mid seventies, Knuth’s description of an advantage of the use of gotos was well understood. In fact C language which was created in the late ’60s had already dealt with the problem you’ve given as an example. With nested loops and conditions calling for exiting those loops from deep within the nesting, gotos are more efficient and even more elegant than multiple test flags and testing statements. So C incorporated the “break” statement to handle that problem. Redefining “goto” in a situation where its use is valuable to something more restricted and directed to the problem was the answer. An answer given years before.

8. Q: In his paper on the goto issue, Knuth (1974) suggests a loop control
statement that allows multiple exits. Read the paper and write an operational
semantics description of the statement

A: Work on the formal semantics of programming languages began in the 1960’s
– a useful early reference is which reports on a conference held in Badenbei-Wien in 1964. The subsequent literature on formal semantics of sequential languages is extensive. A good state of the art example of a formal definition is that of standard ML. This definition is written in Structured
Operational Semantics. It is sobering that, after a quarter century of denotational semantics, it is still found more convenient to tackle the semantics of a language like SML in an operational way. Furthermore, it must be clear that it is extremely difficult to get a formal semantics to the stage where it correctly reflects the intuitions about a language. There are some language standards like that for Modula 2 which are actually being written using formal techniques. But overall the situation is that formal semantic definitions are written only by a very small number of highly skilled people.
The situation with recording the formal semantics

9. Q: What are the arguments both for and against the exclusive use of Boolean expressions in the control statements in Java (as opposed to also
allowing arithmetic expressions, as in C++)?

A: The primary argument for using Boolean expressions exclusively as control expressions is the reliability that results from disallowing a wide range of types for this use. In C, for example, an expression of any type can appear as a control expression, so typing errors that result in references to variables of incorrect types are not detected by the compiler as errors.No , it would not be a good idea. Although this custom precedence sounds like increasing flexibility, requiring parentheses to show a custom precedence would impact in readability and writability of a program.

10. Q: In Ada, the choice lists of the case statement must be exhaustive, so that there can be no unrepresented values in the control expression. In C++,
unrepresented values can be caught at run time with the default selector.
If there is no default, an unrepresented value causes the whole
statement to be skipped. What are the pros and cons of these two designs
(Ada and C++)?

A: In Ada, the choice lists of the "case" statement must be exhaustive, so that there can be no unrepresented values in the control expression.
In C++, unrepresented values can be caught at run time with the "default" selector. If there is no default, an unrepresented value causes the whole statement to be skipped.
Ada was designed for military grade software development.
The idea is that whenever you modify code in such a way that a new case emerges (for example adding a new value for an enumeration type), you are forced to manually revisit (and therefore re-validate) all the case statements that analyze it. Having a "default" is risky: you may forget that there is a case somewhere where the new case should not have been handled by the default.