Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Let's ignore source filters, because presumably any proof to see if a program halts will necessarily happen on the post-filtered source. (This is regardless of whether you're talking about C+cpp, Lisp + Macros or Perl + Source Filters.) I'm not familiar with any of the formal theories here, but in your (somewhat contrived) example, it should be reasonably easy to tell that the second Perl program terminates. The hard part is when your termination conditions are derived from side effects, like environment variables, time of day, or input to your program. (Not the kind of thing you need to worry about in a device driver.)

    Finding degenerate cases in Perl is actually simpler than what you posit, because of tied variables. Because any variable can be tied, it's not immediately obvious if a program will halt, because a tied method could call die, which will be handled by an eval {} three or four levels up the stack (or not). Then again, it may not be a tied variable; it may be a regular variable, or tied some of the time. Then there's objects, duck typing, reblessing, etc.

    Tcl has the same problem, with variable traces. The principle is similar to a tied variable -- any variable can have a "trace" function attached to it that will fire whenever the variable is updated. Great if you have a few magic variables that trigger a GUI update whenever they're modified. Horrible whenever you're trying to capture full Tcl semantics, or apply any kind of reasoning on the behavior of some random Tcl program.

    It's (currently) an either-or decision: either you take the benefit from increased dynamism and flexibility, or you open yourself up to the possibility of benefits from automated reasoning about your program. (Note that decidability and type safety theorems don't map particularly well to C at the moment.)

    All in all, these kinds of tools would be nice to have, but they aren't a compelling reason to stop using Perl.
    • This seems similar to the arguments for static typing -- it lets you build a better IDE because you can reason about the code (eg: what methods does this object have?) In a dynamic language like Perl, that's much, much harder. But it does mean that interfaces in Perl tend towards being simpler and not requiring an IDE, unlike Java.

      -Dom