generator/coroutine terminology

Rustom Mody rustompmody at gmail.com
Sat Mar 14 11:59:36 EDT 2015


On Saturday, March 14, 2015 at 8:59:22 PM UTC+5:30, Rustom Mody wrote:
> On Saturday, March 14, 2015 at 11:34:27 AM UTC+5:30, Steven D'Aprano wrote:
> > 
> > A generator (function) may be a function which returns an iterator,...
> 
> I find "generator-function" misleading in the same way that "pineapple" 
> misleadingly suggests "apple that grows on pines"
> 
> A builtin function is a function in the builtin (or builtins -- can never remember) module
> A pure function is function that does not assign or mutate non-locals
> A Steven-function is a function that presumably Steven wrote 
> 
> However a "generator function" is a weird sort of function (at best).
> Not regarding it as a function is IMO more reasonable.

Another analogy somewhat closer home than pineapples.
In Pascal there are procedures and functions.
Even in the venerable Fortran there are subroutine-subprogram and (sub)function-subprogram.

C took the stupid approach of just throwing out one of these.
A decade of troubles was enough to convince people that it was needed and the
mysterious 'void-returning' function was introduced to simulate procedures

Causing all sorts of unnecessary confusions:
An int-function returns int and a char*-functions returns char*.
Does a void-function return void??
No a void function doesn't return anything!
Ah So a void function does a longjmp?

All of which is to say that in retrospect we need (at least in imperative programming) procedures and functions.

Best if the language supports them

If not, then we need them all the more in the conceptual ontology we use to
build programs.

Analogously we need the generator 'design-pattern' as well as the function
design-pattern. Conflating one as a special case of the other is a recipe for
confusion



More information about the Python-list mailing list