1 / 37

CS 152, Programming Paradigms Fall 2011, SJSU

CS 152, Programming Paradigms Fall 2011, SJSU. Jeff Smith. Variables & constants. Make sure that you understand the difference between constants and literals initialization and assignment For values of constants may it require computation?

hye
Download Presentation

CS 152, Programming Paradigms Fall 2011, SJSU

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CS 152, Programming ParadigmsFall 2011, SJSU Jeff Smith

  2. Variables & constants • Make sure that you understand the difference between • constants and literals • initialization and assignment • For values of constants • may it require computation? • must it be computable at compile time? load time?

  3. Methods of assignment • by copying • cf. assignment by cloning in Louden, p. 170 • cf. deep vs. shallow copies • by sharing • Note the different implications for equality.

  4. Issues re assignment & initialization • Are multiple assignments allowed in one statement? • Does assignment return a value? • At run time, are newly allocated variables given default initial values? • How can pointer variables be initialized? assigned to? • How is storage allocated for the destinations of pointer variables?

  5. Aliases can be created • in assignment by sharing • in shallow copying • indirectly • as well as when using pointer variables and when passing parameters

  6. Expressions and statements • Ideally the meaning of an expression will depend only on • the values of the subexpressions, and • the meaning of the operator that is used to combine these values. • In this case, the semantics is said to be compositional.

  7. Order of evaluation • With compositional semantics, syntax trees can be evaluated bottom up. • Can subexpressions can be evaluated in any order without affecting the value? • This issue is important for compiler optimization. • The answer is "yes", in the absence of side effects. • Note that side effects can include throwing an exception, or simply failing.

  8. Short-circuit evaluation • With short-circuit evaluation of Boolean expressions, the order of evaluation of the subexpressions can determine whether the overall evaluation succeeds or fails. • Short-circuit evaluation is also a violation of the commutative law that holds for AND, OR, etc. • Some languages offer a choice between short-circuit operators and those that aren't short circuit.

  9. Modifying a function argument • Another special kind of side effect arises if a function can modify its argument. • In this case the order of evaluation can be important in an expression like • f(x) + g(x) • Functions that don't behave the way mathematical functions do make programs hard to reason about.

  10. Conditionals and ambiguity • Conditionals can be ambiguous, e.g. • if X then if Y then Z else W • Ambiguity is usually resolved here by associating each else with the nearest if.

  11. Disambiguating conditionals • A different interpretation can be forced by a requirement of explicit delimiters, e.g. • if X then {if Y then Z} else W

  12. Disambiguating conditionals • Or explicit bracketing keywords can be required for all conditionals, e.g. • if X then • if Y then Z endif • else W • endif • This is a different string of tokens than • if X then • if Y then Z else W endif • endif

  13. Explicit bracketing keywords • are used by Ada (cf. T&N, p 165). • may include an elsif construction to avoid multiple closing endifs, e.g. • if --- then --- • elsif --- then --- • elsif --- then --- • else --- • end if

  14. Tests as boolean expressions • A language designer needs to decide whether the tests in conditional statements need to have boolean values. • If not, then a policy is needed to determine which nonboolean values correspond to a successful test.

  15. Conditional evaluation • Don't confuse conditional execution with conditional evaluation (which returns a value). • In C the latter looks like • A ? B : C • When considered as ternary functions, such functions do not evaluate all of their arguments.

  16. Case and switch statements • Many languages offer multiway conditional statements based on the value of a single expression • e.g., switch statements in C • e.g., case statements in Fortran

  17. Issues for case and switch statements • which types are allowed for the expression? any discrete type? • can cases be combined for two or more different values? • is there a default case? • what if the actual value is not among the specified alternatives?

  18. Indefinite iteration • Languages may allow a block of statements may be executed while some condition remains true -- or until some condition becomes true. • In the first case the condition is tested before the block; in the second case it's tested afterwards. • C and Java have a while statement for case 1, and a do-until statement for case 2.

  19. For loops • Some special cases of iteration are handled with for loops, which use a loop control variable (LCV). • Loop control variable issues: • what types of LCVs are ok? any ordinal type? any discrete type? • must an LCV be explicitly declared? • must it be local to the loop?

  20. Values of loop control variables (LCVs) • must integer LCVs begin at 0? at 1? • can an LCV be assigned a value inside a loop? if so, is the assignment effective? • how can LCVs be incremented? decremented? • by successor or predecessor only? • are loop bounds evaluated just once, or at every iteration?

  21. Control and for loops • can control be transferred into a loop? • if so, what's the LCV's initial value? • can control be transferred out of a loop? • can control be transferred out of the current iteration? • if so, where does control go? can a programmer decide? • outside of the loop, do LCVs have a value? • if so, what is it?

  22. Collections and iteration • One common use of for loops is to process each element of a collection. • For this sort of traversal, languages sometimes provide a specialized for loop known as a for-each loop. • Another possibility is an iterator data type.

  23. Transferring control out of a loop • The ability to transfer control out of a loop is useful enough that some languages provide special mechanisms for doing so. • Java has a break construction (and a related continue construction) for this purpose. • One advantage of such constructions is that they can replace a goto statement of the sort found in assembly languages.

  24. Programming using goto • Using goto often leads to bugs and hard-to-read programs. • It's common for languages not to providing a goto statement at all. • Arguably, using break and continue avoids these problems of goto. • So languages that do not provide a goto statement often provide versions of these constructions.

  25. Detecting and handling errors • Many languages have a special mechanism for detecting and handling errors. • The alternative to a special mechanism would be to test for every possible error in the program code. • But some errors (out of memory, corrupt file) don't result from program code.

  26. Errors in functions • could be reported by a special return type • but the function may already have a conflicting return type. • could be reported by a special value of an existing return type (cf. p 181, T&N) • but all values of the return type might be needed for nonerroneous cases.

  27. Errors in functions, part 2 • could be dealt with by passing an error handling function as a parameter. • But not all languages allow function parameters. • could be reported by creating an extra return type, or passing an extra pointer (or reference) parameter. • But not all languages allow this.

  28. Detecting and reporting errors • All of these alternate mechanisms are arguably overly complicated, compared to an exception mechanism as in Java. • Errors that are found can sometimes be handled locally. • But the program segment that detects the error is not always the best segment to handle the error.

  29. Issues for exceptions • Are they types, or instances of types? • What types may be exception types? • Which such types are predefined? • How can users define their own exception types? • Are exceptions basic, or composite? • What is the scope of an exception (name)?

  30. Raising and handling exceptions • How are exceptions raised (or thrown)? • How are handlers defined? • i.e., where does handler code go?

  31. Issues for exception handlers • what is the scope of a handler? • what predefined handlers are available? • can they be redefined? • are there default handlers? • how are handlers bound to exceptions? • can handling be disabled? • If there's no local handler, • where is a nonlocal handler sought? • must it be sought explicitly? • how does the handler get control?

  32. Issues for continuation • after handling, does the handler return to the invoking unit? • can the programmer decide? • is the exception reraised? • where exactly does control resume? • in what environment? • can handlers raise exceptions? • can a value be returned? if so, how? • what if there's cleanup to do? • (e.g., a file to close)

  33. Issues regarding functions • what is the syntax of a call? a definition? a return? • what if there are no arguments? • can a function have side effects? • can a function have side effects only • i.e., no return value? • can function definitions be nested?

  34. Function overloading • can predefined functions be overloaded? • how can overloaded functions be distinguished? • is it enough to have distinct return types?

  35. Operator overloading • (Infix) operators • can they be user-defined? • if so, how are they distinguished from ordinary (prefix) functions? • can predefined operators be overloaded? • if so, must the precedence and associativity stay the same?

  36. Parameters • is an evaluation order specified? • how are parameters & arguments matched? • is it by position? by name? • are default parameters possible? • if so, must they come last? • are extra arguments just ignored? • or treated as an error? • is a variable number of parameters possible? • if so, can their types be checked?

  37. Returns and return values • can a return value be of any type? • an aggregate? a function? • If a function, what environment is used? • how is the type of the return value specified? • what is the syntax for a return? • assignment to a special variable? • an explicit return statement? • can the return value be ignored by the caller?

More Related