# Is there a term for “delegate” function in CS?

This question is all about terminology (names).

When you consider "list", this term is well defined in CS -- despite the fact programming languages use and misuse this term (for example C# List is not a list).

I am looking for term in Computer Science domain that C++ defines as pointer to a function, C# as delegate, Swift as closure. Consider a function A that takes another function B as a parameter -- is there established term for B? Functor?

• Perhaps operator. – Yuval Filmus Mar 31 '15 at 18:25
• It is called a functional parameter. But how much have you searched on your own? Did you read the wikipedia article on closure: en.wikipedia.org/wiki/Closure_%28computer_programming%29 - Technically, in most languages (statically scoped) any function is a closure, i.e. the association of a piece of code to be executed (with or without parameters) together with an environment that gives a meaning to all identfiers not defined locally. – babou Mar 31 '15 at 18:53
• @babou, thank you. "Closure" does not sound right, because it could be misleading when you have pure lambda (i.e. lambda that relies only on arguments). Besides it is rather associated with the caller side, not callee. – greenoldman Mar 31 '15 at 19:59
• I do not understand your objections to "closure", but it has been the accepted technical term for at least 35 year (from memory, without researching). When the body of the function contains no global variables, you just have a special case that requires only an empty environment. But the concept of closure is used more for functions as result, where it is essential. For functional parameters, you can leave all that implicit. This has to do with the fact that environment management requires no special mechanism in the case of functional parameters, unlike functional results. – babou Mar 31 '15 at 20:59
• Many programming languages don't have closures but do have references to functions that can be passed around. A C++ function pointer or C# delegate or Algol68 procedure reference is not a closure. – reinierpost Oct 17 '16 at 8:06

I cannot know all the parochial terminologies and concepts used by the great variety of the many - sometimes disputable - language designs available in computer science. Some design choices may be motivated by issues that are only remotely connected with science. But there is also some more or less established terminology.

When a function A takes a function B as parameter, that is simply called a functional parameter.

A function can be seen as composed of a control part (the code or instructions) and of an environment of entities used by the control. This environment comprises usually two kinds of program entities:

• local entities that are normally intended to be used during the lifetime of a call to the function, that have distict instances for distinct calls, and are visible only to other entities created (declared) in the body of the function. They come into existence at each function call, usually only for the duration of that call

• global entities that are defined (declared) in some (usually) enclosing structure (function, method, class instance ...) containing the function declaration, hence also visible and usable by the function. They are the same for each call of the function value created by the same declaration instance.

The function code together with its associated global environment is called a closure. The term is about 50 years old. But a closure is essentially a functional value.

Often the conceptual closure structure can be ignored as everything works naturally as one would hope, since a function declared in some environment usually ceases to be accessible, thus to be used, when this environment is exited. Hence it will no longer need what it was using there. It is however possible that a functional value $\gamma$ leaves the environment where its has been declared, and has to survive the disappearance of this environment where it uses some global entities. This happens mostly when another function returns $\gamma$ as a functional result.

If function G and variable X are declared in function F, then G can use X as a global. It may happen that the functional value $\gamma$ of G is returned by a call to F. This is no problem because that functional value $\gamma$ can be stored in a functional variable (some would probably say pointer) and just used from there. The difficulty comes from the fact that when this functional value $\gamma$ is called, it may use the variable X of the call to F that created $\gamma$, and terminated returning it. So special steps must be taken to preserve X for the closure, even after the call to F has terminated, and the corresponding environment should be no longer otherwise needed.

Actually, this occurs often in object oriented programming, for essentially the same reason. Object orientation can be implemented in a language that does not have it precisely by declaring an object constructor function with local variables (the state variables of the object constructed) that return tuples of functional values (the methods of the object class) accessing these variables. Thus the closure concept is just a very intentional and frequent occurrence in OO programming. Every method is essentially a closure on the environment implementing the state of an object. At each call to the constructor, a new tuple of closures is created for the new object, corresponding to function code that does not change, but which is closed on a new environment, the local environment of the constructor call that creates the object.

As said above, a closure is just a pair composed of a function and its globals. It is not mutable: the pair is essentially fixed when the function is created. However, the adress of such a pair is just a pointer to a closure, and can be stored in a variable. It can be dereferenced and called (no big mystery). But I do not know whether that is what C++ calls a pointer to a function, though I would hope it is.

You may note that creation of a closure has nothing to do with caller or callee. It has to do with the function that declares the closure, and with the function that returns it out of the environment where its globals are defined.

I am not experienced with C# delegates (so double check me), but they seem just to be functional types, that can have functions, closures, or methods as instances. This typing ensures that instances are not misused, as might happen with untyped pointers to functions. It is not clear to me whether C# allows changing the closure associated with a delegate instance, i.e. whether delegate instances are to be considered functional variables or functional constants. From what I read, it seems to be the former, hence the comparison with function pointer. Why that is necessary to pass functions or methods as parameter is apparently due to specific features of C#. Other languages do not need anything special for that: they just declare the parameter like any other, but with a functional type (i.e. a signature).

I suggest you read the wikipedia articles on closure and possibly scoping (though I have not read them in enough detail to vouch for their accuracy).

• Thank you very much for your exhaustive answer, great reading. – greenoldman Apr 3 '15 at 8:50
• Thanks. I just noticed I had written "latter" for "former¨ in the paragraph before last. So I corrected. In the example in the referenced C# manual page, it seems that delegates are being assigned values when being instantiated ... since it is the syntax of assignment with =. But this may be only syntax, and I am not sure the instanciation can be changed in the way a variable can be assigned a new value. This really needs better knowledge of C# than I have. – babou Apr 3 '15 at 10:21