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

      by dpuu (6090) on 2008.01.30 1:24 (#60680) Homepage Journal

      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 selling tools that could synthesize subsets of the languages down to gates. The "Synthesizable Subset" became a de-facto standard: it was the subset that you used if you wanted you code to synthesize across the tools from multiple vendors. More recently, SystemVerilog and SystemC are following a similar path.

      Not everything can be defined using the synthesizable subset. Analog components, and complex cores, would be defined as "black boxes", with behavioral models (i.e. full language models -- or even models written in other languages such as C++) for simulation; plus meta data to define the relevant properties to the tools.

      I would see the same path being followed for Perl6. Language designers and library implementors will use the whole language. People, such as yourself, will create tools that understand some useful subset. If other people agree that the subset is useful then they will limit themselves to that tool; and module authors will have an incentive (users!) to create the meta data. The exact form of meta data need not be part of Perl. It could be a separate domain-specific language -- though one could argue that Perl6 should have the hooks to allow it to be associated with the code (perhaps via POD).

      So I say, don't wait for the subset to be blessed by @larry before creating the tool. Pick some arbitrary subset (e.g. pugs) and tell people of all the cool things they can do if they restrict themselves to just those features. If it's not cool enough, then add more features! I'd hope that a symbiotic relationship could form between programmer-tools and language-design.

      Reply to This

      Parent

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

          by dpuu (6090)

          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