Talk:Function (computer programming)/Archive 1

Archive 1

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

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.

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 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)

flagrant use of weasel words

in an entry on computer science? wtf? 12.108.188.134 (talk) 19:26, 1 December 2009 (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)

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://en.wikipedia.org/w/index.php?title=Subroutine&curid=32177451&diff=516519142&oldid=510553280

this page wasnt helpful, i made this edit -- http://en.wikipedia.org/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)

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)

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

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

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)