Damian Conway wrote:
> I very much doubt Perl is going to become significantly more statically
> analyzable in general. Though static determinacy is obviously a
> desirable thing, there are plenty of other B&D
Bondage and Discipline?
> languages that offer it
> in abundance. And the dynamic power that Perl would have to lose would not
> compensate for the static benefits gained.
>
> Damian
>
> PS: Of course, as always, Larry's MMV on that ;-)
Main Man Vote?
One of the major features of Perl is that it can cross between "data" and
"code" so easily (eval, inserting into the namespace at runtime, changing the
inheritance tree at runtime, computed method calls, computed gotos, etc.).
I knew this, but it is rather amazing how many different examples of this
people used against my arguments for "strong" type checking at compile time.
What about a trade-off between compile time checking and run time checking?
I think everyone agrees that if something is going to fail, it is better for
you to find this out sooner rather than later. Compile time is sooner, run
time is later, and when the IRS audits a customer who's taxes were done wrong
because of a subtle data corruption bug you never caught in testing is even
later. Can we move the time when you catch the type failure error at least
somewhat sooner, even if we can't get it all the way to compile time? Perl
already has other intermediate "times". For example, the BEGIN block code is
run during compile time.
I suggest that for most programs you could "factor out" all of the
data-to-program bits of your code (that prevent compile time checking) into
an initial phase of your program. After that phase is ended (all the
autoloading is done, inheritance tree modified, whatever) you run the
"compile time" checker on your own program, perhaps giving it a set of
sentences to verify, such as "This class/package is sealed". If there is a
type failure, at least you get the error right then, before you tell the
robot to pick up the car. Assertions are good for checking that *data* has
properties I expect. If data can be come program (as in Perl), I want
assertions that my *program* has properties I expect.
For those of you who love code that manipulates its own internals, you can
see such "assertions about the program" are a kind of introspection into your
own parse tree. People have written compilers that first parse and then
allow your custom plug-in to check properties of the parse tree. These
"assertions about the program" could be implemented that way. First you call
"parse", which is used just like the current "eval", but instead returns the
parse tree. Then have your own routines traverse over the tree and verify
any properties your heart desires. A few standard ones implementing, say,
sealed classes, would of course show up on CPAN.
This strategy would of course require a "parse" to produce a nice parse tree
data structure, with all the compile time properties conveniently attached.
It would also be nice if afterward, you could turn off some/all of the
data-to-program features, like namespace manipulation.
Daniel
