in reply to Re: Prototype for constant items?
in thread Prototype for constant items???

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)

Cheers Rolf

Replies are listed 'Best First'.
Re^3: Prototype for constant items???
by moritz (Cardinal) on Sep 25, 2009 at 13:37 UTC
    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.
      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

        Sadly thats only half of the truth. Many builtins can't be modelled with prototypes and rely on magicly hidden parsing rules.

        That's why I wrote syntactically resemble

        And yes, this is indeed a problem. Maybe not for own function (which rarely need such things), but when you try to override built-ins. For example autodie does that, but can't handle all the variants that the core functions do.

        It's one of the things we try to make better in Perl 6: no built-in should rely on magic that's not available to the user, so that everything can be overridden and mimicked. So far I think we did a rather good job at that, though much of that isn't implemented yet.

        As far as we can assure that candidate lists known at compile time, it would also be possible to catch some form of errors then (like arity mismatch).

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