Godot: Nested functions

[kubecz3k]

Operating system or device:

Issue description (what happened, and what was expected):
It would be great if we could have nested functions inside GDscript. Nested functions would allow to divide script into significantly higher amount of 'logic blocks' without loosing readability. It's one of the features most modern languages don't support, which I personally miss the most.
Interestingly nested functions are present in Python and since GdScript is Python-similar I think it would be a nice addition.

Steps to reproduce:

Link to minimal example project (optional but very welcome):

[vnen]

The lambda expressions from #2704 might help with this. And I believe all functions in GDScript are actually methods, as the belong to an object. To which object would a nested function be attached to?

[reduz]

that one hasn't been merged yet because it would have some considerable
performance cost, so will probably try to solve it in a different way

On Wed, May 4, 2016 at 12:16 PM, George Marques [email protected]
wrote:

The lambda expressions from #2704
https://github.com/godotengine/godot/pull/2704 might help with this.
And I believe all functions in GDScript are actually methods, as the belong
to an object. To which object would a nested function be attached to?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/4546#issuecomment-216897555

[ret80]

All this is great but to be honest it a waste of time. You either leave it as is and it is better to optimize the scripting engine that he would have worked faster or tie another programming language for example the same python or c #
And so it's just reinventing the wheel!

[kubecz3k]

@vnen I believe lambdas expressions and nested functions are usually used to serve different purposes. I'm not very much into implementation details, but I believe nested function should have access to everything inside 'parent' method scope, so it should have access to all the object methods and members. It would be cool if it also could have access to local variables of parent method that were declared before nested function declaration. Also I think calling nested function should be very fast (perfectly not adding any computation by the call itself).
I think all this things could be met by forcing nested functions to work the way how inline functions work in c. (<- I mean it could at compile time just copy paste its body into at the function call place)

[vnen]

I cited the lambdas as a direction to first-class functions, which is something GDScript doesn't have. Python and JavaScript both have first-class functions, which naturally allow nested functions. For me that's the way to go, but this is just IMO, as I'd find much more useful than simply nested functions.

I can see the point of a nested function that works as inline too, which seems much easier to add.

[bojidar-bg]

@vnen @kubecz3k ~ If we do them as inlined functions, recursion would be impossible, which is something I don't really like (also, it would bloat the ram a lot in some cases). Maybe another issue would be needed for this :smile: ?

The way I personally see it is as functions bound to the same object, but hard to access from the outside (but still possible, since call_deferred should work even in those cases).

func do_stuff(x,y,z):
    func helper(a):
        return a * a / 2 - 6

    func another_helper(x):
        if has_node(x):
            get_node(x).raise()
            get_node(x).connect("jumped", self, "handler")

    if x == y:
        x = helper(y + x)
    else:
        z = x - y

    call_deferred("do_stuff/another_helper", str("l", z)) # If it is function-scoped and not block-scoped...

[kubecz3k]

@bojidar-bg as I said I'm not very much into implementation details so I wont defend this whole inline idea :) What you proposed already looks nice for my eyes :)

[ghost]

@ret80 I was gonna say the same thing but devs on Godot generally like reinventing the wheel. I was pretty perplexed at first but I think I get it now. Godot is sortof a creative fun project for most devs here . They seem to enjoy spending extra time making a work of art rather than slap some code together just to make it work.

[reduz]

@trollworkout @ret80 I'm sorry guys, but sometimes it's difficult to go against ignorance. Just like you, a lot of developers also think it's simple to just take some existing scripting/compiled language and adapt it to a game engine. I'm sure that you think it's like Lego bricks that you put together and magic happens. As a result of this, you are probably thinking we are kind of stupid or like reinventing the wheel because we did our own scripting language.

I'm pretty sure you never tried to adapt a script VM to a game engine, but truth is that most existing VMs are either very limited or not designed for games. The reasons are maybe too technical for you, or really difficult for me to explain. I adapted and worked with several existing script languages and made several games with them. I understand very well why going with something of our own solved plenty of problems that you don't even realize you would have if we used something that already exists.

I tried to explain it several times but it's no use, people thinks we are stupid or like reinventing the wheel. I posted the reasons in the documentation, yet almost no one would read them, believe them or understand them.

It's evident at this time that implementing C# will be a great solution to a lot of problems. We couldn't do it before because the license of Mono was incompatible, but things changed now that Microsoft acquired Xamarin.

With C#, we will solve many problems:

1. Developers who are too lazy to learn new language will feel at home.
2. Developers who don't quite grasp how to use a dynamically typed language and write inefficient code will be fine with C#, because it's much more tolerant to inefficient code.
3. Companies in countries where job specialization is so extreme that programmers can only learn by taking courses will have a familiar language to work with.
4. Developers who complain that GDScript lacks A or B feature of other programming languages will be able to use a language that is super featured and has a large standard library.

Of course, the downside will be larger exports, and more time taken writing and testing code, because you lose all the benefits of a tightly integrated language to the engine. I can only hope that for such programmers, the benefits will outweight the downsides.

[reduz]

@vnen @bojidar-bg The lambdas patch turns GDscript into an even more dynamical language. I don't want to go this way because performance in key areas would be lost.

In fact, my idea is to turn GDScript into an even more static language to increase performance in the future. The only reason more work is not put into this area is time and that there are other priorities. I seriously want to spend more time working on this area, but it will have to be after 3.0 (new renderer) is out.

[ghost]

Thanks @reduz. As I have spent more time with Godot I realize is not as simple as putting bits and pieces from all over and making it work. You really need to adapt a code and make it work with what you already have. And yeah while I used the expression "reinventing the wheel" I realize that's not it at all anymore.

[reduz]

Seriously, I _really_ tried using other script languages. There are bottlenecks you just can't go over.

With Lua, we had all kind of problems. The binder was a mess, replicating a class structure with fallbacks was slow, the garbage collector generated stalls, thread safety was impossible.

With Squirrel the situation somehow improved because it had native classes and no garbage collector, but we were still severely limited due to lack of thread safety (or only safety when using a massive lock).

Added to that, most game code uses vector types (Vector2, Vector3, etc). Adding that kind of custom types to a VM is just slow.

A lot of devs try to benchmark GDScript by using the same code in Lua or Python as in GDScript and complain GDScript is slow. Try using custom vector types in those languages, and you'll quickly see which languages hit a hard bottleneck quickly.

Added to all that, the amount of C++ code needed to ONLY BIND Lua, Python or Squirrel is several times bigger, and several times more messy than the whole GDScript implementation. We spent years finding bugs in binder code. GDscript has been pretty much bug free since a few months after it was made.

But all this is really difficult to explain, people still come back and complain about why we didn't use Lua or real Python. For this, I'm very glad they'll soon be able to use C#.

[volzhs]

I have experience that some of my game logic got improved as 10 times faster with tuning a few lines.

I personally feel same with @reduz said

With C#, we will solve many problems:

Developers who are too lazy to learn new language will feel at home.
Developers who don't quite grasp how to use a dynamically typed language and write inefficient code will be fine with C#, because it's much more tolerant to inefficient code.
Companies in countries where job specialization is so extreme that programmers can only learn by taking courses will have a familiar language to work with.
Developers who complain that GDScript lacks A or B feature of other programming languages will be able to use a language that is super featured and has a large standard library.

[ret80]

@reduz
Everyone understands that the addition of third-party libraries are almost always faced with some sort of unexpected problems. Not a hundred does not consider that you have not the right to choose to develop their language and did not take sides. Just read your language is not an easy task. It is especially difficult to optimize for speed. Now there is the open side cursors that can be used in Godot. On account of the extent to which their easy to implement say, not what can not. Here is another question. Any popular programming language drags your community. And if you want to expand the community of programmers on Godot it is quite possible to consider alternative language support. In fact, I was quite happy Godot script. Unfortunately, as I understand it you just do not have the resources that would have to develop it. And only for this purpose, I consider that the proposed alternative.
PS
I do not quite understand, work on adding C# are already underway, and in the near future we will see it? Or I'm wrong?! Maybe C# is not the best choice. What is the uncertainty with it. And Unity3D developers him namuchalis much.

[ret80]

I'm more worried about the engine performance in general than other programming language. Now I'm doing a little game that uses 3D 30-50 cubes and a couple of sprites except for the text. 3 a light source. And FPS does not please me. On «JIAYU S3» I have 35-45 FPS. At low samsung tablet (model I do not remember but like Q SD400 CPU) 30 FPS which is very small for such a simple game. And if you move to another programming language will gain in performance well, it would be great. But at the same time, another programming language can greatly increase the amount of build a little sad. In general, you need to look for compromises.

[volzhs]

maybe, we need official roadmap for main improvement of further version.

[jaacko-torus]

I know this is old, and I have read enough of the thread to know that many of you who are actually doing the heavy work dont want to make gdscript more like other languages, and after everything ive read I totally understand.

However I still want to ask, is it planned now or ever to make lamdas or nested functions? Is it just a bad idea? Or is it hard to implement? Or something else?

Im a noob to programing in every sense of the word, I'm not going to act like I know what is right for the progress of the language and engine. But please do say if this is a feature that will be implemented.

Thank you.

[Calinou]

@jaacko-torus Lambdas are on the roadmap for Godot 4.0, see https://github.com/godotengine/godot-roadmap/issues/23.

[akien-mga]

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!