(Possible) Breaking change: local variables references inside nested function definitions

[A Former User]

@d-healey Wow, very different solution. Thank you for the suggestion, I will check!

[d.healey]

@Christoph-Hart said in (Possible) Breaking change: local variables references inside nested function definitions:

In your case you might get away with just changing local to var for the origin definition.

I'm finding this approach is causing problems in other functions that use the same variable names. My nest solution is still working fine but it's ugly code. Is there a possibility of some syntactic sugar being added to HISE so that we can use the word local in these scenarios and internally HISE will treat them as children of a reg variable, just like I'm doing with my reg nest method?

Edit: I just realised I asked this already :p

[andioak]

@Christoph-Hart @d-healey It's been a while for me here at the Hise forums, so please correct me if I'm wrong, but isn't one important issue the fact that we're using "inline" functions?

Perhaps we could be using normal functions (not "inline") for things that are asynchronous in nature, such as the fetching of files through the FileSystem.browse() object. If the "inline" is the issue that makes the local variables go out of scope, when the stack is not synchronously executed as per the inline function specification. (if I'm getting that bit right :beaming_face_with_smiling_eyes: )

After all, the inlining of functionality is for things that are very sensitive in timing, real-time stuff for audio and such things. This is not going to run in the same threads as the audio streaming, right?

Otherwise, the "asynchrounous:ness" of the file browser could perhaps be explained a bit, I would love some info on that. Looking at the docs atm :)

(a novice at C++ at best still :) )

[d.healey]

@andioak said in (Possible) Breaking change: local variables references inside nested function definitions:

@Christoph-Hart @d-healey It's been a while for me here at the Hise forums, so please correct me if I'm wrong, but isn't one important issue the fact that we're using "inline" functions?

The particular issue in this thread is when you use a non-inline function within and inline function. This is often the case when using things like the file browser which requires a callback function as a parameter.

[andioak]

@d-healey said in (Possible) Breaking change: local variables references inside nested function definitions:

The particular issue in this thread is when you use a non-inline function within and inline function. This is often the case when using things like the file browser which requires a callback function as a parameter.

@d-healey Yes, I know. But why use an inline function to begin with in the case of the file browser? (or anything asynchronous in nature) Is not better to use a normal function in the cases that require asynchronous behaviour?

[d.healey]

@andioak You could use a normal function but the problem of scope would remain.

[Christoph Hart]

In C++ there is a concept where you can pass on certain variables to a local function (google lambda capture for more info), so maybe I can hack around again and frankenstein that feature into HiseScript…

[Christoph Hart]

You could use a normal function but the problem of scope would remain.

Oh but this is wrong (at least according to my understanding of the issue). Normal functions do have a local scope that will not overwrite the global variable, but inline functions don't:

var x = 100;

inline function overwriteRootVariable()
{
	var x = 90;
}

function dontOverwriteRootVariable()
{
	var x = 1000;
}

overwriteRootVariable();
dontOverwriteRootVariable;

Console.print(x);

[d.healey]

@Christoph-Hart Aha that's good to know. In that case I assume a callback function within a normal function still won't have access to the outer function's variables, correct? I like the lambda idea.

[Christoph Hart]

@d-healey Ah yes, that's true, just checked.

I've added the explicit capture syntax. It looks a bit weird coming from JS, but is inspired from the big mighty C++ again. It only works with anonymous functions so all you need to do is to put a list of all local variables and parameters between the function keyword and the parameter list

function [variables] (parameters)
{
   body;
}

Example usage:

inline function testScope(p)
{
	local x = 900;
	
	Engine.showYesNoWindow("Show local value", "Click OK", function [p, x](ok)
	{
		Console.print(p);
		Console.print(x);
	});
};

function testScope2(p)
{
	var x = 200;
	
	Engine.showYesNoWindow("Show local var", "Click OK", function [p, x](ok)
	{
		Console.print(p);
		Console.print(x);
	});
};


testScope(10);
testScope2(19);

There are still a few limitations (eg. the captured values will be overwritten by the last call), but let me know if that helps. Edit: removed this limitation :)

[d.healey]

@Christoph-Hart Fast work! I'll play around with this tomorrow and let you know if I hit any issues, but look like a good improvement to me.

[andioak]

@Christoph-Hart Great. Looks like the C++ examples I just read about on the Lambda / Lambda Capture pages.

As I understand it, C++ did not have any capacity to declare a function within another function until C++ 11. At this time the Lambda function, also called an "anonymous" function (a function with no name or declaration in the global scope) was added to try and keep the global scope clean, free of unnecessary functions that are only used once. Strange that something that is so frequently used in JavaScript since forever has been added so late in the game in C++.

The closer we are to C++ in HiseScript, the better we understand our plugins. :)

@d-healey said in (Possible) Breaking change: local variables references inside nested function definitions:

@Christoph-Hart Fast work! I'll play around with this tomorrow and let you know if I hit any issues, but look like a good improvement to me.

Please post any tests you make with lambdas, I would love to have a look at that! :)

[d.healey]

@Christoph-Hart

I noticed this causes a function not found error when you respond to the popup. I wonder if it's related to the new lambda stuff

Engine.showYesNoWindow("title", "text", function(response)
{
	
});

[d.healey]

reg variable overrides the local variable

reg x;

inline function test()
{
	local x = 900;
	
	Engine.showYesNoWindow("Show local value", "Click OK", function [x](ok)
	{
		Console.print(x);
	});
};

test();

[Christoph Hart]

@d-healey Both issues are fixed now.

[d.healey]

@Christoph-Hart Excellent, thank you! The new lambda variables and broadcaster are both excellent additions, make life so much easier :D

[d.healey]

@Christoph-Hart New problem. It breaks when using objects.

inline function test()
{
	local x = {"name":"dave"};
	
	Engine.showYesNoWindow("Show local value", "Click OK", function [x](ok)
	{
		Console.print(x.name);
	});
};

test();

[Christoph Hart]

@d-healey Ah yes, totally missed that. It's fixed now and before you ask: arrays and even functions work too now:

inline function test()
{
	local x = function()
	{
		Console.print("Dudel");
	};
	
	Engine.showYesNoWindow("Show local value", "Click OK", function [x](ok)
	{
		x();
	});
};

[d.healey]

@Christoph-Hart Thanks for the fast work!

[Christoph Hart]

Now that I'm currently in "fixing annoying things in the HiseScript compiler" mode, I also fixed leaking of iterator variables into the global namespace:

inline function inner()
{
    for(i = 0; i < 10; i++)
        Console.print(i);
} 

function outer()
{
    for(i = 0; i < 5; i++)
        inner();
}

Console.print(i);

This will have rather unpredictable results because the i in the inline function is actually using the same scope as the one in the outer function, which will leak also to the global scope. In order to fix this, you previously needed to declare local / var statements before the loop like this:

inline function inner()
{
    local i = 0;

    for(i = 0; i < 10; i++)
        Console.print(i);
} 

function outer()
{
    var i = 0;

    for(i = 0; i < 5; i++)
        inner();
}

Console.print(i);

Which I've grown accustomed to do whenever I was using these kind of generic loop iterator names that might be called in a nested fashion. However that shouldn't be the responsibility of the user but a language feature, so I've added some code to the compiler to actual inject these local / var statements before the for loop so it makes sure it uses the most narrow scope possible when using iterator variables.