Content deleted Content added
Nowhere man (talk | contribs) |
No edit summary |
||
Line 264:
::''Iterators are a 1980's version of the 1950's concept of generators. A generator is a subroutine which is called like a function, but returns a "new" value every time it is called (i.e., it is emphatically not a mathematical function). The "random number generator" is prototypic of a generator.''
:With this new information in hands, I will not wait to modify the article. [[User:Nowhere man|Nowhere man]] 17:38, 29 April 2007 (UTC)
== Suggestion for clarifications, definitions, etc. ==
The Icon programming language, while not the first language to implement generators, was one of the first to fully integrate the concept into the language. Within Icon, generators are not only used within the scope of loops, but are available throughout the language. In addition while in a certain sense one could say that a generator returns a list of values, a better term is that a generator returns a result sequence. Specifically, a generator could return an infinite number of values (e.g. a random number generator).
There was a lot of research and many papers written on generators. In doing a date sorted search of the string "generator" in the ACM portal, the earliest reference I found (outside random number generators, and a couple of references to code generators) was
<code><pre>
Mary Shaw, William A. Wulf, Ralph L. London
August 1977
Communications of the ACM, Volume 20 Issue 8
Publisher: ACM Press
Full text available: pdf(1.28 MB)
Additional Information: full citation, abstract, references, citings
The Alphard “form” provides the programmer with a great deal of control
over the implementation of abstract data types. In this paper the
abstraction techniques are extended from simple data representation and
function definition to the iteration statement, the most important point
of interaction between data and the control structure of the language
itself. A means of specializing Alphard's loops to operate on abstract
entities without explicit dependence on the representation ...
Keywords: abstraction and representation, abstraction data types,
assertions, control specialization, correctness, generators, invariants,
iteration statements, modular decomposition, program specifications,
programming languages, programming methodology, proofs of correctness,
types, verification
</pre></code>
Of interest, is that immediately following the above article in the same issue of the Communications of the ACM, was an article on CLU.
The next real reference to generators was the article written by the late Dr Ralph Griswold
<code><pre>
Generators in Icon
Full text pdf formatPdf (1.03 MB)
Source ACM Transactions on Programming Languages and Systems (TOPLAS) archive
Volume 3 , Issue 2 (April 1981) table of contents
Pages: 144 - 161
Year of Publication: 1981
ISSN:0164-0925
Authors
Ralph E. Griswold Department of Computer Science, The University of Arizona, Tucson, AZ
David R. Hanson Department of Computer Science, The University of Arizona, Tucson, AZ
John T. Korb Xerox Corporation, 3333 Coyote Hill Road, Palo Alto, CA
Publisher
ACM Press New York, NY, USA
</pre></code>
Quoting from the above
<code><pre>
5. RELATED WORK
The concept of generators has appeared in various forms in many languages. An
early language that has generators is IPL-V [31], in which a generator is a
subroutine that calls a processing routine to operate on each object in a data
structure. Other languages, such as ALGOL 68 [38] and COBOL, use the term
generator to describe various language features, but this use is unrelated to the
Icon notion.
Languages that support coroutines frequently use the term generator to describe
a particular coroutine usage. SIMULA [1] is the oldest of such languages;
more recent examples include extensions to POP-2 [24] and SL5 [20] and
coroutine additions to PASCAL [27]. There also has been a substantial amount
of work on the "lazy evaluation" approach to the incremental generation of
sequences, usually in LISP or APL frameworks [7, 17, 22].
More recently, ALPHARD [43] and CLU [28] have been developed to support
data structure abstraction. In these languages generators are used to iterate over
the elements of programmer-defined data structures [35]. Included with the
definition of a data abstraction (or "cluster" in CLU) is a procedure for generating
the elements of the abstraction. In CLU, this procedure, called an iterator,
produces its values using the yield statement. When another element is required,
execution of the iterator continues where the yield statement left off. In each of
these languages, generators are only accessible in a specific context: a particular
type of for statement. This is significantly more restricted than in Icon, where
generators may appear anywhere.
Superficially, generators in ALPHARD and CLU appear to correspond to the
every expression in Icon. But while every has the syntactic appearance of a
standard control structure, the nonstandard goal-directed evaluation mechanism
makes its semantics more general than the corresponding ALPHARD and CLU
constructs. It is the restricted applicability and the lack of goal-directed evaluation
that differentiate these constructs from generators in Icon.
ACM Transactions on Programming Languages and Systems, Vol. 3, No. 2, April 1981.
158 R.E. Griswold, D. R. Hanson, and J. T. Korb
</pre></code>
| |||