Talk:Call a function

Duplication?

I'm fairly certain that this is duplicative of a number of tasks or parts of other taks. If the distinction is just to show calling and not the mechanism, I suggest the requirement include referencing the other tasks or omits as appropriate. --Dgamey 03:26, 15 July 2011 (UTC)

Some languages have different mechanisms for functions and subroutines, and the Function definition task did not consider calling a function. This task provides a centralized comparative reference for all of the calling mechanisms. I know other tasks may utilized mechanisms that are used in other tasks, but this does not necessarily help with comparison of sub methods, because different approaches to a solution may have been used, so the sub methods are not present in the solution, even though they are supported by the language. To find out how to call a function, we really need a task that demonstrates this. Markhobley 14:23, 15 July 2011 (UTC)

Huh?

In some languages, at least, there are multiple ways of doing things -- especially something so basic as "calling a function". Is the intent of this task to show typical use? Or is it a much larger task of showing various or all possible ways of accomplishing these tasks? Also, what is a "function" if the language spec does not use the term -- is it "anything that can be said to be equivalent to the mathematical concept of a function?" (or some constrained version of that -- if so, what kind of constraints are we talking about here?) or is it "anything that can be said to be equivalent to language X's concept of a function?" (if so, what is X?) or is it some other concept which is independent of language X? --Rdm 14:51, 15 July 2011 (UTC)

It's a larger task that shows multiple ways of doing things Markhobley 15:38, 15 July 2011 (UTC)

I was hoping for a little more than that. For example: Calling a function that requires no arguments is a confusing concept, mathematically. Is a constant a "function that requires no arguments"? Is an operation which produces different results at different times really a function that requires no arguments? Is it even a function? (In some languages it would not be a function, according to the concepts laid out in the documentation for those languages. And, perhaps ironically, languages with this character tend to be called "functional languages".) --Rdm 18:07, 15 July 2011 (UTC)

So this really comes down to a complaint that mere mortals do not use terms the way mathematicians do. And perhaps that too many mere mortals, who think that "functional" means "does something", are allowed to use computers. :-) --TimToady 18:32, 15 July 2011 (UTC)

Maybe? But my real gripe is that this distinction hasn't made it into the task description. --Rdm 18:44, 15 July 2011 (UTC)

I think it's quite obvious which meaning of "function" is intended here: "a function is something you call". Nobody should have a corner on the One True Vocabulary on a site like RosettaCode. --TimToady 18:55, 15 July 2011 (UTC)

Maybe. But, I think that that reasoning conflicts with the Some languages have different mechanisms for functions and subroutines bit from the first part of this talk page. That said, right now, given your reasoning, I am leaning towards the "anything that can be said to be equivalent to language X's concept of a function" concept of "function", where X="ZX Spectrum Basic". --Rdm 19:02, 15 July 2011 (UTC)

A constant is not a function. Functions may produce different results at different times, whether or not they require arguments. For example time related functions, random functions, or device control functions may return different results at different times. Markhobley 19:12, 15 July 2011 (UTC)

In stateful languages, a function that takes no arguments is an entirely relevant concept; the environment may still vary. Purely stateless functional languages would of course have no-argument functions be constants. It's all a matter of how explicit things are made, and that is something that language designers (and their groupies) have argued over uselessly for many years. –Donal Fellows 14:48, 16 July 2011 (UTC)

Personally, I was concerned about documenting a language with state which offered two different kinds of concepts of "a function that takes no arguments": constants being one kind of concept, and ignoring the argument list (or requiring it be empty) being the other kind of concept. And since the description assumed details about the implementation language, rather than spell them out, it was not obvious to me whether I should be documenting both kinds of concept. The responses here, however, suggested that I not document how to call constants. --Rdm 15:04, 16 July 2011 (UTC)

My “Huh?” about this task is that it asks for all sorts of things rather than being something more focussed, making it awkward to properly deal with from the perspective of someone trying to an implementation or from someone looking things up. Would it be better done as multiple sub-tasks? (How many of those sub-tasks actually exist already?) –Donal Fellows 14:54, 16 July 2011 (UTC)

I don't think that we should split the task. However, we could cross reference to another task where an appropriate explanation is given. For example, if a language supports named parameters, we could say: "This language supports calling a function using named parameters", with a link to the appropriate explanation. Markhobley 16:31, 16 July 2011 (UTC)