Re^5: Prototype for constant items???

[Porculus]

Please try to give me a sub "newjoin" which croaks about this error!

It is, unfortunately, impossible.

You can get pretty close with some runtime heuristics. It's unlikely that people will often deliberately try to join a single-element list using a number as the delimiter, so:

sub newjoin ($@) {
    my $delim = shift;
    if (@_ == 1 and $delim =~ /^\d+$/) {
        carp "Did you mean to put those parameters the other way round
+?";
    }
    return join $delim, @_;
}

Whether that will extend to other functions is, of course, highly dependent on their specific signatures.

I agree with you that it would be nice to have a robust general solution here, but it would seem to be quite a complicated thing to arrange for what could be fairly small gains in practice, and then you have to consider the risk of breaking existing code if you go round messing with how fundamental builtins like join() parse their arguments!

[LanX]

Hi Porculus,

I think you know that join was just an example to illustrate why I'm asking for an extended prototype mechanism. Confusion between scalar and list syntax are one of the main traps in perl.

I don't intend to break existing code nor to change CORE::join. I just want to discuss how to widen the possibilities of future code. And this without waiting another decade for the new perl6 "messiah"¹.

It can't be to difficult to extend the perl5 parser to fill this gap in the prototype definitions. Actually the drawbacks of prototypes are so big that everybody is discouraged to use them.

(Anyway after further meditation I think it was a major design error not to map the scalar of an array on it's ref instead of it's length. An unintentional ref can be much easier spotted at runtime. )

BTW: Your example code won't work with swaped parameters: join @list,$delim since the join of a 1-element list has no delimiter.

(1) don't get me wrong I like perl6, but significantly delaying the evolution of perl5 in consequence is close to osborning.