in reply to callback or call now?

This is a puppy that will grow up to bite you. It is cute and appealing though.

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, ],

Replies are listed 'Best First'.
Re: Re: callback or call now?
by John M. Dlugosz (Monsignor) on Oct 17, 2002 at 14:59 UTC
    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,
    The form
    $z => \$what_is_this
    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?

        Yes, I posted it because I think it would be a useful idiom in general for \\&foo to mean the same as sub{\&foo} to code that does this kind of stuff.

        As for its presence in this module causing farther spread that must be traced back to this module's use of it, it won't happen with this particular module. I expect it will be "statically" configured in a hash, not generated and passed in by other code (since this happens first!). The internal use to figure out what different types of values mean will all be encapsulated.

        —John