I'm not really classically educated in CS or mathematics. I'm just thinking there should be a term for this in pass-by-reference laungauges such as php. IE. functions that return a result (like how you'd want most functions to work) versus functions that modify an in-parameter.
Is there such a term?
The only term that I have heard relating to what you are talking about is: parameter idempotence
Simply put this type of function guarantees that the arguments remain untouched.
As far as a function that changes parameters I haven't heard any particular terms but I just say: parameter mutating.
From my experience any function that takes a reference to an object, it's a fairly safe bet that it will be mutating that parameter in some way.
Related
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.
Why is the return function called return?
The description is:
Inject a value into the monadic type.
The name not only doesn't make sense (to me), it is confusing for people coming from an imperative language where return is a language keyword that returns from the function.
Why is it called that? Because it's usually the very last function in a monadic block of code. Usually the only good reason to use return is to set the final return value from your monadic action.
I too think that this is a very, very poor name choice. But it's not like we can fix it now...
It's purely historical. Most Haskell developers agree it's a bad name. It breaks the principle of least surprise. Quite a few of the older library functions are a bit wonky (the plethora of error handling schemes and a few other typeclass element names come to mind).
As #bheklilr says, there is a restructuring underway which should help:
http://www.haskell.org/haskellwiki/Functor-Applicative-Monad_Proposal
These are good places to start if you are interested in the meta of Haskell:
http://www.haskell.org/haskellwiki/Future_of_Haskell
http://www.haskell.org/haskellwiki/Category:History
The answer is because it returns something. It you use in PHP for example - echo something in it, it returns that text or data. But functions primary power is not in echoing data directly. Their power is in storing data and returning variable/array or similar where are data is stored.
You can also return true or false based on data/calculation. In classes, functions are named methods and do the same thing - return something. In java return can be void (echoed data), or strict data type (boolean for example, or String, Array, etc).
After return function data is not being returned.
When writing recursive functions, it sometimes happens that something should happen only on the first pass of the recursive algorithm. When this is true, I have two options,
Have an optional parameter called "first run" which is set to true by default but when called recursively, the argument is false
Have two functions
Which option is preferable? If it is the latter, what should I name these functions? (e.g. if its a flood fill algorithm would I choose FloodFill and FloodFillRecursive?)
Thanks in advance, ell.
I might use two functions, and I would say that the function that will be called should be named FloodFill : the user doesn't need to know how that function is implemented, so it should not be named FloodFillRecursive.
Actually, FloodFillRecursive could be the name of the inner function : the one that contains the implementation, the on that is called by the one called by the user -- as it is that second function that is recursive.
Ideally, that function should not be visible from the users : it should be kind of hidden in your library (be it trully hidden, or using some naming-convention that informs users they should not call it directly).
And, this way, if you change implementation, you will not have your users call a FloodFillRecursive function that might no be recursive anymore.
It would depend really if the function is intended to be usable by 3rd party developers. If it is it might be preferable to use the two functions approach for neatness's sake, with the second function (FloodFillRecursive) private/internal to your library.
If it's not then the optional parameter approach is fine.
Option 2 is better in every case I can think of. This depends on the language you're using, but you're probably going to see significantly more (entirely avoidable) overhead by passing an additional argument every time.
For the naming convention, use a normal name for the outer function (eg FloodFill). For the inner function I'd say FloodFillRecursive or FloodFillInner are good choices.
If the language allows it then in my opinion the best is to have one function with the official "clean" interface, and the using a local function (not visible outside) for the recursion.
For example in Common Lisp
(defun n-queens (n)
(let ((result (list)))
(labels ((place-queen (row free-cols free-diagonals free-counter-diagonals)
...))
(place-queen 0 ...)
result)))
or Python
def n_queens(n):
result = []
def place_queen(row, free_cols, free_diags, free_counter_diags):
...
place_queen(0, ...)
return result
in the above example the recursive functions requires many parameters (e.g. the still free columns, diagonals and counter-diagonals) but the official public function only accepts a parameter and the recursion is handled internally.
I'm writing a toy compiler thingy which can optimise function calls if the result depends only on the values of the arguments. So functions like xor and concatenate depend only on their inputs, calling them with the same input always gives the same output. But functions like time and rand depend on "hidden" program state, and calling them with the same input may give different output. I'm just trying to figure out what the adjective is that distinguishes these two types of function, like "isomorphic" or "re-entrant" or something. Can someone tell me the word I'm looking for?
The term you are looking for is Pure
http://en.wikipedia.org/wiki/Pure_function
I think it's called Pure Function:
In computer programming, a function may be described as pure if both these statements about the function hold:
The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.
The result value need not depend on all (or any) of the argument values. However, it must depend on nothing other than the argument values.
I guess you could say the adjective is "pure" if you go by "pure function".
I always learnt that a function whose output is always the same when the arguments are always the same is called "deterministic". Personally, I feel that that is a more descriptive term. I guess a "pure function" is by definition deterministic, and it seems a pure function is also required to not have any side-effects. I assume that that need not be the case for all deterministic functions (as long as the return value is always the same for the same arguments).
Wikipedia link: http://en.wikipedia.org/wiki/Deterministic_algorithm
Quote:
Given a particular input, it will always produce the same output, and the underlying machine will always pass through the same sequence of states.
I am curious to know about this.
whenever I write a function which have to return multiple values, either I have to use pass by reference or create an array store values in it and pass them.
Why all the Object Orinented languages functions are not allowed to return multiple parameters as we pass them as input. Like is there anything inbuilt structure of the language which is restricting from doing this.
Dont you think it will be fun and easy if we are allowed to do so.
It's not true that all Object-Oriented languages follow this paradigm.
e.g. in Python (from here):
def quadcube (x):
return x**2, x**3
a, b = quadcube(3)
a will be 9 and b will be 27.
The difference between the traditional
OutTypeA SomeFunction(out OutTypeB, TypeC someOtherInputParam)
and your
{ OutTypeA, OutTypeB } SomeFunction(TypeC someOtherInputParam)
is just syntactic sugar. Also, the tradition of returning one single parameter type allows writing in the easy readable natural language of result = SomeFunction(...). It's just convenience and ease of use.
And yes, as others said, you have tuples in some languages.
This is likely because of the way processors have been designed and hence carried over to modern languages such as Java or C#. The processor can load multiple things (pointers) into parameter registers but only has one return value register that holds a pointer.
I do agree that not all OOP languages only support returning one value, but for the ones that "apparently" do, this I think is the reason why.
Also for returning a tuple, pair or struct for that matter in C/C++, essentially, the compiler is returning a pointer to that object.
First answer: They don't. many OOP languages allow you to return a tuple. This is true for instance in python, in C++ you have pair<> and in C++0x a fully fledged tuple<> is in TR1.
Second answer: Because that's the way it should be. A method should be short and do only one thing and thus can be argued, only need to return one thing.
In PHP, it is like that because the only way you can receive a value is by assigning the function to a variable (or putting it in place of a variable). Although I know array_map allows you to do return something & something;
To return multiple parameters, you return an single object that contains both of those parameters.
public MyResult GetResult(x)
{
return new MyResult { Squared = Math.Pow(x,2), Cubed = Math.Pow(x,3) };
}
For some languages you can create anonymous types on the fly. For others you have to specify a return object as a concrete class. One observation with OO is you do end up with a lot of little classes.
The syntactic niceties of python (see #Cowan's answer) are up to the language designer. The compiler / runtime could creating an anonymous class to hold the result for you, even in a strongly typed environment like the .net CLR.
Yes it can be easier to read in some circumstances, and yes it would be nice. However, if you read Eric Lippert's blog, you'll often read dialogue's and hear him go on about how there are many nice features that could be implemented, but there's a lot of effort that goes into every feature, and some things just don't make the cut because in the end they can't be justified.
It's not a restriction, it is just the architecture of the Object Oriented and Structured programming paradigms. I don't know if it would be more fun if functions returned more than one value, but it would be sure more messy and complicated. I think the designers of the above programming paradigms thought about it, and they probably had good reasons not to implement that "feature" -it is unnecessary, since you can already return multiple values by packing them in some kind of collection. Programming languages are designed to be compact, so usually unnecessary features are not implemented.