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
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Taming the Beast (Score:1)
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.
Reply to This
Re: (Score:1)
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)
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)
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)
Re: (Score:1)
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
Re: (Score:1)
(The word you were looking for is “presumably.”)