in reply to Re^5: What would you change?
in thread What would you change?

That results with "Not enough arguments for vec()." And, illustrates in brilliant colors the stupidity of compile-time checking in a dynamic language.

I see what you mean. And boy, do I ever agree with you regarding attempts to force static language semantics upon dynamic languages.

Playing with this, my first thought was to disable the prototype checking: 

&vec( $thing, @params ) = 1;

[download]

but that resulted in: Can't modify non-lvalue subroutine call which came as a complete surprise.

I never knew that the l-valueness of a subroutine was allied to its prototype. The best alternative I came up with is: 

sub myvec :lvalue { CORE::vec( $_[ 0 ], $_[ 1 ], $_[ 2 ] ) }

[download]

which once you get past the deliberate error ;) in the example: 

my $thing = 'a' x 10;
my @params = ( 2, 3 );
myvec( $thing, @p ) = 1;;
Illegal number of bits in vec

[download]

seems to work fine. Of course, you pay a performance penalty for the indirection, but hey. CPU cycles don't matter :)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^7: What would you change?
by ikegami (Patriarch) on May 20, 2008 at 00:40 UTC

    never knew that the l-valueness of a subroutine was allied to its prototype

    It's not. &vec calls vec of the package in which you happen to be, not the core function. 

    >perl -e"&vec()"
Undefined subroutine &main::vec called at -e line 1.

    [download]

    The (presumably non-existant) vec in your current package is not an l-value sub, thus the error messag. You can't use & on core functions.

[reply]
[d/l]
[select]

      Good point and (probably) a good call, but I'm now wondering about the difference betweem the error message you got and that I got: Can't modify non-lvalue subroutine call ...?

      I'll have to see if I can reproduce the situation. I was running my REPL at the time.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
        The difference is that I didn't use it as an lvalue. Perl checks whether or not it can be used as an lvalue before trying to execute it. 
        >perl -e"&vec()"
Undefined subroutine &main::vec called at -e line 1.

>perl -e"&vec() = 1"
Can't modify non-lvalue subroutine call at -e line 1.

        [download]
[reply]
[d/l]
Re^7: What would you change?
by dragonchild (Archbishop) on May 20, 2008 at 00:08 UTC
    The more I think about this vs. Haskell/Scala, the more I come to the conclusion that compile-time checking can actually work in a dynamic language. We just have to be smart about what we're checking. I mean, Haskell has compile-time checking all over the place and it's dynamic.

    I think the point here is that the more side-effect free you can be, the more comprehensive your checking can be. I'm not sure where this meander is going, though.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]
      I mean, Haskell has compile-time checking all over the place and it's dynamic.

      Hm. Perhaps we are at crossed threads after all. The concept of Haskell being a dynamic language goes right over my head. Indeed, if that article is anything to go by, I'd say that it was damn nearly impossible for Haskell to:

      • extend the program, by adding new code;
      • extend objects and definitions;
      • modify the type system;

      all during program execution.

      I would say that it runs exactly contrary to the entire motivation of Haskell.

      It's interesting to conceive of what it would take, and the processing power it would require, for Haskell to eval generated statements at runtime and cross-reference (and inference) the types generated, with whatever remains of the type annotations that where present in the source code of the original program.

      AFAIK, the whole basis of term rewriting is that once type compatibility has been verified, the expansion and/or reductions of terms can be directly substituted for the terms they rewrite, and so large chunks of the definitions in the original source code don't make it into the object code in a recognisible form whatsoever. It would therefore be impossible to extend the compile-time type system at runtime.

      I realise that a Haskell program can be written to parse, compile and run (or interpret) a different type system (language; ala. pugs), but a Haskell program that could eval code at runtime and then extends its own type system on the fly, is a whole different ball of wax.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        I was always under the impression that any language that implements lambda is a dynamic language. I am more than willing to be mistaken.
        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
[reply]

In Section Meditations