Talk:Function (computer programming)

Old text from Subprogram

Someone with more patience and objectivity than I, might want to resurrect some of the text from this revision of Subroutine that was subsequently eroded and finally obliterated by well-meaning edits. I wrote this draft, and I think it has a decent, straightforward, NPOV structure that's more encyclopedic than what's currently on this page. --Doradus 02:04, Oct 1, 2004 (UTC)

The Python examples is riddled with mistakes

If that is intentional it should be pointed out in the text, but as of writing this, it only says "The following program prints "Hello world!" followed by "Wikipedia" on the next line.

def simple_function():
    print('Hello world!')
    print('Wikipedia')
simple_function()
# output will be:
Hello World!
Wikipedia
                  

def func(name)
    print("welcome "+name)
print(func("martin"))
#output will be: welcome martin

If you were to try and run this with Python, lines 6 and 7 would lead to syntax errors because they are not commented. The second example function is worse, the def statement does not end with a colon leading to another syntax error and because the function does not return anything, printing the return value of the function will print "None" after printing "welcome martin" 2001:7C0:2049:1D4:D511:6438:FDB6:39FC (talk) 14:33, 22 November 2023 (UTC)

Article scoping; rename proposal

This page has ALOT of history – is old with lots of edits. One could write an article about the history of this article :) I am new to this article, but have been programming for 30 years. I'm interested in improving this article – mostly for up and coming programmers wanting to learn the trade. As it was when I started working on it a few says ago, it was a mess – filled with inconsistent use of terms and wrong/bad info.

It tries to cover alot of ground – probably too much. But I'm focused on correcting what's there more than removing what's too far afield. At some point, maybe I'll get to refactoring into other pages.

Probably the biggest challenge for this article is scope. What is this about? Its title is 'function', but clearly it's also about subprogram ... and procedure ... and method ... OMG. Thing is, these terms all have meaning in the context of certain languages and environments. Even within particular contents, the meaning has changed over time -- over the last 70 years ... in arguably the most dynamic industry in human evolution! This article takes on a broad and deep topic.

But, I think it's worthwhile. Since whatever this article is about is clearly important.

But, to be useful and understandable, the article needs to be focused – as much as possible for such a board topic.

IMO this article always has been and should continue to be about the technology (or concept or construct) that is common among all languages and environments that allows programmers to structure code into chucks that can be used within a program to decompose a problem into a solution.

One challenge of this is that there is no one, good word for that!

Seems that function has connotations of the technology in general, but it is also bound tightly to particular implementations – contexts such as particular languages. Using it for the name of the technology seems off the mark.

Some say that subprogram is the general concept. In fact, I think this article used to be called subprogram. Why was it changed? Was the change a mistake?

An issue that I personally struggle with is that I often confuse subprogram and subroutine even though they are quite different, right? Subroutine is like function – an implementation of subprogram, right?

The article does use the term callable unit which does seem to cover the desired focus of this article. Unfortunately, it's not commonly used – not nearly as commonly used as the other terms (function, subprogram, ...). But, a Google search does have hits (other than this article). So, it is a thing apparently.

I think this article should be renamed – either back to subprogram or to callable unit. And, content should be updated to use the new name throughout when referring to the general concept. And, to continue to use the more specific terms as context warrants.

This article already has re-directs for all of the more specific terms and that should remain. Folks do and should continue to come to this article for all the various terms (callable unit, function, subprogram, ...).

...Just reviewed the edit history of this page. Seems that the page rename from subprogram to current function was done by Uni3993 in late 2022. And they seem to be permanently blocked :o) From that I take it that they have a history of over zealous modifications. It seems they did a global search and replace of 'subprogram' with 'function'. Well intentioned, but badly implemented. For one, when the word started a sentence, it was no longer capitalized. For another, I guess the result had "function and function". OMG. What a mess. Guy Harris fixed the many, many issues. Thanks for that!! I do want move away from 'function' as the general term, but do _not_ propose a simple minded search and replace. Would require a surgical approach.

– Stevebroshar (talk) 16:06, 4 February 2024 (UTC)

Regarding I'm interested in improving this article: Wonderful! Employ some secondary research to find reliable sources about functions and dive right in. Timhowardriley (talk) 22:51, 5 February 2024 (UTC)

Procedure context

In languages such as Algol 60 and PL/I, it is possible to define a procedure within another procedure. The procedure name identifies not only an entry point but also a context (stack frame) for local variables of the enclosing block. Similarly, in object oriented languages, an instance method is assciated with the context of an object, not just with its class. This is a special case of a Closure. I'm not quite sure where this belongs, but I believe that the article should discuss it in an NPOV manner and then give examples. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:43, 8 February 2024 (UTC). -- Revised 16:32, 12 February 2024 (UTC)

I don't think this article should attempt to describe every feature of a function in every language. I like that it tries to cover many aspects of functions (of whatever we call them) with examples from various languages. But, if we try to cover every feature for every language, the article will be too long ... and boring :) If it's wrong about algol and pl/l we should fix it. But IMHO we don't need to be exhaustive about each language. Stevebroshar (talk) 00:23, 13 February 2024 (UTC)

Recursive and reentrant are orthogonal

#Reentrancy states A recursive callable must be reentrant., but actually the two concepts are orthogonal. A recursive function can fail to be reentrant due to unserialized access to global data. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:57, 8 February 2024 (UTC)

I was thinking that the "a recursive callable must be reentrant" was not right. Please fix that section. Thanks. ... but I don't know what you mean by "A recursive function can fail to be reentrant due to unserialized access to global data". Try to keep it high level. This is not for compiler designers. I'd say it's for high school and college students learning to program. Stevebroshar (talk) 00:27, 13 February 2024 (UTC)

Fixed.

Consider a factorial function

FACT: PROCEDURE(N) RECURSIVE RETURNS(FIXED BINARY);
DECLARE
   COUNT FIXED BINARY EXTERNAL INIT(0)
   N FIXED BINARY;
   COUNT=COUNT+1; /* Not protected by a semaphor]]
   SELECT;
      WHEN (COUNT=0) RETURN 1;
      WHEN (COUNT>0) RETURN N*FACT(N-1);
      OTHERWISE SIGNAL CONDITION(NEGATIVE);
      END;
   END;

Since access to COUNT is not serialized with, e.g., a critical section, a semaphore, the function will not maintain a correct count if two invocations are invoked concurrently. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:09, 16 February 2024 (UTC)

Not wrong vs. misleading

Removal of "[callable unit] is not commonly used" is not wrong ... but...

Now it only says "The technology is generically called a callable unit" ... which is not wrong, ... but...

I am very concerned about how information can be misleading. To _not_ say that it's not common leads the reader to think 'callable unit' is common -- otherwise it wouldn't be in wikipedia, right? But, it is uncommon.

I struggle with what to call the thing that is the focus of this article. 'function' is not great since so many other terms have been used throughout the years. Even today 'function' is not the only term used. I would love to have a term that covers it all. But, there just isn't a common term that covers the breadth of the topic. 'callable unit' does, but it's not common and that fact is important IMHO.

It's like what is the gender neutral, singular pronoun? There isn't one!

And what is the gender neutral word for cow and bull, singular for cattle? Cattlebeast? 1 head of cattle? Stevebroshar (talk) 00:43, 13 February 2024 (UTC)

It's okay to start the history with "subroutine" and make that the most generic term. Then as technology improves, "procedures", "functions", and "methods" can be added to the vocabulary. Rather than trying to figure this out yourself, I suggest getting one of these books: Programming_language#Further_reading. I have Comparative Programming Languages by Wilson. There's a chapter called "Procedures, functions and methods" that is ripe for this article. This article also needs an explanation of the different parameter methods. Additionally, this article only has a superficial coverage of how functions are implemented. Andrew S. Tanenbaum is the godfather of modern computer hardware. I have the 1990 edition of his seminal book, Structured Computer Organization. (Subsequent editions are out there.) In this book, stack addressing and the stack frame are well covered. Timhowardriley (talk) 03:14, 13 February 2024 (UTC)

I think my father had books :) Joking aside, I think you are right that historically subroutine ... and subprogram ... and routine ... are older terms, then function came along to more or less replace them and then method came with OOP but doesn't replace function. That's my hypothesis. Is there a source that covers this aspect of history of this thing with many names? ... Comparative Programming Languages costs $3! I didn't plan on investing so much as part of my wikipedia hobby. Stevebroshar (talk) 11:26, 15 February 2024 (UTC)

Functions are overly restrictive. What about relations? And why sequences of instructions? Why exclude sets of callable units, which can be called in the order in which they are needed, or in parallel.

In the family of Prolog and Datalog logic programming languages, a callable unit is a predicate representing a relation. Moreover, a predicate can be defined in terms of other predicates, and can either be called using top-down backward reasoning, as in Prolog, or be derived bottom-up using forward reasoning, as in most Datalog systems.

A similar neutrality between sequential and parallel execution and between top-down and bottom-up problem solving strategies also arises in parsing formal grammars. Robert Kowalski (talk) 10:23, 15 February 2024 (UTC)

Thanks for your input. Many points to cover...

What do you mean by "Functions are overly restrictive"? That the term function is overly restrictive WRT the concept that the page is intended to cover? You think the central concept of the page is relation? If that's what you mean, then no, that's not what this article is about. ... unless I don't know what you mean by relation. I think of relation as a static association between things. Whereas a function is a dynamic action. Very different.

I think it's appropriate to call a function a sequence of instructions since the text of a function is a sequence of lines. Control flow when executed may not be sequential -- one line to the next -- although that is the default control flow when not otherwise directed by the instructions.

WRT "Why exclude sets of callable units": in what way are they excluded? You mean that concept should be included? Isn't that basically a library ... which is described?

... oh you are thinking about Prolog and Datalog logic programming (you buried the lede). OK. I don't know much about that. But, I wonder whether this predicate concept falls under the concept of this article (function...). Maybe the concept of this article only applies to imperative languages -- not other languages such as logic programming. Is a predicate something that gets called per se? Or is it a higher level concept? I'm sure a logic language processor (compiler/interpreter) includes callables. At the bottom level of abstraction, all programs execute as imperative instructions and almost surely include callables. But does it make sense to say that from the perspective of logic language source code to talk about calls? I'm thinking not. Stevebroshar (talk) 11:58, 15 February 2024 (UTC)

To put it differently, functions are not the only way to "structure code into chucks that can be used within a program to decompose a problem into a solution". Relations are more general than functions and can also be used to stucture code. I am certainly not suggesting that the article be renamed Relation (computer programming). Callable unit is not great either. I can live with subprogram, but function is simply not the topic of most of the article. Robert Kowalski (talk) 13:08, 15 February 2024 (UTC)

Relations as generalizations of functions-in-the-programming-sense: presumably you're referring here to something along the lines of this interpretation of predicate logic as a programming language. Guy Harris (talk) 20:29, 15 February 2024 (UTC)

Yes, but the field has moved a long way since then. See for example the Wikipedia article logic programming, and the section comparing functions and relations. Robert Kowalski (talk) 20:52, 15 February 2024 (UTC)

It can be challenging to know the intent of something, But, based on various factors I think this article is about the calling technology; not chunking. For example, a graphical language allows chunking via visual things; shapes or something. That is chunking, but clearly not what this article is about. I also don't think this is about a more general concept of chunking. The callable nature seems to be central to this article. Notice how it gets into gory details of call/return, call stack and such. This is about calling ... which today implies chunking ... although in some older languages it didn't involve chunking. ... Including a short bit on chunking seems like a good addition since it is part of the modern concept of a callable. ... I do think the article is about the concept of function, but only in a modern sense of the word. Way back, other terms were used, but now function is a common term to use for anything that is callable. It is an overloaded word for sure. Function means lots of things. Further, terms like subprogram, subroutine, routine are not common today although used to be. Stevebroshar (talk) 11:06, 17 February 2024 (UTC)

Many thanks for this clarification, @Stevebroshar. I understand you as saying that in this article the term function is not used in the sense of functional programming or in the sense of mathematical function, but in some broader sense that includes the notion of function in functional programming. In particular, it includes, for example, the use of predicates in the procedural interpretation of logic programs. If so, then maybe it would be good to add something along these lines to the article. As it currently stands, the topic of the article may be easily misunderstood. Robert Kowalski (talk) 09:57, 18 February 2024 (UTC)

See for example: https://en.wiktionary.org/wiki/function. Note that the first definition is

• "What something does or is used for. Synonyms: aim, intention, purpose, role, use."

The sixth and seventh definitions are

• "(mathematics) A relation in which each element of the domain is associated with exactly one element of the codomain. Synonyms: map, mapping, mathematical function, operator, transformation
• (computing) A routine that receives zero or more arguments and may return a result. Synonyms: procedure, routine, subprogram, subroutine, func, funct"

in that order. Robert Kowalski (talk) 14:49, 18 February 2024 (UTC)

Yes. #7. Interesting that it starts with 'routine' which seems to be one of the rarest used synonyms. But, that definition is just what this article is about: a thing that has all those names. A thing that does not have just one name that is commonly used and separate from other words. The term 'function' is correct, but it is highly overloaded which of course leads to confusion. This page used to be named 'subroutine', but was renamed in 2022 or something. I think that change was a not good. I also think that 'subroutine' is not a good name since it is so rarely used today. ... This article is about the mechanics of calling -- a technology that probably is much older than the concept of functional programming. The technology surely is used in functional programming, but at a lower level of abstraction. ... Maybe this article should be called 'Function call'. Stevebroshar (talk) 08:10, 19 February 2024 (UTC)

When your $3 book arrives in the mail, you'll see on page 141 why Function call is incorrect. The article's current title is correct. Timhowardriley (talk) 10:58, 19 February 2024 (UTC)

What about:

In computer programming, a function, subprogram, procedure, method, routine, subroutine, is a callable unit that has a well-defined behavior and can be invoked by other software units to exhibit that behavior. Robert Kowalski (talk) 11:04, 20 February 2024 (UTC)

I like it. ... even though I think it's inappropriate or something like that :( I did find that NIST reference for callable unit, but... it's not a common term and I think that's relevant. I wish it was common, but my wishing does not make it so. It's an obscure reference that happens to be from a non-obscure publisher. I'm not going to change it though. Maybe this reference will lead to its integration into the lexicon; something wikipedia is not supposed to do ;) Stevebroshar (talk) 14:49, 23 February 2024 (UTC)

Tim: still waiting for its arrival. Stevebroshar (talk) 14:50, 23 February 2024 (UTC)

In Mathematics, it is common for a text to begin with a discussion of nomenclature, explicitly steting which of several different conventions is used. IMHO, doing the same thing in Wikipedia articles would be desirable. It doesn't much matter whether the article uses the terms extenal unit, procedure or routine, as long as it notes the existence of alternative nomenclature and is consistent.

Another concept that requires clear nomenclature is the components of a callable unit. Using line is misleading, since a line of source code may contain multiple statement and conversely a statement may spread over several lines. This applies equally to functional and procedural languages. I suspect that it also applies to rule-based languages. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:26, 16 February 2024 (UTC)

About 'line': I agree that line can be misleading since some languages allow multiple statements on a line. But ... some don't. I think BASIC does not so talking about lines is OK. Could use statement with BASIC I guess. I'm curious to read the part(s) with 'line' that you think are misleading. Stevebroshar (talk) 11:12, 17 February 2024 (UTC)

Yes, in the sections on BASIC the term line is probably okay. However, it is more problematical in #Inlining and #C and C++, since a single line may contain many statements. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:28, 20 February 2024 (UTC)

References

All the names

@Meownium This article is a PITA due to all the different names that have different meaning, but all refer to something that is so very core to programming ... that itself does not have a general name. The article uses callable unit but it's not generally accepted. It's used as a way to refer to the more general concept. The article is named function even though it's _not_ the most general term. It just happens to be very commonly used today. The article used to be called subprogram.

IMO and due to historical reasons it seems valuable to leave in Subprogram was used long ago but today is antiquated.

WRT adding subprogram to the part about routine/subroutine being like [sub]directory I think is inaccurate. It seems routine and subroutine are a pair like directory and subdirectory. Seems subprogram is not related to [sub]routine in that way. Seems subprogram is related to program in that same way. Stevebroshar (talk) 18:32, 26 June 2024 (UTC)

I don't think it's perfectly valid to call "subprogram" an antiquated term as it's still used (though, not as frequently as the other terms featured in the article); but your assessment on roping it in with subroutine/routine is definitely true. I'll go ahead and revise, thank you for the input! Meownium (talk) 00:35, 27 June 2024 (UTC)

Who uses subprogram? Stevebroshar (talk) 10:31, 28 June 2024 (UTC)

https://www.adaic.com/resources/add_content/standards/05rm/html/RM-6-4.html

https://llvm.org/doxygen/classllvm_1_1DISubprogram.html

https://www.ibm.com/docs/en/xffbg/121.141?topic=procedures-function-subroutine-subprograms

Admittedly, not many. Meownium (talk) 01:42, 29 June 2024 (UTC)

I edited it again since there were multiple grammatical errors and overly wordy. Concise is good. I've tried to keep all concepts that you added. Stevebroshar (talk) 13:39, 28 June 2024 (UTC)

What about iterators?

What about iterators, specialized coroutines used, e.g., to control loops? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:44, 27 June 2024 (UTC)

An iterator is not a function. It's (basically) an object. Or maybe you mean like C# iterator method. Stevebroshar (talk) 10:30, 28 June 2024 (UTC)

Generators then. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:30, 28 June 2024 (UTC)

The 2nd sentence of that article: "All generators are also iterators." so same deal. Routines are ubiquitous and used in implementing many things, including these constructs. - R. S. Shaw (talk) 18:42, 28 June 2024 (UTC)