Talk:Call a function

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)

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)

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)

Splitting the task is probably appropriate, just based on Donal's note. You might split it as a set of closely-related tasks, with subpages. Such as Call a function/something specific. Or you might use a category to group them. Or you might play with {{collection}} or similar. --Michael Mol 01:47, 17 July 2011 (UTC)

Operators are generally a separate concept from functions (and outside the scope of this task, unless they are called in the same way as functions, can be used in place of functions, or are needed to demonstrate a method of invoking a function). I notice that the perl6 examples contain explanations relating to operators. I don't know perl6, but presumably, these need to be extracted and moved to a task that describes operators and their utilization. Markhobley 18:21, 17 July 2011 (UTC)

That is the point. In Perl 6 all operators are functions. They can be called in the same way as functions, can be used in the place of functions, and as such are needed to demonstrate a method of invoking a function. Just because operators are generally a separate concept in other languages doesn't make it specifically true in Perl 6. The true name of the binary addition operator is infix:<+>, and that can be used anywhere any other function name can be used. The fact that the very same routine can also be called as an infix operator does not change the fact that it is fundamentally a function call. And the whole point of this task is to show all the ways you can call a function, not just one particular way that is already well documented in other tasks. So I will resist strongly the suggestion that we pretend one of Perl 6's fundamental unifying principles isn't there, when that is precisely one of the things that makes Perl 6 different from other languages, and should be documented right here. --TimToady 00:48, 18 July 2011 (UTC)

Ok, cheers Tim. If that is the case, then I agree it was right to document it here. Like I say I don't know the language. Out of interest, if an operator is a function, can it be redefined? Is there an example of say, a redefinition of an addition function that is used for the addition operator? I plan to learn Perl 6 in future, when the compiler rolls down into Debian stable. Markhobley 06:34, 18 July 2011 (UTC)

Hey, I found some notes entitled "Metaoperators", that explains this operator/function stuff. Cheers all. Markhobley 06:42, 18 July 2011 (UTC)

Yes, that's one of the nice things about treating operators as functions: they end up lexically scoped just like functions, and obey the same shadowing and/or multiple-dispatch rules. So if you define your own infix:<+> it can either override or cooperate with any outer definitions of that operator. And even the metaoperators are just calls to higher-order functions underneath. These translations happen very early in the compilation; in a sense, all operators in Perl 6 are just convenient macros that rewrite the AST to a purer FP and/or OO form, and then either the early-binding lexical rules or the late-binding inheritance rules control which function gets called. We're pretty happy with how simple this foundation turned out, given everything we're trying to build on top of it.

Maybe I haven't had enough coffee, but I'm not sure what this means or how it's different from normal calling. --Dgamey 16:37, 19 July 2011 (UTC)

dosomething() or call dosomething(), as opposed to returnvalue=dosomething(). The function is used as an instruction (with a void context), rather than used within an expression. Does that make sense? Markhobley 17:17, 19 July 2011 (UTC)

Okay, I thought it might just be wording, I had that form in another mental bucket. More like a procedure call to me. Thanks. --Dgamey 17:52, 19 July 2011 (UTC)