...You ask why declaring if I call once...it *IS* to simplify it.

What I wanted (and have used in other languages) is lexically scoped, named subroutines. That' perl makes all named subs global is related to it coming from being an unstructured, 'batch' language with no subroutines, and only global variables. We have lexically named variables, but sub's starting from a more primitive place than variables did (vars at least existed, while subs didn't), aren't yet at the place where one can use lexically named subs.

For *me*, (and this is for me), having the subroutine internal to the only subroutine that is using it makes it more clear. I know -- unquestionably, that the routines are intimately related and shouldn't be considered for separate use unless they are further refined. At a glance, I can see what routines are only used by 1 routine.

Normally when one makes a change in a large program, you need to be sure that the changes you are making to a subroutine won't cause some other place in the code to break because they had different expectations about what the sub was to return or "do". I don't do it as often in perl (because I have to go through the var->anonsub(args) ) and don't normally have the luxury of so finally tuning code at that level.

But you can't argue that that local-subs aren't more clear unless you also want to argue that locally declared variables are not better (for the same clarity reason, among others) than global variables.

I've used (and use) the structure you mentioned about having multiple subs in outer layers of braces. But in some instances, (like this one), the subroutine came from inline in the same routine -- and wasn't envisioned as a "co-routine", but a sub-function that I desire to be both named and treated as a lexical variable. As I replied elsewhere, above, something like a my sub foobar() {....}; that has the same lexical rules as variables in the same scope. So...yeah... I currently *can't* have lexical named subs, but that doesn't mean that this is a "good" thing. :-) It is possible for perl5 to evolve beyond where it's at now isn't it?

As for the types -- I think they catch my typing errors when I'm writing my code before the typing information is stripped off and thrown away by making the calls indirect. And I rely on them altering the code in some places (though not in the code snipplet posted). But it's hard to write a "push" operator that doesn't use "\@" as its first parameters. Beyond that, even though I know the types aren't used on funcs I create as objects, I find the prototypes useful, at least during development, as documentation.

In fact I find it quite annoying that there isn't an _option_ for stronger typing -- in the same way that many people would be upset if the "-w" flag and "use strict" were no longer around. But that's just me -- and not every program nor all the time...but sometimes it's annoying.

It's inconvenient that the types that exist are so disparaged that common modules like "Exporter" don't even work right with typed modules without some special handling. So of course types become more of a problem because no one uses them or tests to see that their code could work with them. So that types "cause problems" becomes a self-created and self-fulfilling prophecy. Oh well... :-/