PureBasic Forums - English

it would be nice to have nested procedures. it gives better information hiding and procedure headers don't have to become long and complex.

http://en.wikipedia.org/wiki/Nested_function
http://en.wikipedia.org/wiki/Nesting_%28computing%29

I am curious how this would differ from merely using a module? What are you wanting to accomplish?

I have no opinion one way or the other, because in my naivete, I do not see an advantage of it over the module. However, just as a preparatory FYI, I highly doubt Fred will implement this. Since we have been denied labels within procedures (i.e. for a subroutine), my guess would be a nested procedure would have the same implementation challenges that prohibit the feature.

And as another FYI, I understand the reason we cannot have subs within procedures is because PB uses the stack directly for local variable offsets, rather than a frame pointer. The frame pointer register is used for other register-use optimization purposes, which apparently requires too much rewrite to change.
For info on the frame pointer topic, see http://en.wikipedia.org/wiki/Call_stack ... e_pointers
and http://programmers.stackexchange.com/qu ... xplanation

What´s an Advantage of this? Only the Thing with procedurenames -> Module?

please read the articles of the links:

Purpose
Lexically nested function definitions are a form of information hiding and are useful for dividing procedural tasks into subtasks which are only meaningful locally. This avoids cluttering other parts of the program with functions and variables that are unrelated to those parts.
They are typically used as helper functions or as recursive functions inside another function (as in the quicksort example above). This has the structural benefit of organizing the code, avoids polluting the scope, and also allows functions to share state easily.[3] As nested function can access local variables of the enclosing function, sharing of state is possible without passing parameters to the nested function or use a global variable, simplifying code.
In languages with nested functions, functions may normally also contain local constants, and types (in addition to local variables, parameters, and functions), encapsulated and hidden in the same nested manner, at any level of depth. This may further enhance the code structuring possibilities.

it keeps the code clean and structured.

Well I'd say that lambdas are of much greater use and provide more flexibility than just nested functions.

yup, but easy things first?

No, I'd rather have it "right" on the first go.

there is NO right there. it is 2 different things and i think the nested procedures are easier to implement.

That's why I quoted the word. However, I do think that nested procedures in PB
are of rather limited use and I'd say that the current modules provide enough information
hiding capabilities in that regard.

seeker wrote:please read the articles of the links:

I did read (or skim) those articles. I still do not see an advantage. Perhaps you should read about PB's modules. From what I understand, they do everything you have promoted about nested procs.

i am baffled that you can't see the advantages. why should juggle global variables in modules when there is an elegant an needly structured way?

Why don't you give it a try with a module and see how close you can get to what you are trying to do? I still believe it will do exactly what you want.

well, module has a different meaning for me and may be i am to old to frickle around, cut corners etc., because the language does not have the syntactic sugar/support to structure a program/procedures cleanly.
there is a difference in module and nested procedure.
well thanx anyway.

I fully understand the frustrations that come with losing the syntax of your favorite language. Please understand, I am not against your request, I just have no confidence it will be implemented.

In the meantime, there are at least two ways you can work around your issue. The first and easiest is to create a module that merely contains the variables that you want "global" to the set of procs you want. This was trimmed down from the cars example in the Help file: So, the "global" variable is Cars::NbCars, which is akin to just naming a regular global var Cars_NbCars and making sure you do not need that name elsewhere. However, by using the Module, it places a layer of protection around it to simplify your name conflicts--that is, if you end up with two modules named Cars, then you can rename one.

Unfortunately, both Car1() and Car2() are visible to everything. And so...

The second way, which more closely mimics the nested proc examples on wikipedia, is to write all procedures within a module, but only make the one procedure visible.
This is taken from wikipedia, and converted to (wishful) PB syntax: Converting to a module, we get this:So yes, you have the extra commands required of the four lines containing module commands. And the parameters are not global. However, it accomplishes the goal of isolating one variable (x, in this case) so it may be used within a number of functions and not in others.

To call the "global" function, E, you have two choices. You can announce the module, then just call E anywhere you like: Or, if you prefer, you can skip the announcement, and just call the module function directly: Obviously this is more work than a nested proc, but it is available today. Because of the issues mentioned in my first post, nested procs are likely never to be available. At least, not until Fred warms up to the idea of rewriting the register allocation and optimization routines within the compiler. At least now he has two requests to add to that motivation.