Do bound functions support proper tail calls in ES6? - ecmascript-6

In the ECMAScript 2015 Language Specification, the definitions of Function.prototype.apply and Function.prototype.call both include "Perform PrepareForTailCall()" as one of their steps, so we know that these functions support proper tail calls (i.e., tail call optimisation).
The definition of [[Call]] on bound function objects, however, omits PrepareForTailCall(). Does this mean that bound functions do not support proper tail calls, and that a bound function calling itself recursively could blow up the stack?

The definition of [[Call]] on bound function objects omits PrepareForTailCall(). Does this mean that bound functions do not support proper tail calls, and that a bound function calling itself recursively could blow up the stack?
No. The PrepareForTailCall happens in EvaluateDirectCall during the evaluation of the call expression, where it checks whether that expression is in a tail position. When the tail call is prepared, the current running execution context is dropped, before the function is called, dispatching on the respective [[Call]] internal method. The new running execution context is set up in PrepareForOrdinaryCall from the [[Call]] method of user-defined functions. The [[Call]] method of bound functions just introduces an extra level of indirection before that happens.
In the ECMAScript 2015 Language Specification, the definitions of Function.prototype.apply and Function.prototype.call both include "Perform PrepareForTailCall()" as one of their steps, so we know that these functions support proper tail calls.
Yes, this is necessary because the [[Call]] method of built-in functions sets up a new running execution context (for the "implementation-defined steps"). It is this "builtin context" that the PrepareForTailCall will drop before the actual function is called.
The call and apply methods are functions calling functions, and when they are called there are two calls on the stack that need to be tail-call-optimised. (Contrast this to - for example - Array.prototype.map, which also calls other functions, but here the map execution context stays on the call stack. In call and apply, the Call() is indeed in a tail position of the algorithm).

See ยง12.3.4.1 (Runtime Semantics: Evaluation). First, we do IsInTailPosition, then we do EvaluateDirectCall -- the result of which is F.[[Call]]. In other words, by the time we make the actual call, we already know whether or not we're in a tail position.
However, as you mention, JS is not tail-optimized on any browser, except Safari.

Related

Can you pass arguments to functions in Slate?

In Foundry's Slate application, is there a clean way to write functions that accept arguments as input using the handlebar syntax?
Instead of function arguments, inputs to a Slate function are defined by a Handlebar reference inside the Function itself; for example to access data from a query from inside a Function, you might write:
const data = {{q_myQuery}}
Defining dependencies in this way allows Slate to automatically recompute the Function outputs whenever the values of upstream dependencies change. In this way, you never "call" a function, but rather some other element in Slate references the Function output and that output is updated whenever the inputs change.
If you want to do some kind of code reuse you can use functionLibraries to write common code that you can re-use between Functions. These are standard javascript functions that are included in the global javascript scope and can be referenced simply by the function name from any Function and take function parameters using normal javascript syntax. Since these are vanilla javascript you cannot use Handlebars inside a functionLibrary - here any input must be passed in as a parameter from the parent Function.
From the documentation (Slate > Concepts > Functions):
Per-Document level function libraries
Users are able to write reusable javascript functions with parameters. This will assist in the refactoring of code and reducing the copying and pasting of code in functions. You can also re-run and update all the functions dependent on a function library using the Re-run All Function button.
Default JavaScript libraries available
For enhanced use of functions, Slate ships by default (as of Slate 2.15) with the following external JavaScript libraries: Lodash, Math.js, Moment, Numeral and es6-shim. Feel free to use these libraries when writing your functions.Do not use ES6 syntax features unless all users are mandated to use a browser supporting these features.

CAPL Test Functions and Normal Functions in CAPL

I want to know the difference between the "CAPL Test Functions" and normal functions (Like in C or C++) which can be used in CAPL ??
Under which scenario should I use TestFunctions ??
Thanks.
Test functions are mainly used for test nodes which is used for running test cases (defined
in an XML file) and provide reports about the results.
Normal functions can be used in test/simulation/program nodes
Internally pre-defined CAPL functions does not require function libraries or linking header files to use and compile these functions.
CAPL's internal library provides functions in 3 categories.
1. capl's internal library
2. user defined functions
3. Dll functions, which require user to implement a dynamic linked library.
The idea behind test function and normal functions is quite simple. You can use both in Vector CANoe (test modules) and vTEST Studio. BTW. To make function visible in outter scope you use 'export' keyword.
Test Functions:
- they are always top-most (cannot be nested or executed by any other function)
- does not return anything
- provides additional logging in Vector CANoe test reports (visible either in HTML/XML based or CANoe Test Report Viewer)
- use it only in CAPL Test Modules as 'test steps' of test cases (top most functions)
Casual Functions:
- might be called by other functions and test functions
- might have a return
- executing a function does not influence test logs directly (only information added by testStep, testStepPassed etc. will be added in test report)
- use them in test cases only when you want to return some values (test functions cannot be used in this case)
- use them as smaller pieces of test functions

How do we wrap C++ variable argument parameter in WinRT components

I have a C++ method that takes variable argument as init param. Something like
MyMethod(std::wchar_t*, ...)
Can someone please let me know how can we write a WinRT component wrapper to expose the variable arguments?
WinRT metadata does not support vararg functions, so there is no good way to do this. The answer therefore depends on what the function actually does. Assuming it is some kind of string formatting function I would suggest wrapping it with something like:-
MyMethod(Platform::String^, Windows::Foundation::Collections::IVector<Platform::Object^>^ params);
This will allow you to take the variable arguments.
The problem of course is that this has completely different semantics from what you have. The caller is going to have to pack up an array, and you won't be able to call your existing method easily with the arguments from the vector.

What are callback methods?

I'm a programming noob and didn't quite understand the concept behind callback methods. Tried reading about it in wiki and it went over my head. Can somebody please explain this in simple terms?
The callback is something that you pass to a function, which tells it what it should call at some point in its operation. The code in the function decides when to call the function (and what arguments to pass). Typically, the way you do this is to pass the function itself as the 'callback', in languages where functions are objects. In other languages, you might have to pass some kind of special thing called a "function pointer" (or similar); or you might have to pass the name of the function (which then gets looked up at runtime).
A trivial example, in Python:
void call_something_three_times(what_to_call, what_to_pass_it):
for i in xrange(3): what_to_call(what_to_pass_it)
# Write "Hi mom" three times, using a callback.
call_something_three_times(sys.stdout.write, "Hi mom\n")
This example let us separate the task of repeating a function call, from the task of actually calling the function. That's not very useful, but it demonstrates the concept.
In the real world, callbacks are used a lot for things like threading libraries, where you call some thread-creation function with a callback that describes the work that the thread will do. The thread-creation function does the necessary work to set up a thread, and then arranges for the callback function to be called by the new thread.
Wiki says:
In computer programming, a callback is
a reference to executable code, or a
piece of executable code, that is
passed as an argument to other code.
This allows a lower-level software
layer to call a subroutine (or
function) defined in a higher-level
layer.
In common terms it is the mechanism to notify a piece of code i.e. a method, which piece of code to execute, i.e. another method, when it is needed.
Callback is related to the fact that the client of the calling function specifies a function that belongs to the client code's responsibility to the calling function to execute and this is passed as an argument.
An example is in GUIs. You pass as argument the function to be called once an event occurs (e.g. button pressed) and once the event
occurs this function is called.
This function is usually implemented by the object that originally registered for the event
Callback function is a function that is called through a function pointer. If you pass the pointer (address) of a function as an argument to another, when that pointer is used to call the function it points to it is said that a call back is made.
Why Should You Use Callback Functions?
A callback can be used for notifications. For instance, you need to set a timer in your application. Each time the timer expires, your application must be notified. But, the implementer of the time'rs mechanism doesn't know anything about your application. It only wants a pointer to a function with a given prototype, and in using that pointer it makes a callback, notifying your application about the event that has occurred. Indeed, the SetTimer() WinAPI uses a callback function to notify that the timer has expired (and, in case there is no callback function provided, it posts a message to the application's queue).
In general you supply a function as a parameter which gets called when something occurs.
In C code you will pass something that looks like this:
int (callback *)(void *, long );
meaning a function that takes two parameters, void * and long and returns an int.
With object-orientated languages the syntax is sometimes simpler. For example you might be able to construct a callback mechanism that allows the user to pass in an object that looks like a function or has an abstract method (thus wrapping a function) and context data too.
Modern languages use the term "delegate" to refer to a function "pattern". These can be used as callbacks. Some languages also use the term lambda which is essentially a function with no name, often created "on the fly" in a block of code and passed as a callback.
C++11 has introduced these into its standard.
The advantage of using a callback is that you can separate out, i.e. reduce / decouple an API from what is calling it, and to some extent vice versa, i.e. although in one place you know you are calling into the API, at the point of the "handler" it does not need to know from where it was called.
For example, you can have an API that generates objects and then "calls-back" as they get generated.
Call back means that you pass the code as a parameter. For example, imagine a button, that much show a dialog when pressed:
Button testBtn;
testBtn.setOnClickListener(new OnClickListener() {
#Override
public void onCLick() {
JOptionPane.showDialog(testBtn, "Test button pressed");
}
}
Here we tell the button what to execute, when it will be click. So, the framework will execute the passed code, when it detecs the click. Inside the framework there are some code like:
void processEvent(Event e) {
if (e.type == Event.CLICK) {
e.getComponent().getOnClickListener().onClick();
}
}
So, some basic code calls back the listener when the appropriate event happens.
PS: Pseudocode here, just do describe the idea.
A callback method is a method that gets called when an event occurs
In simple word, actually, a Callback is a reference to a function or method, which you can pass as a parameter to another function for calling it back later.
From the above figure, B_reference() is the callback method.
Source code sample:
>>> def A(A_msg,B_reference):
... # After printing message, method B is called.
... print(A_msg)
... B_reference()
...
>>> def B():
... print("Message from B")
...
>>>
>>> A("Message from A",B)
Message from A
Message from B
>>>
If you still don't understand what it is, you can check this video:

Whats the difference between C# delegates, Dynamic Proxy, Closures and function pointers?

What are useful definitions for the common methods of passing a method or function as data, such as:
Delegates
Closures
Function pointers
Invocation by dynamic proxy and
First class methods?
Function pointers lets you pass functions around like variables. Function pointer is basically legacy method to pass function around in languages that don't support first-class methods, such as C/C++.
First class methods Basically means you can pass functions around like variables. Methods (loosely) mean functions. So this basically means first class functions. In simplest terms, it means functions are treated as "first class citizens", like variables. In the old days (C/C++), because we can't directly pass a function around, and we had to resort to workarounds like function pointers, we said functions weren't first-class citizens.
Delegates is C#'s answer to first-class methods. Delegates are somewhat more powerful because it involves closures, consider the following code snippet:
void foo( int a )
{
void bar() { writefln( a ); }
call( &bar );
}
void call( void delegate() dg ) { dg(); }
int main( char[][] args ) {
foo( 100 );
}
Notice that bar can reference the local variable a because delegates can use closures.
Closures can be very confusing at first. But the lazy-man's definition can be really simple. It basically means a variable can be available in the human-expected way. Put in other words, a variable can be referenced in places where they look like they would be present, by reading the structure of the source code. For example, looking at the code fragment above. If we didn't have closure, bar would not be able to reference a because a was only local to foo, but not bar, which is another function.
Dynamic Proxy is the odd one out. It doesn't belong to these items. Explaining it requires some very long text. It stems from the famous Proxy Pattern. The problem with Proxy Pattern was that the Proxy class needs to be implementing the same interface as the Subject. Dynamic Proxy basically means using reflective approach to discover the Subject's method so that the ProxyPattern can be freed from being tied to the Subject's interface.
just the ones i know about:
Function pointers: just that, a pointer to a piece of code. you jump to it, it executes. typed languages can enforce some parameter passing convention (i.e. C declarations)
Closures: a function with some state paired. most naturally written in lexically scoped languages (i.e. Scheme, JavaScript, Lua). several closures can share the same state (or part of it), making it an easy way to implement OOP.
First class methods: a closure created from an object instance and a method. some languages with both closures and a native OOP (Python, JavaScript) can create closures automatically.
Closure is a programming language concept. Delegate is its realization in MS.NET.
A Delegate in MS.NET is a strongly typed pointer to an object's method (a delegate instance points to both - an object and its method). There is also a way to combine several void delegate instances into one.