Talk:Call a function: Difference between revisions

m
(I don't think that we should split the task. However, we could cross reference.)
 
(13 intermediate revisions by 4 users not shown)
Line 2:
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. --[[User:Dgamey|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. [[User:Markhobley|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? --[[User:Rdm|Rdm]] 14:51, 15 July 2011 (UTC)
Line 20 ⟶ 18:
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?) –[[User:Dkf|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 namenamed parameters, we could say: "This language supports [[Named parameters|calling a function using named parameters]]", with a link to the appropriate explanation. [[User:Markhobley|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 {{tmpl|collection}} or similar. --[[User:Short Circuit|Michael Mol]] 01:47, 17 July 2011 (UTC)
 
== Operators ==
 
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. [[User:Markhobley|Markhobley]] 18:21, 17 July 2011 (UTC)
:That is the point. In Perl 6 all operators <i>are</i> 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 <i>generally</i> a separate concept in other languages doesn't make it specifically true in Perl 6. The true name of the binary addition operator is <tt>infix:<+></tt>, 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. --[[User:TimToady|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. [[User:Markhobley|Markhobley]] 06:34, 18 July 2011 (UTC)
:::Hey, I found some notes entitled "Metaoperators", that explains this operator/function stuff. Cheers all. [[User:Markhobley|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 <tt>infix:<+></tt> 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.
:::Wow! Excellent. I am looking forward to learning this. Cheers. [[User:Markhobley|Markhobley]] 16:50, 18 July 2011 (UTC)
== What is using a function in a command context?==
Maybe I haven't had enough coffee, but I'm not sure what this means or how it's different from normal calling. --[[User:Dgamey|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? [[User:Markhobley|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. --[[User:Dgamey|Dgamey]] 17:52, 19 July 2011 (UTC)
:: I've changed this to read "statement context". [[User:Markhobley|Markhobley]] 18:45, 19 July 2011 (UTC)
Anonymous user