in reply to Prototype for constant items???

I'd like to construct a prototype which checks at compile time for a "real scalar value" instead of forcing scalar context.

I'd be surprised if that was possible. It also begs the question what to do with test1 other_function

if not forcing scalar context onto other_function. Since context propagates inwards in Perl 5, other_function has to be called in some context, forcing the the return value of other_function to be in that context.

What do you need that feature for? It might be an XY Problem

Perl 6 - links to (nearly) everything that is Perl 6.

Replies are listed 'Best First'.
Re^2: Prototype for constant items???
by LanX (Saint) on Sep 25, 2009 at 13:13 UTC
    No XY-problem, I want the possibility of a more rigid compile-time checking.

    For instance, I want to get warnings/errors for typos like in  join @a,@a (the length of @a will be used as delimiter here)

    Using \$ excludes functions, if I want functions I can still use \[$&], but there is no way to include constants in this list...

    ... OK I have to admit that functions are a problem, too! (Because of scoping, evaluation a coderef inside the prototyped function will produce other return values than passing the return value....)

    sigh ... seems like I have to rely on something like perl critic to achieve this ..

    hmm writing something like the following is a (very unpractical) workaround :

      DB<18> tst2 ${ \"1" }
SCALAR(0x89baac0)

    [download]

    Cheers Rolf

[reply]
[d/l]
[select]
      I want the possibility of a more rigid compile-time checking

      And therein lies your problem.

      Prototypes are primarily hints for the parser what to expect next, and allow you to write functions that syntactically resemble built-in functions.

      When you abuse them for anything else you're bound to run into limitations rather soon.

      Perl 6 - links to (nearly) everything that is Perl 6.
[reply]
        Sadly thats only half of the truth. Many builtins can't be modelled with prototypes and rely on magicly hidden parsing rules.

        So prototypes are only a crippled mechanism.

        The fact that you can restrict to scalarrefs of $variables with \$ but not to refs of literals is an obvious gap in the definition, which you can't deny.

        The possibility to warn about errors like in join @a,@b could make perl much more user friendly.

        I don't even see a possibility to warn about this at runtime!!!

        (well except magic things like using caller to parse the calling the line of code)

        Cheers Rolf

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom