my $thing = 'a' x 10;
my @params = ( 2, 3 );
vec( $thing, @params ) = 0;
[download]

Frankly, if we wanted to have compile-time checks, we should be telling the compiler what we expect to happen. So, for example, if @params should have 2 and only 2 things, we should be able to say that. Then, vec() knows that if @params makes it to him, it's got two things. But, even that sucks because you'd have to assign two things to @params - you wouldn't be be able to build it up using push.

So, compile-time checks suck.

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."

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.

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?