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)

New stuff

"however, the C programming language and its programmers view subroutines simply as functions that do not return a value."

The one thing in life that frustrates me most is arguing over definitions, so this is just a thought. I'm a (mostly) self-taught C programmer, so I have very little use for terminology, but what about functions that return only success or failure... Would they not be considered a sub routine?

--The Extremist

Returning a boolean is still returning a value. IMHO. --Mike Van Emmerik 03:51, 12 May 2005 (UTC)

indeed

Return address

"The IBM 360 range used to save this address in a register, relying on macros to save and restore deeper return addresses in memory associated with individual subroutines, then using branches to the address specified in the register to accomplish a return. However stacks have proved a very useful approach, and are typically used in more modern architectures."

Sorry, that's the fashion again. Push/pop architectures like the Pentium are now obsoleted by RISC and VLIW machines (e.g. SPARC, PowerPC, Itanium, etc) that use a link register to store the return address, which has to be saved by non-leaf subroutines. Push and pop instructions aren't always used even when available, e.g. see Pentium code generated by the MLton compiler. It subtracts a constant from the stack pointer for every call, and all local variables and also outgoing parameters are handled as offsets from the stack pointer. Even return instructions are replaced by a branch indirect on an offset from the PC. Presumably they do this for speed, but it may just be easier to write RISC-like code for all target machines. In any case, it's simply not true to say that the more modern machines prefer to use stack instructions. Pentiums only have stack instructions because of backwards compatibility to the 8086 (at the binary level) arguably the 8008 (at assembly language level). I don't have time for this right now, and would also like to seek confirmation on this point.

--Mike Van Emmerik 03:51, 12 May 2005 (UTC)

Yes, the link register has come back into fashion -- many RISC machines have a link register to store the return address. (I've done a bit of ARM assembly language programming -- ARM was post-8086, right ?).

However, we *are* still using a stack -- a stack is necessary for recursive subroutines.

Um, NO. Continuation passing style has been used for years in Standard ML compilers, and SML uses recursion almost exclusively as the control-flow of choice. --bmills 18:34, 24 October 2005 (UTC)

We're not going back to the bad old days of the MIX and other machines that required self-modifying code. Those machines begin each (non-leaf) subroutine by overwriting the address in the "jump" instruction at the end of a subroutine with the value of the link register. Are you sure that "return instructions are replaced by a branch indirect on an offset from the PC" ? Because that sort of thing makes recursive subroutines impossible. I might believe you if you said "branch indirect on an offset from the SP", because that is still (effectively) a stack. --DavidCary 05:55, 16 July 2005 (UTC)

However, we *are* still using a stack -- a stack is necessary for recursive subroutines.

Agreed.

I might believe you if you said "branch indirect on an offset from the SP", because that is still (effectively) a stack.

Sorry, that is what I meant.

My point was this: RISC machines have no more hardware support than what the IBM360 had (ability to copy the program counter to a register). I assumed that this means that the IBM used a stack... if not why not? --Mike Van Emmerik 13:46, 17 July 2005 (UTC)

No, the 360 calling convention did not use a stack. See the Overview in this article at Everything2 and/or the History section of this 390 linkage pdf.

The 360 hardware architecture was excellent (in historical context), but the software wasn't. Of course the hardware could support a call stack, but they explored piles of calling convention kludges instead.

Why did they do that? Hard to say; ignorance is my best guess. You might get some insight from Stack? S/360 don't need no stinkin' stack!. I think in part it was overreaction to the Burroughs stack approach (B5000). This is suggested by the "Pushdown stack vs address registers" discussion in Amdahl's 1964 "Architecture of the S/360" paper. It says "Subroutine transparency ... is one of the apparent advantages of the stack. However, the disadvantage is that the transparency does not materialize unless additional independent stacks are introduced for addressing purposes" (whatever that means). -R. S. Shaw 20:02, 17 July 2005 (UTC)

OK, thanks for all the info. I've now cleaned up the part which I was objecting to (i.e. that RISC machines have somehow "reverted" to the bad old days of the IBM 360). --Mike Van Emmerik 04:14, 18 July 2005 (UTC)

Subroutines and Methods

Aren't subroutines and methods pretty simliar? If so, I think each article should mention the other one to some degree. -Hyad 2 July 2005 23:26 (UTC)

I actually think that merging the article 'Function Stack' with 'Subroutine' is a good idea. I also think that the page describing a 'Subprogram' should be reintroduced. --Anonymous 16:20, 15 July 2005 (UTC)

Actually they can be similar or dissimilar (if I understand the termonology) depending on the language you use.

A method can be called a function or subroutine (and in other languages it is once again different) but thow in an object oriented language and you have something different. The method implements variables that modify an object. Normally methods would just return varibles or modify something, but that is language depenent.

Subroutines and parameters

I think that the Parameter (computer science) article ought to be dropped and redirected to this article. Please see the comment on Talk:Parameter (computer science). —Preceding unsigned comment added by Donhalcon (talk • contribs) 07:14, 23 October 2005

What? No. Parameters are vaster then simple methods, although the article doesn't seem to explain that. Look, if you have an equation the parameters of that equation are what go in to fill (ex) x, y, and z. The Parameter artile needs a re-work, but it should not be incorporated into a single article

Furthermore, the separation of facts is nessicary for a working encyclopedia. You wouldn't combind Time with Watch just because of the similarities. Or god with devil because they exist within the same idea. The more separated objects are the better.

http://www.answers.com/parameter&r=67

A parameter is something that is passed to the subroutine. They are separate concepts. Poppafuze 06:04, 28 September 2006 (UTC)

Proposal to merge section from Control Flow article into Subroutine article

Currently, the Subroutine section in Control flow and the Subroutine article are both covering the same topic. When a section summarises the content of a linked article, it should be a short summary and should not include any significant content that is not in the linked article - this is not currently the case at all. The section in Control flow on subroutines is not short, it is not a summary, and it contains content that is not in the main article. Any objections to this proposed merge?—greenrd 13:20, 27 May 2007 (UTC)

I am surprised to hear a claim that these articles are covering the same subject. If they read as if they are covering the same subject then some rewriting is needed. I have read them and don't think they read as if they are covering the same subject. Derek farn 15:01, 27 May 2007 (UTC)

Perhaps I was not sufficiently clear. I am talking about the Subroutine section in the Control flow article, not the entire Control flow article. Both that section and the Subroutine article are talking about the same subject, subroutines...—greenrd 16:47, 27 May 2007 (UTC)

You were sufficiently clear, but I was insufficiently switched on. Good call. Do the merge. Derek farn 19:24, 27 May 2007 (UTC)

What is "Clean Code"

There has been a lot of activity today regarding what is "good form" or "clean." I would like to raise the point that Wikipedia does not accept original research and thus we can't just blatantly state what is or is not "good form." Citations will need to be laid out. Furthermore, to follow WP:NPOV, we need to handle all sides of the argument (what is and is not "good form" is highly controversial), which to be honest is outside of the scope of this article in the first place. Accordingly, I really don't feel this is appropriate for this article. Feel free to disagree/discuss. --Mpdelbuono (talk) 03:31, 27 November 2009 (UTC)

For the record, these are the two sections which were proposed (I have since removed it per the above, pending this discussion):

 ==Disadvantage==
  Code is easier to understand when it is written linearly.

 It is good convention to put subroutines before and call them in the main body of code after (rather than the other way round).
 Functions in languages such as C depend on this, whereas newer languages such as C# also allow methods to be placed afterwards as well.

--Mpdelbuono (talk) 03:36, 27 November 2009 (UTC)

I will explain why I added this. Code is naturally going to be easier to read when you don't have to skip back and fourth through sections.

Much of this article, including the "advantages" section is not cited. I thought we could at least manage one uncited disadvantage!

It's good convention because it maintains compatibility and makes sense logically. Putting subroutines before the main body works in most languages, whereas putting subroutines afterwards works in fewer languages. Of course I can't cite original research.--81.154.146.7 (talk) 03:54, 27 November 2009 (UTC)

As I mentioned earlier, the statements you are making are entirely based off opinion and original research. Neither of these are appropriate for a neutral encyclopedia. I believe that what you are saying is a valid viewpoint, however, it is also highly controversial. If you want to include this content you really need to (1) ensure that both sides of the argument are handled equally, and (2) you cite sources indicating that people really believe in this. It is important to point out that the very fact that we are having this debate right now implies that there must be some sort of controversy in your statements, and to be frank, I strongly believe that, in C, putting main() before other functions is preferable because it is the logical flow of the program. I could continue to rant on about reasons against what you're saying, but that's really not the subject of this talk section. The actual content isn't as important as it is to minimize the controversy associated with the content. Simply adhere to the policies WP:NPOV and WP:NOR and I will have no objections to these statements. --Mpdelbuono (talk) 03:59, 27 November 2009 (UTC)

No, in C, if you put main() before the functions in the program, the program will not work. In C# you can put methods before and after. I'm glad you understand my point. I don't think what I wrote was controversial ... it just makes sense. Anything is going be easier to read linearly than not. I really can't be bothered to go looking for references for this kind of thing. I think I might delete the advantages section because it's unsourced and controversial.--81.154.146.7 (talk) 04:08, 27 November 2009 (UTC)

Consider the following code:

 void foo();
 int main()
 {
    foo();
    return 0;
 }
 void foo() 
 {
    // Do something here
 }

This is perfectly legal C code, and honestly what I prefer. However, what I prefer is not in question here. What is more important is that there is a debate over what is clean and what is not. You certainly have the right to remove the "Advantages" section, but I would argue this would be a better place for {{citation needed}}. The difference with the "advantages" section is that there isn't controversy associated with most of those statements. You can't really argue subroutines don't "[reduce] the duplication of code within a program" because, quite frankly, that's what they do, plain and simple. The difference between your "Disadvantages" section and the currently-existing "Advantages" section is that your "Disadvantages" section is controversial and needs to hold up to both sides of the argument.

That being said, you do raise a valid point. I think it is fair to argue that some parts of the "Advantages" section are also controversial and either need a corresponding counter-point or need to be removed. --Mpdelbuono (talk) 04:14, 27 November 2009 (UTC)

Hmm, I will get round to testing that code. May I ask why you have "void foo();" at the top?

I won't delete the Advantages section ... but the thing which gets me most was the "readability" part. This is what provoked me most. Things are most certainly easier to read linearly and that is a disadvantage.

I don't know how to ask for a citation so could you please? —Preceding unsigned comment added by 81.154.146.7 (talk) 04:22, 27 November 2009 (UTC)

Yeah ... your code worked. I found out what the "void foo();" at the top does. It declares the sub routine. It has to be put before main() and hence, the code below did not work.

int main()
{
   foo();
   return 0;
}
void foo();
void foo() 
{
   printf("hello");
}

--81.154.146.7 (talk) 04:36, 27 November 2009 (UTC)

Well of course it didn't work, because main() is not aware of foo() at the time. However, that's not really the argument here. The point is that there are multiple ways to do this, and both of them have strong arguments for and against. Hence, the controversy and why we must be careful when editing Wikipedia to ensure that both sides are considered, and not to bias either side.

Regarding requesting a citation, it's very simple. All you have to do is add the code {{citation needed}} after the statement and Wikipedia will handle the rest. You can do this anywhere you feel a citation is warranted. I totally agree with you regarding readability being potentially controversial. Per your request, I will be more than willing to do this on your behalf.

I totally understand, after reviewing the content, why you would think what you posted would be accepted without dispute. I hope, as well, you now understand why I personally (and probably others, though I cannot speak for them) disagree with what you posted. However, I hope that we can come to a mutual agreement over how to add your content without inciting a controversy. Naturally, Wikipedia relies on points of view from many varying and unique authors, so without contributions from people like you, this would never have even been considered, perhaps. Now, with some work, we can get that added without violating policies and guidelines. I'm totally willing to work with you to reach that goal. --Mpdelbuono (talk) 04:45, 27 November 2009 (UTC)

As a note, I have now added this article to my list of things to be worked on in an effort to go through and try to link the article to existing publications to justify the statements. --Mpdelbuono (talk) 04:50, 27 November 2009 (UTC)

Thank you. I just hope people are interested in creating studies for where subroutines can and can't be defined for different languages in relation to the main body of code. I also hope people are interested in creating studies to show whether linear code is easier to read than non-linear code. In the mean time, I would strongly advise people to put there subroutines before the main body like so:

[CODE]

void foo() 
{
   printf("hello");
};
int main()
{
   foo();
   return 0;
}

[/CODE]

...even if it isn't on the main page. peace. —Preceding unsigned comment added by 81.154.146.7 (talk) 05:05, 27 November 2009 (UTC)

I have finished this by adding citations to the relevant locations which were of concern before. Please feel free to review them. --Mpdelbuono (talk) 00:29, 29 November 2009 (UTC)

In the citation, I couldn't find the author saying that an advantage of using a subroutine is to improve the codes readability? Could you point me in the correct direction? --86.130.42.219 (talk) 02:57, 29 November 2009 (UTC)

Okay, I'm deleting some of the points given in the advantages section. It is based on a subjective bias and the citation you gave does not actually match the points given in the section. --86.153.19.120 (talk) 17:58, 6 December 2009 (UTC)

flagrant use of weasel words

in an entry on computer science? wtf? 12.108.188.134 (talk) 19:26, 1 December 2009 (UTC)

History needs updating + too low level

This subroutine history is far better on the early history of subroutines. The idea of subroutines was there pretty much from the beginning and both Turing and Zuse provided special hardware to support them. Arguably Ada invented the concept. I also believe much of the text here could be moved to the Self-modifying code and Call stack articles instead and this article made a bit more high level. Dmcq (talk) 14:54, 6 December 2009 (UTC)

There is also a claim that not Mauchly but hist programmer Kathleen Antonelli (they were later married) came up with subroutines while working on the trajectory calculating programs on ENIAC. That claims also appears here: http://fortune.com/2014/09/18/walter-isaacson-the-women-of-eniac/ in any case Turing had probably already published. Mwasheim (talk) 11:01, 18 December 2018 (UTC)

NO mention of pre and post conditions

No discussion of "function" is complete with mention of preconditions and postconditions. — Preceding unsigned comment added by 74.85.3.146 (talk) 03:40, 2 June 2011 (UTC)

this page wasnt helpful, i made this edit -- http://wiki.riteme.site/w/index.php?title=Subroutine&curid=32177451&diff=516519142&oldid=510553280

this page wasnt helpful, i made this edit -- http://wiki.riteme.site/w/index.php?title=Subroutine&curid=32177451&diff=516519142&oldid=510553280 — Preceding unsigned comment added by Coginsys (talk • contribs) 10:39, 8 October 2012 (UTC)

Your change was reverted (twice) because it wasn't as clear and meaningful as the version that was there before. - David Biddulph (talk) 13:02, 8 October 2012 (UTC)

Calling conventions

I was going to add something about call by name and found there's no general discussion of argument passing, only specific language instances. Looking at this talk page I read

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)

I agree that the article needs some work. Peter Flass (talk) 13:44, 14 January 2013 (UTC)

I added a table on argument-passing conventions. I didn't cite a source because I found so many and synthesized this using several of them. Peter Flass (talk) 13:45, 15 January 2013 (UTC)

Proposal for new article: function(computer programing)

Subroutine could become a redirect. Function is a broader term. Python does not have subroutines. Functions that do not specify a return value return None (python's null value)Panpog1 (talk) 00:49, 7 May 2013 (UTC)

Function is not a broader term than subroutine; in fact in many contexts it would be considered narrower. A subroutine may or may not be defined to return a value. If it does not return a value, it is not a function. In interpretive languages like Python, all subprograms are functions and have some convention for cases which do not return explicit values, substituting a value like "None" or 0 or "Undefined". In those contexts, these are functions whose result range includes that value. But in most compiled languages, non-value-returning subroutines simply have no location designated for returning a value. If there is to be only one article, it should be Subroutine as that does best at capturing the computational ideas involved; the term function tends to evoke the mathematical concept, which is related but misleading. --R. S. Shaw (talk) 06:23, 10 May 2013 (UTC)

I agree with R. S. Shaw a function is not a broader term than procedure call. In a formal sense a true function is not just a procedure that returns a value. It's a procedure that does not modify any external variables. Even many of the functions in Lisp aren't truly functions in the formal mathematical sense. But the more important issue is that procedure call is more general than function is. I also think the intro text to this article is wrong and should be changed. It describes "function" and "procedure call" as if they are synonyms when as we just described they are not. --MadScientistX11 (talk) 15:41, 10 December 2014 (UTC)

I suppose by "formal sense of a true function", you mean a mathematical function, and that is a different concept, thus OP use the term "function (computer programming)" to distinguish with that. In modern popular languages the word function is interchangeable with subroutine, it can have side effects, modify states, and be void valued. Since "function" is a more popular term than "subroutine", it is more appropriate to called this article function(computer programing).Golopotw (talk) 10:45, 3 November 2020 (UTC)

I'm not convinced it should be a separate article, but certainly the gist of this discusion should be in the subroutine article. Peter Flass (talk) 18:59, 10 December 2014 (UTC)

Yes, it's always easier to kvetch and kibitz then to actually edit and fix ;-) I agree. There isn't enough good content here to even consider branching off a new article and it would be good to clarify the actual distinction between functions, procedures, etc. If no one else does it I'll take a shot at it although I'm working on some other things right now but I'll keep this on the stack but if someone else wants to take it please feel free. --MadScientistX11 (talk) 19:29, 10 December 2014 (UTC)

I would also like to see a section on pure functions, etc. It could briefly explain the concept, then link to the Functional Programming page. RichMorin (talk) 21:22, 30 March 2015 (UTC)

I learned programming in the 1960s when most programming was in assembly language. My view is that a function is a subroutine that returns a value and may be used in an expressio. A subroutine is more general including all code that may be called to perform some operation. A pure function does not change variables used by code outside the function.

I think this article should be simplified. It is a technology that is a part of several other higher order concepts. Subroutines may be simply local, coded as part of a program. They may be part of a package linked with a program. Support function that interface with an operatoring system. Part of a high level language support library.Steamerandy (talk) 21:44, 21 August 2016 (UTC)

@Panpog1, Steamerandy, RichMorin, Golopotw, and Peter Flass: I actually agree with Panpog1. The semantic distinctions between subroutines and functions are sometimes language specific, and trying to come up with a universal distinction between these similar concepts makes for relatively intractable articles for lay-readers. CessnaMan1989 (talk) 02:01, 5 November 2021 (UTC)

• I disagree that function(computer programing) should be created. Functions fit as a section in this article. A subroutine is getting sidetracked in any language, including those that don't support functions. (In classic BASIC, you would goto a subroutine and then goto back.) A function is getting sidetracked with special characteristics. Therefore, a function is a subroutine. Timhowardriley (talk) 04:49, 5 November 2021 (UTC)

• In Rexx I can write a procedure that sometimes returns without a value and sometimes returns with a value. Is such a procedure a function or a subroutine?

• /* is it or isn't it */
  call foo 2,3 /* valid */
  bar = foo(3, 4) /* valid */
  call foo 4, 5, TAG /* valid */
  bar = foo 5, 6 /* invalid */
  exit 0
  
  foo: procedure
  parse arg left, right, display
  baz = left+right
  if display = '' then
     return baz
  else 
     say display':' baz
  return
  

  --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:39, 5 November 2021 (UTC)

Notes

Incorrect chronology

Subroutine#History has an incorrect chronology. The text claims Some very early computers and microprocessors, such as the IBM 1620, the Intel 4004 and Intel 8008, and the PIC microcontrollers, have a single-instruction subroutine call that uses a dedicated hardware stack to store return addresses—such hardware supports only a few levels of subroutine nesting, but can support recursive subroutines. Machines before the mid-1960s—such as the UNIVAC I, the PDP-1, and the IBM 1130—typically use a calling convention which saved the instruction counter in the first memory location of the called subroutine. This allows arbitrarily deep levels of subroutine nesting but does not support recursive subroutines. The PDP-11 (1970) is one of the first computers with a stack-pushing subroutine call instruction; this feature supports both arbitrarily deep subroutine nesting and also supports recursive subroutines.

The IBM 1620 does not have a hardware stack of registers for return addresses; it has a single register, IR-2.

The IBM 1130 was introduced in 1965, not before the mid-1960s.

It is likely that some of the machines I mention below are themselves not the first. The PDP-6 had the PUSHJ instruction well before the PDP-11, and the Burroughs B5000 had stack linkage before DEC. The IBM 704 had the TSX instruction in 1954. The UNIVAC 1103A had a return jump in 1956; unlike later architectures, the return jump on the 1103A specified where to store the return address independently from the address of the subroutine. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:49, 4 July 2021 (UTC)

Notes

References

Added procedures and functions stubs

I added stubs for procedures and functions. The article computer program has a wikilink to functions. Timhowardriley (talk) 18:03, 29 October 2021 (UTC)

• I removed the procedures section stub. Timhowardriley (talk) 20:20, 5 November 2021 (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)