Each time you call the anonymous sub constructor it creates a new closure already. What exactly do you mean by "adjust the type"? Something like this perhaps?

sub instantiator {
  my $state = shift;

  if( $state eq 'scalar' ) {
    return sub { ... something scalarly ... }
  } elsif( $state eq 'array' ) {
    return sub { ... an array of possibilities ... }
  } else { # hash
    return sub { ... make a complete hash of things ... }
  }
}
[download]

Update: Aaah. You can overload &{}, so perhaps you could use that to do what you want (i.e. you return an object rather than a sub ref which has an overloaded &{} that examines whatever and then behaves differently).

package Foo;

use overload "&{}" => \&deref;

sub instatntiate {
  my $state = shift;

  # ...

  return bless { _original_code => sub { ... } }
}

sub deref {
  my $self = shift;
  ## examine $self and create $newsub using $self->{_original_code}
  $newsub->( @_ );
}

package main;

$f = Foo::instantiate( ... );

$f->( $a, $b, $c );
[download]

{
  my $both;
  sub inst {
    my $inner = shift;
    $both .= "xxx ";
    return sub {
      printf "both: %s\nmine: %s\n", $both, $inner;
    };
  }
}

for( 1 .. 3 ) {
 my $n = inst("[$_]");
 &$n;
}

__output__

both: xxx
mine: [1]
both: xxx xxx
mine: [2]
both: xxx xxx xxx
mine: [3]
[download]

How about always accepting the arguments as an array?

sub instantiator {
    my @state = @_;
    sub {
        # work on @state
    }
}
[download]

To retain a data structure through the argument list of a sub, you need to pass a reference to it (you knew that!). Then you can do a perly case switch on ref $_[0] to return a sub specialized to the argument type.

my $utility = instantiator( \&instantiator );
[download]

Not what you were looking for, but I couldn't resist the opportunity.

If you want to return one of several different styles of closure, you'll need to have closure generators for each of them, or a conditional block that determines which to return.

Sorry, I thought that ...chose/adjust the type (scalar/array/hash) of the closure... was fairly clear. The problem was that during the life of the utility sub, as a result of it's use, it may be beneficial to change the form in which the retained state is stored.

For example, when the sub is generated, the parameters supplied to the instantiator might indicate that an array would be the best representation. However, in use, the sub might determine that the data being retained is sparse data and therefore it makes more sense to revert the storage format to using a hash rather than an array. The reverse situation might also apply.

I was looking for some way for the utitlity sub to change the type (scalar/array/hash) of the closure on the fly. It turns out that I was simply looking for a complicated solution when a simple one would suffice. Zaxo++ pointed out (via /msg) that if the closure defined at construction time is a simple scalar I can later assign a reference to either an array or a hash as I decide I need and that addresses the problem.

I'm embarrassed that I didn't see the obvious myself before posting, but I didn't:(

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail