I have written a ColdFusion UDF which calls itself recursively. What I would like to know is whether local/var scoped variables set in a parent call to the function are available in the child function or whether they are only available in the function call where they were set.
I am away from my workstation for a while so am unable to test for myself so wondered if anybody already knew the answer to this.
Thanks!
Function-local variables are local to the current call to that function. Each function call has its own memory space, and function local variables reside in that memory space. Recursive calls are no different in this regard.
As far as I know, JavaScript is no different here: I'd like to see an example that bears out your assertion that it's different.
Related
OK, let me try to rephrase my question.
Actually I wanted to know how is Function Application implemented in FP.
Is it done like a function call in imperative languages, where a stack frame is added for each call and removed on each return.
Or, is it like in inline functions, where the function call statement is replaced by the function definition.
Also, in terms of implementation of a function application, what is the significance of the statement functions in FP are mappings between domains and corresponding ranges. It is obviously not possible to maintain a mapping for each domain-range entry pair, so what exactly does the statement imply...
This question is broad enough that I can't answer it completely, since I don't know every single functional programming language. But I can tell you how it's done in one language, F#. You asked whether function application is done like a function call in imperative languages (another stack frame added for each call) or whether it's done as inline functions... and in F# the answer is both. The F# compiler is allowed to choose whether to create a stack-frame-using function call, or whether to inline the function at the call site; generally the choice is made based on the size of the compiled function. If the function compiles down to fewer than N bytes of compiled code (I can't tell you the exact number, but knowing the exact number doesn't actually matter) then the compiler will usually inline that function call; if it takes more than N bytes then the function call will use a stack frame. (Except in the case of tail-recursive calls, which are compiled to the equivalent of a goto and don't use a stack frame).
P.S. You can force the compiler's hand by using the inline keyword, which forces that function to be inlined at the call site every time. Most F# programmers don't recommend doing that on a regular basis, because the compiler is smart enough that it's usually not a good idea to override its decisions. (Also, the inline keyword means that the types of the function's parameters must be resolvable at compile time, so there are some functions for which that changes the semantics, but that's a little off-topic for the question you asked so I won't go into it. Except to say that in F#, statically-resolved type parameters or SRTPs are a very complicated subject, and you can do some very advanced things with them if you understand them.)
This is a basic R question: R has the concept of environment. So what purpose does it have, when do I need to start more then one and how do I switch between them? What is the advantage of multiple environments (other then looking up content of .Rdata file)?
The idea of environments is important and you use them all the time, mostly without realizing it. If you are just using R and not doing anything fancy then the indirect use of environments is all that you need and you will not need to explicitly create and manipulate environments. Only when you get into more advanced usage will you need to understand more. The main place that you use (indirectly) environments is that every function has its own environment, so every time you run a function you are using new envirnments. Why this is important is because this means that if the function uses a variable named "x" and you have a variable named "x" then the computer can keep them straight and use the correct one when it needs to and your copy of "x" does not get over written by the functions version.
Some other cases where you might use environments: Each package has its own environment so 2 packages can both be loaded with the same name of an internal function and they won't interfere with each other. You can keep your workspace a little cleaner by attaching a new enironment and loading function definitions into that environment rather than the global or working environment. When you write your own functions and you want to share variables between functions then you will need to understand about environments. Environmets can be used to emulate pass-by-reference instead of pass-by-value if you are ever in a situation where that matters (if you don't recognize those phrases then it probably does not matter).
You can think of environments as unordered lists. Both datatypes offer something like the hash table data structure to the user, i.e., a mapping from names to values. The lack of ordering in environments offers better performance when compared with lists on similar tasks.
The access functions [[ and $ work for both.
A nice fact about environments which is not true for lists is that environments pass by reference when supplied as function arguments, offering a way to improve performance when working large objects.
Personally, I never work directly with environments. Instead, I divide my scripts up in functions. This leads to an increased reusability, and to more structure. In addition, each function runs in its own environment, ensuring minimum interference in variables etc.
I'm developing an major upgrade to the R package, and as part of the changes I want to start using the S3 methods so I can use the generic plot, summary and print functions. But I think I'm not totally sure I understand why and when to use generic functions in general.
For example, I currently have a function called logLikSSM, which computes the log-likelihood of a state space model. Instead of using this functions, I could make function logLik.SSM or something like that, as there is generic function logLik in R. The benefit of this would be that logLik is shorter to write than logLikSSM, but is there really any other point in this?
Similar case, there is a generic function called simulate in stats package, so in theory I could use that instead of simulateSSM. But now the description of the simulate function tells that function is used to "Simulate Responses", but my function actually simulates the hidden states, so it really doesn't fit into the description of the simulate function. So probably in this case I shouldn't use the generic function right?
I apologize if this question is too vague for here.
The advantages of creating methods for generics from the core of R include:
Ease of Use. Users of your package already familiar with those generics will have less to remember making it easier to use your package. They might even be able to do a certain amount without reading the documentation. If you come up with your own names then they must discover and remember new names which is an added cognitive burden.
Leverage Existing Functionality. Also any other functions that make use of generics you create methods for can then automatically use yours as well; otherwise, they would have to be changed. For example, AIC uses logLik.
A disadvantage is that the generic involves the extra level of dispatch and if logLik is in the inner loop of an optimization there could be an impact (although possibly not material). In that case you could check the performance of calling the generic vs. calling the method directly and use the latter if it makes a significant difference.
Regarding the case that your function has a completely different purpose than the generic in the core of R, then it might be more confusing than helpful so you might, in that case, not create a method but have your own function name.
You might want to read the zoo Design manual (see link to zoo Design under Vignettes near the bottom of that page) which discusses the design ideas that went into the zoo package. These include the idea being discussed here.
EDIT: Added disadvantates.
good question.
I'll split your Question into two parts; here's the first one:
i]s there really any other point in [making functions generic]?
Well, this pattern is usually invoked when the develper doesn't know the object class for every object he/she expects a user to pass in to the method under consideration.
And because of this uncertainty, this design pattern (which is called overloading in many other languages) is invokved, and which requires R to evaluate the object class, then dispatch that object to the appropriate method given the object type.
The second part of your Question: [i]n this case I shouldn't use [the generic function] right?
To try to give you an answer useful beyond the detail of your Question, consider what happens to the original method when you call setGeneric, passing that method in.
the original function body is replaced with code for performing a top-level dispatch based on type of object passed in. This replaces the original function body, which just slides down one level so that it becomes the default method that the top level (generic) function dispatches to.
showMethods() will let you see all of those methods which are called by the newly created dispatch function (generic function).
And now for one huge disadvantage:
Ease of MISUse:
Users of your package already familiar with those generics might do a certain amount without reading the documentation.
And therein lies the fallacy that components, reusable objects, services, etc are an easy panacea for all software challenges.
And why the overwhelming majority of software is buggy, bloated, and operates inconsistently with little hope of tech support being able to diagnose your problem.
There WAS a reason for static linking and small executables back in the day. But this generation of code now, get paid now, debug later if ever, before the layoffs/IPO come, has no memory of the days when code actually worked very reliably and installation/integration didn't require 200$/hr Big 4 consultants or hackers who spend a week trying to get some "simple" open source product installed and productively running.
But if you want to continue the tradition of writing ever shorter function/method names, be my guest.
I am trying to figure out what you call a function that references itself. Is this termed recursion? Or is it simply a self-referencing function?
It is a recursive function. Direct recursion is when a function calls itself.
A function that calls itself is, as you suspect, called "recursive".
Recursive or self recursive is what I usually refer to it as. Just be careful so you don't get stuck in a loop calling yourself, eventually blowing the stack.
Also keep in mind your variable's scope. Declare variables as static if they are needed to be shared throughout all recursion levels (or declare them outside the function). Pass variables to the function if you need to specific information passed from one level to the next. And finally, use local variables in the function that are needed to keep state for a current level of recursion. Local variables will make a copy on the stack for each recursion level you call, and pop back to the previous values for each recursion that unwinds.
Suppose I have a procedure that I want to only have called by another specific procedure. Is it possible to force restrictions on that procedure so that it can only be referenced by the specified calling procedure? Really what I'm wanting to know, is whether there is another way to write the code so you don't have to nest/embed procedures within procedures, to force a limited scope.
procedure one
procedure two
begin
blah
end two;
begin
end one;
EDIT: This is for Ada Code btw.
No (generally speaking).
A public procedure is a public procedure, so it can be invoked by anything that "with's" it (if it's a standalone procedure) or the package in which it is declared.
There are a few ways to constrain its visibility if any of these might fit with your implementation approach:
Declare the procedure in the private part of a package, or within the package body. Then only subprograms within that package would have access to it.
Declare the supplying package or subprogram as private, then those packages that 'with' it can only reference the supplying unit's contents (including invoking its subprograms) within their private part or package body.
"Private with" the supplying package, so that it can only reference the package within its private part/package body.
But like T.E.D. says, work with the language and exploit its capabilities rather than trying to recreate some other language's constructs.
Well, if you were to put procedure one in a package by itself and put procedure two in its private section, then no other routine would be able to call it (unless written into the package or a child package).
You could also make a tagged type with any data specific to procedure one in it, and put procedure two in its package with an object of that type as a parameter. Then others might call procedure two, but not with procedure one's object.
I'm a little confused as to why you'd want to recreate Ada's scoping behavior without using scoping though. Embrace the language.
I have two possible suggestions. The first one is slightly odd and off topic a bit but I wanted to bring it up in case you didn't know since most of the answers have to do with hiding visibility of the code or changing relationships
You could consider using the Ada Tasking features and use the 'Caller Attribute. Normally this is only for tasking and then the "caller" name only denotes the calling task to the receiving task. But once inside the receiving task's entry you can then use the Caller name to quickly end or otherwise flag the caller as wrong or not the caller you expected. This basically puts a "doorman" inside the task entry which could then decide to let them proceed, requeue the caller to a different entry, or do something else. But again this would only really work if you have a task consuming published calls from another task. This is the only thing that I'm aware of in Ada where you can detect who called you and do something about it at runtime.
However your question seemed to want to use scope and so I would agree with what's been said here and only add that in Ada it is a normal have have nested procedures (for readability) but in addition to that you could consider creating child packages and using the hierarchy in reverse. That is expose the chidren to the programmer and make the parent only accessible from the children. Design the parent to be very limited in scope such that the public spec of the parent is totally worthless to any caller that doesn't have the private view of the parent's spec. That way you have your separation and only the chidren can access the functions in the parent and can actually call them because they have a complete view of the parent's types and function definitions.
Good luck with your issue.