use Perl

• Taming the Beast (Score:1)

  by dpuu (6090)

  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
  • Re: (Score:1)

    by Alias (5735)

    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
    • Re: (Score:1)

      by dpuu (6090)

      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
      • Re: (Score:1)

        by Alias (5735)

        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...
        • Re:Taming the Beast (Score:1)

          by dpuu (6090) on 2008.01.30 12:35 (#60707) Homepage Journal

          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 otherwise you can exist somewhat independently.

          That said, a good way to promote it would be to have the (an) implementation of perl6 were written in this safe subset. A statically analyzable language is easier to optimize at compile-time, so there's an objective technical reason for doing so.

          Reply to This

          Parent