Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • The reasoning of the article -- that dynamic languages (where the language itself is dynamic) are difficult (perhaps impossible) to analyze statically seems reasonable. The proposed solution: less so.

    Lets assume that we don't want to hobble perl6 before people have had a chance to evolve it -- yet we still want tools that can safely analyze non-trivial applications of it, without running those applications -- not even the "BEGIN" blocks. What would be required?

    The answer is probably that you'd need to require any grammar modification to be accompanied by some meta data. Perhaps one could say that grammar modification is only permitted by a "used" module, and that it is allowed to modify the grammer only of its user, not itself. This would mean that the code analyser would need to see the meta data associated with the "use Foo;" statement, but not necessarily the code associated with module Foo.

    This proposal might hobble perl-6 too much. So there's a second fallback: define a dielect (subset) of perl that enforces this rule. If you're writing perl6 code yourself, and so know that you want to use the tool, then you'd only permit yourself to use modules that conform the the appropriate meta-data spec (C6PAN modules might be tagged that they support it). A lint tool that sees you using a module that doesn't contain the meta data (minimal: "this module doesn't mess with it's user's grammar" tag) would issue an error.

    Summary: I agree that unconstrained perl6 will be so dynamic that it is impossible to analyze statically, but my gut tells me that it will be possible to define a tame subset that can be analyzed. Library writers, and JAPHs, and golfers, would use wild-perl; corporate enterprise users would use tame-perl.

    • I concur completely with both your conclusions and suggested adaptations.

      This is pretty much what I'm advocating.

      The key differentiation is perhaps that I strong think we need to define and support this subset/strict form of Perl 6 from day one and have it a considered part of the language, rather than try to hack something afterwards.

      To quote Larry, "Why do people seem to keep thinking I'm only creating one language here".

      From these N languages he is allowing, we need to at some point nail down an identifi
      • I guess the place where I disagree is the "have it considered part of the language" bit (other than that, by definition, a subset is part of the whole).

        My background is ASICs. The history of semiconductor design is one of increasing abstraction while maintaining a path to implementation (i.e. to manufacturable hardware). Many years ago, Verilog and VHDL appeared as hardware modeling languages. Tool vendors saw opportunity for profit if they could convert "models" to "implementation", and they started sell

        • Thanks for the great precedent.

          The thing in this case is that the language still hasn't been finalized, and if at all possible I'd like this subset blessed and supported internally.

          For example, not just detailing the subset but actually having the parser finalize the grammar class by default, or something, so that the subset is both provable and enforcable.

          And if that fails, well THEN we look at the alternatives...
          • I'd be tempted to go down the road of being explicit -- avoids the political pain of fighting for the subset. In perl5, people are used to saying "use strict" at the top of every file. You could create a "use strict::static" module that (a) tells your tool that the user's module should be analyzable; and (b) modifies the grammar to eliminate the ability to modify the grammar. If the core language doesn't allow you to write such a module then you have a strong case to argue to tweak the language; but otherwi
      • Do you mean something like the Scheme standard revisioning process for a "Standard Perl"? That could actually be nice. Especially since we have a (assumably (is that even a word?)) larger userbase and a (also assumably) more practical than academic POV.

        Ordinary morality is for ordinary people. -- Aleister Crowley