I know what a function call is. I know what it does. I've debugged it a lot. I do have some intuitive sense on why it makes sense to use the term "function call", but when it comes down to it, I can't explain this properly like I could with a return statement.
For example, with a return statement the answer is: it's called a "return" because you return to where you came from. You return to the line from where the function was called. So it makes sense why the end of a function (implicitly or explicitly) returns.
I've noticed that for people who speak English as their native language this easier to grasp (especially with more obscure words such as "cache"). However, for people like me (Dutch, learned English through videogames and subtitled television), it's harder to grasp.
I googled for this question, but I get all kinds of entries what a function call is and how it works. I associate the word "call" a lot with telephones, since that's what I use it mainly for in English.
I asked a similar question on what the "de-" means in the word "dereference" here: What does the de- prefix in dereference mean? Is there a linguistic explanation for it?
The term call has a wide meaning. When used in calling a function, you would probably best interpret that as short for calling a function for execution. See the following meaning given by the Free Dictionary:
To order or request to undertake a particular activity or work; summon:
She was called for jury duty. He was called to the priesthood.
This is very close in meaning to another expression used for invoking functions: call upon a function.
That should make sense in the context of functions. The function provides a service, and it is called upon to provide it now. In both cases the meaning is: request the code in a function to be executed.
NB: In Dutch you may translate with oproepen or (less common) aanroepen.
Thanks to #hvj I noticed that the comments of the really related -- though not the same! Since I want to know it linguistically not historically -- question referenced a paper that was behind a paywall ( see http://dl.acm.org/citation.cfm?id=609816&CFID=888670230&CFTOKEN=46456506 ). I read the paper and then I found this small piece:
In this type of routine it is arranged that a sequence of operations is performed each time the subroutine is called into action.
So apparently the Zeitgeist of that time was phrasing it as calling sub-routines into action. Side note: they also talked about returning control from a sub-routine to the main program.
Related
While finalizing my upcoming Raku Advent Calendar post on sigils, I decided to double-check my understanding of the type constraints that sigils create. The docs describe sigil type constraints with the table
below:
Based on this table (and my general understanding of how sigils and containers work), I strongly expected this code
my %percent-sigil is List = 1,2;
my #at-sigil is Map = :k<v>;
to throw an error.
Specifically, I expected that is List would attempt to bind the %-sigiled variable to a List, and that this would throw an X::TypeCheck::Binding error – the same error that my %h := 1,2 throws.
But it didn't error. The first line created a List that seemed perfectly ordinary in every way, other than the sigil on its variable. And the second created a seemingly normal Map. Neither of them secretly had Scalar intermediaries, at least as far as I could tell with VAR and similar introspection.
I took a very quick look at the World.nqp source code, and it seems at least plausible that discarding the % type constraint with is List is intended behavior.
So, is this behavior correct/intended? If so, why? And how does that fit in with the type constraints and other guarantees that sigils typically provide?
(I have to admit, seeing an %-sigiled variable that doesn't support Associative indexing kind of shocked me…)
I think this is a grey area, somewhere between DIHWIDT (Docter, It Hurts When I Do This) and an oversight in implementation.
Thing is, you can create your own class and use that in the is trait. Basically, that overrides the type with which the object will be created from the default Hash (for %) and Array (for # sigils). As long as you provide the interface methods, it (currently) works. For example:
class Foo {
method AT-KEY($) { 42 }
}
my %h is Foo;
say %h<a>; # 42
However, if you want to pass such an object as an argument to a sub with a % sigil in the signature, it will fail because the class did not consume the Associatve role:
sub bar(%) { 666 }
say bar(%h);
===SORRY!=== Error while compiling -e
Calling bar(A) will never work with declared signature (%)
I'm not sure why the test for Associative (for the % sigil) and Positional (for #) is not enforced at compile time with the is trait. I would assume it was an oversight, maybe something to be fixed in 6.e.
Quoting the Parameters and arguments section of the S06 specification/speculation document about the related issue of binding arguments to routine parameters:
Array and hash parameters are simply bound "as is". (Conjectural: future versions ... may do static analysis and forbid assignments to array and hash parameters that can be caught by it. This will, however, only happen with the appropriate use declaration to opt in to that language version.)
Sure enough the Rakudo compiler implemented some rudimentary static analysis (in its AOT compilation optimization pass) that normally (but see footnote 3 in this SO answer) insists on binding # routine parameters to values that do the Positional role and % ones to Associatives.
I think this was the case from the first official Raku supporting release of Rakudo, in 2016, but regardless, I'm pretty sure the "appropriate use declaration" is any language version declaration, including none. If your/our druthers are static typing for the win for # and % sigils, and I think they are, then that's presumably very appropriate!
Another source is the IRC logs. A quick search quickly got me nothing.
Hmm. Let's check the blame for the above verbiage so I can find when it was last updated and maybe spot contemporaneous IRC discussion. Oooh.
That is an extraordinary read.
"oversight" isn't the right word.
I don't have time tonight to search the IRC logs to see what led up to that commit, but I daresay it's interesting. The previous text was talking about a PL design I really liked the sound of in terms of immutability, such that code could become increasingly immutable by simply swapping out one kind of scalar container for another. Very nice! But reality is important, and Jonathan switched the verbiage to the implementation reality. The switch toward static typing certainty is welcome, but has it seriously harmed the performance and immutability options? I don't know. Time for me to go to sleep and head off for seasonal family visits. Happy holidays...
I want to know when a function body end in assemby, for example in c you have this brakets {} that tell you when the function body start and when it ends but how do i know this in assembly?
Is there a parser that can extract me all the functions from assembly and start line and endline of their body?
There's no foolproof way, and there might not even be a well-defined correct answer in hand-written asm.
Usually (e.g. in compiler-generated code) you know a function ends when you see the next global symbol, like objdump does to decide when to print a new "banner". But without all function-start symbols being visible, there's no unambigious way. That's why some object file formats have room for size metadata associated with a symbol. Like .size foo, . - foo in GAS syntax.
It's not as easy as looking for a ret; some functions end with a jmp tail-call to another function. And some call a noreturn function like abort or __stack_chk_fail (not tailcall because they want to push a return address for a backtrace.) Or just fall off into whatever's next because that path had undefined behaviour in the source so the compiler assumed it wasn't reachable and stopped generating instructions for it, e.g. a C++ non-void function where execution can/does fall off the end without a return.
In general, assembly can blur the lines of what a function is.
Asm has features you can use to implement the high-level concept of a function, but you're not restricted to that.
e.g. multiple asm functions could all return by jumping to a common block of code that pops some registers before a ret. Is that shared tail a separate function that's called with a tail-called with a special calling convention?
Compilers don't usually do that, but humans could.
As for function entry points, usually some other code somewhere in the program will contain a call to it. But not necessarily; it might only be reachable via a table of function pointers, and you don't know that a block of .rodata holds function pointers until you find some code loading from it and calling or jumping.
But that doesn't work if the lowest-address instruction of the function isn't its entry point. See Does a function with instructions before the entry-point label cause problems for anything (linking)? for an example
Compilers don't generate code like that, but humans can. (It's a handy trick sometimes for https://codegolf.stackexchange.com/ questions.)
Or in the general case, a function might have multiple entry points. Or you could describe that as multiple functions with overlapping implementations. Sometimes it's as simple as one tailcalling another by falling into it without needing a jmp, i.e. it starts a few instructions before another.
I wan't to know when a function body ends in assembly, [...]
There are mainly four ways that the execution of a stream of (userspace) instructions can "end":
An unconditional jump like jmp or a conditional one like Jcc (je,jnz,jg ...)
A ret instruction (meaning the end of a subroutine) which probably comes closest to the intent of your question (including the ExitProcess "ret" command)
The call of another "function"
An exception. Not a C style exception, but rather an exception like "Invalid instruction" or "Division by 0" which terminates the user space program
[...] for example in c you have this brakets {} that tell you when the function body start and when it ends but how do i know this in assembly?
Simple answer: you don't. On the machine level every address can (theoretically) be an entry point to a "function". So there is no unique entry point to a "function" other than defined - and you can define anything.
On a tangent, this relates to self-modifying code and viruses, but it must not. The exit/end is as described in the first part above.
Is there a parser that can extract me all the functions from assembly and
start line and endline of their body?
Disassemblers create some kind of "functions" with entry and exit points. But they are merely assumed. No way to know if that assumption is correct. This may cause problems.
The usual approach is using a disassembler and the work to recombinate the stream of instructions to different "functions" remains to the person that mandated this task (vulgo: you). Some tools exist that claim to simplify this, but I cannot judge their efficacy.
From the perspective of a high level language, there are decompilers that try to reverse the transformation from (for example) C to assembly/machine code that try to automatize that task and will work more or less or in some cases.
So I've been Googling function arguments and I would like to understand arguments better.
I am new to as3, to summarize arguments with my current knowledge, I would say they are like temporary variables? I don't fully get why you add parameters which are names that can be any value? Then you like call these parameters later and their order magically replace these parameters, but why? I'm missing some understanding here to fully grasp their use. Why make parameters in a function and then add the values later? If I'm even saying that right.
function name( applepie, sugar, healthyfood)
name( 1,2,3)
What was the point?
Also I haven't found a syntax book that describes what every symbol does yet that I can just search like () and it describes it, I heard some just use Google, but the results I got weren't very fruitful. Hence why I'm here asking. Personally I don't want to continue on until I fully grasps the use of (). I also tried Adobe website search but that didn't work out well either, was a good amount of searches trust me....
A function is a piece of code that can be reused many times in different contexts. You pass arguments to a function to tell the function something about the context in which it is being called; as a trivial example, when you call the print() function you must specify what you want the function to print. In your example name(applepie, sugar, healthyfood) the function should use the value supplied in place of each argument somewhere in its body, because the function doesn't know what values it will be passed, in the body of the function definition you use the names you chose (which should be descriptive) to refer to the values which will be passed in later and which will presumably be different each time it is called.
The parentheses are used for delimiting different semantic elements, in this case they are telling the interpreter where the argument list starts and stops.
This is a language agnostic question, but I'm wandering what people prefer in terms of readability and maintainability... My hypothetical situation is that I'm writing a function which given a sequence will return a copy with all duplicate element removed and the order reversed.
/*
*This is an extremely well written function to return a sequence containing
*all the unique elements of OriginalSequence with their order reversed
*/
ReturnSequence SequenceFunction(OriginalSequence)
{...}
OR
UniqueAndReversedSequence MakeSequenceUniqueAndReversed(OriginalSequence)
{....}
The above is supposed to be a lucid example of using comments in the first instance or using very verbose function names in the second to describe the actions of the function.
Cheers,
Richard
I prefer the verbose function name as it make the call-site more readable. Of course, some function names (like your example) can get really long.
Perhaps a better name for your example function would be ReverseAndDedupe. Uh oh, now it is a little more clear that we have a function with two responsibilities*. Perhaps it would be even better to split this out into two functions: Reverse and Dedupe.
Now the call-site becomes even more readable:
Reverse(Dedupe(someSequence))
*Note: My rule of thumb is that any function that contains "and" in the name has too many responsibilities and needs to be split up in to separate functions.
Personally I prefer the second way - it's easy to see from the function name what it does - and because the code inside the function is well written anyway it'll be easy to work out exactly what happens inside it.
The problem I find with comments is they very quickly go out of date - there's no compile time check to ensure your comment is correct!
Also, you don't get access to the comment in the places where the function is actually called.
Very much a subjective question though!
Ideally you would do a combination of the two. Try to keep your method names concise but descriptive enough to get a good idea of what it's going to do. If there is any possibility of lack of clarity in the method name, you should have comments to assist the reader in the logic.
Even with descriptive names you should still be concise. I think what you have in the example is overkill. I would have written
UniqueSequence Reverse(Sequence)
I comment where there's an explanation in order that a descriptive name cannot adequately convey. If there's a peculiarity with a library that forced me to do something that appears non-standard or value in dropping a comment inline, I'll do that but otherwise I rely upon well-named methods and don't comment things a lot - except while I'm writing the code, and those are for myself. They get removed when it is done, typically.
Generally speaking, function header comments are just more lines to maintain and require the reader to look at both the comment and the code and then decide which is correct if they aren't in correspondence. Obviously the truth is always in the code. The comment may say X but comments don't compile to machine code (typically) so...
Comment when necessary and make a habit of naming things well. That's what I do.
I'd probably do one of these:
Call it ReverseAndDedupe (or DedupeAndReverse, depending which one it is -- I'd expect Dedupe alone to keep the first occurrence and discard later ones, so the two operations do not commute). All functions make some postcondition true, so Make can certainly go in order to shorten a too-long name. Functions don't generally need to be named for the types they operate on, and if they are then it should be in a consistent format. So Sequence can probably be removed from your proposed name too, or if it can't then I'd probably call it Sequence_ReverseAndDedupe.
Not create this function at all, make sure that callers can either do Reverse(Dedupe(x)) or Dedupe(Reverse(x)), depending which they actually want. It's no more code for them to write, so only an issue of whether there's some cunning optimization that only applies when you do both at once. Avoiding an intermediate copy might qualify there, but the general point is that if you can't name your function concisely, make sure there's a good reason why it's doing so many different things.
Call it ReversedAndDeduped if it returns a copy of the original sequence - this is a trick I picked up from Python, where l.sort() sorts the list l in place, and sorted(l) doesn't modify a list l at all.
Give it a name specific to the domain it's used in, rather than trying to make it so generic. Why am I deduping and reversing this list? There might be some term of art that means a list in that state, or some function which can only be performed on such a list. So I could call it 'Renuberate' (because a reversed, deduped list is known as a list "in Renuberated form", or 'MakeFrobbable' (because Frobbing requires this format).
I'd also comment it (or much better, document it), to explain what type of deduping it guarantees (if any - perhaps the implementation is left free to remove whichever dupes it likes so long as it gets them all).
I wouldn't comment it "extremely well written", although I might comment "highly optimized" to mean "this code is really hard to work with, but goes like the clappers, please don't touch it without running all the performance tests".
I don't think I'd want to go as far as 5-word function names, although I expect I have in the past.
let's consider a small method:
int MyFunction(string foo, int bar)
{
...
}
and some calls:
MyFunction("",0)
int x = MyFunction(foo1,bar1)
How would you explain this to a non-technical persons? Has anybody a nice metaphor?
I tried to explain method calling (or function application) several times, but I failed. Seems I can't find the right words here.
Regards,
forki
UPDATE: It is important for me to explain how the parameters are passed / matched.
(Highly non-technical solution)
It's like making an order:
Calling the method = dialing the right number
Passing the arguments = giving your details
the method does is job
Getting a return value = getting what you ordered
You could tell function is a process available into an object that could be called by other. Lets say "You" is an object with function "Work". Your "Boss" is the caller object. Your Boss then can call you to Work with different type (which is parameter).
In the end Your "Boss" can ask "You" to Work("encode this") or Work("check email") or Work("finish deadline"), etc.
How about delegating a task? Imagine you’re baking a cake and ran out of flour. Instead of buying some yourself you could just send your kid with instructions to buy flour. Input: money, output: flour.
It's difficult to understand the "method call" concept if you don't understand first the
flow of control.
A simple explanation is that methods, or routines, is a construct for packeting instructions
in order to reuse them and make the code more readable.
Calling a method, temporarily, switches the execution flow to that method.
C:: do(a ,b)
You are telling C to do something , given the condition a and b.
The best approach is probably to come up with a domain specific example which the person you are explaining to can relate to. If she is working with the post office, you should describe the function "send letter with this text to this recipient", where recipient is a parameter (containing the address) and message is the parameter for the textual content.
Parameter order is not important as long as you have a name for each parameter. Trying to explain why order is important in some arcane programming language is fruitless.
How about
Calling a function: Ask the software to perform xxx task
Returning value type function: Ask your software to perform xxx task and tell you the outcome of the operation
Calling a function with param: Given X is this value and Y is thisvalue, ask your software to perform xxx task (and tell you the outcome of the operation)
Think of the system as a teller at a desk. To call a function you fill in a form to ask the system to do something, hand it to the teller. They go off and do the work, then hand you back a piece of paper with the result written on it. Depending on what you want the system to do, you pick an appropriate form.
The form for MyMethod says:
MYMETHOD REQUISITION FORM:
String _______
int _______
This analogy can be extended in all kinds of ways. Wouldn't it be handy if the form told you what the purpose of the String and int were? That's where languages with named parameters come in.
For OO, instead of having one desk for the whole system, each object is its own teller, you hand a form to them, and in order to get the job done, they hand a lot more forms back and forth between each other. Etc.