Concepts+Techniques+and+Models+of+Computer+Programming_Part17

Concepts+Techniques+and+Models+of+Computer+Programming_Part17

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
438 Explicit State end local C={NewCell 0} in C:=25 {Sqr fun {$} C end } {Browse @C} end The argument A is evaluated when the result is needed. The local variable B stores its result. If the argument is needed again, then B is used. This avoids reevaluating the function. In the Sqr example this is easy to implement since the result is clearly needed three times. If it is not clear from inspection whether the result is needed, then lazy evaluation can be used to implement call by need directly (see Exercise). Call by need is exactly the same concept as lazy evaluation. The term “call by need” is more often used in a language with state, where the result of the function evaluation can be the name of a cell (a mutable variable). Call by name is lazy evaluation without memoization. The result of the function evaluation is not stored, so it is evaluated again each time it is needed. Discussion Which of these mechanisms (if any) is “right” or “best”? This has been the subject of much discussion (see, e.g., [116]). The goal of the kernel language approach is to factorize programming languages into a small set of programmer- significant concepts. For parameter passing, this justifies using call by reference as the primitive mechanism which underlies the other mechanisms. Unlike the others, call by reference does not depend on additional concepts such as cells or procedure values. It has a simple formal semantics and is efficient to implement. On the other hand, this does not mean that call by reference is always the right mechanism for programs. Other parameter passing mechanisms can be coded by combining call by reference with cells and procedure values. Many languages offer these mechanisms as linguistic abstractions. 6.5 Stateful collections An important kind of ADT is the collection , which groups together a set of partial values into one compound entity. There are different kinds of collection depend- ing on what operations are provided. Along one axis we distinguish indexed collections and unindexed collections, depending on whether or not there is rapid access to individual elements (through an index). Along another axis we distin- guish extensible or inextensible collections, depending on whether the number of elements is variable or fixed. We give a brief overview of these different kinds of collections, starting with indexed collections. Copyright c ± 2001-3 by P. Van Roy and S. Haridi. All rights reserved.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
6.5 Stateful collections 439 Tuple Dictionary Record Array Add literal indices Add state Add state Add literal indices Indices are integers from 1 to N Cannot be changed Indices are integers or literals Cannot be changed Content can be changed Indices are integers from L to H Indices are integers or literals Content and size can be changed Figure 6.4: Different varieties of indexed collections 6.5.1 Indexed collections In the context of declarative programming, we have already seen two kinds of indexed collection, namely tuples and records . We can add state to these two data types, allowing them to be updated in certain ways. The stateful versions
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This document was uploaded on 08/10/2011.

Page1 / 30

Concepts+Techniques+and+Models+of+Computer+Programming_Part17

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online