You say it's "a reference to a scalar", but don't you mean to say it's a reference to a code reference? You can add as many backslashes as you like, you only have to dereference them sufficiently to get at the underlying referent.

I think I understand, but I'm a bit puzzled by your terminology. Seems like a cool trick to me, let me see if I understand you correctly:

#! /usr/bin/perl -w

use strict;

sub foo { "this is foo" }
sub bar { "this is bar" }

my @later;
sub do_it {
  my $ref = shift;
  if( ref($ref) eq 'CODE' ) {
    print "do it now: ", $ref->(), "\n";
  }
  elsif( ref($$ref) eq 'CODE' ) {
    push @later, $$ref;
  }
}

do_it( \&foo );
do_it( \\&bar );

print "deferred ", $_->(), "\n" for @later;
[download]

Is that what you mean? If so, yeah, I like it.

Your solution implies that all scalars will be scalar coderefs, at least for some set of keys. And Then this set of
keys, or its universal nature, must be unmistakeable otherwise your attempted idiomatic meaning becomes lost
because it is just normal code.

If parameters may be needed you will need to deal with array references or such anyway.

A good programmers' idiom is complete in itself, like an idiomatic phrase in natural language.
Your meaning exists in one place, but must be interpreted in another. This plays against its utility.
I would be more explicit:

   $foo => \&immediate,
   $bar => sub { "immediate" },
   $bey => [ \&immediate, $arg, ],

   $mah => [ -defer, \&delayed, ],
[download]

If a "hard link" value is always a double-reference, written with two backslashes and the (properly-typed symbol), then it is consistent. We have:

   &func => \\&internal_func,
   $x => \\$private_variable,
   &foo => \&figure_it_out_at_import_time,
   $y => \&figure_this_out_too,
[download]

The form

   $z => \$what_is_this
[download]

which could be unambiguous for everything other than code symbols can instead be incorrect. Always use a double-ref for hard link.

—John

If a "hard link" value is always a double-reference, written with two backslashes and the (properly-typed symbol), then it is consistent.

My point was aimed in the other direction: are all double-references ever and always going to correspond to your current definition of a "hard link". And not just in this block of code.

That level of unambiguity you won't attain. That may be setting the bar unnecessarily high.

I do think that in two years, the puppy will a dog, and anyone who looks will be tracing the calls to find the point of the extra indirection.

You could document it, but then what is the point?

I think that you've got it turned around. The common case, in my mind, would be import by ref instead of import by callback. The second slash means "Something a little funny is going on" which would be the callback case, to my mind.

Light a man a fire, he's warm for a day. Catch a man on fire, and he's warm for the rest of his life. - Terry Pratchet

If backslash simply means "not the default", then its meaning varies with your expectations.

I'm thinking that it more-specifically means "take it literally, not as instructions to find the answer.". Then you get this progression:

foo => &bar means call bar now when the structure is being built. foo => \&bar means call bar later, when foo is imported (and bar can see the context of what the impoter is asking for). Finally, foo => \\&bar will call bar even later, when foo is actually called after being imported.

—John