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.

Why Perl 6 scares the hell out of me 6 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Seems to me the trick is to separate grammar changes from BEGIN blocks. That is, you have explicit blocks which do nothing but change the grammar. They can't execute code, they can't call eval, they can't declare variables, they can't load modules (except other grammar-only modules). They would then allow two critical things for tools:

    1) They're safe to execute.
    2) The tools can be made aware of grammar changes.

    It might not even need to be as restrictive as all that, maybe just that grammar changes happen in a "Safe" compartment which doesn't allow access to the outside world. This allows some flexibility when defining the grammar while still making it safe to run.

    It might already work this way, I haven't looked.
    • The problem is that the grammar is code itself.
      • That may not be a problem if the code is never run...

        If "=" is mapped to sub equals, you shouldn't need to run equals while parsing, right?
        • You don't understand. The grammar itself is a class. The parsing primitives are methods. It is actual Perl 6 code that does the parsing, you don't get a BNF for it.
          • The parsing primitives are controllable and, fortunately, NOT arbitrary code.

            And so they don't present a decidability problem, at least for the parsing primitives that are available out the box.

            If we DO allow arbitrary grammar modifications, and those modifications will result in the execution of arbitrary code, well then we're back into the decidability quagmire again.

            In fact, if arbitrary grammar chances are trivially associational with arbitrary compile-time execution then that should pretty much clearly
            • Go over the synopses again then... You can definitely define grammars in terms of code.

              However, as long as this is trusted code, which you can determine by introspecting it, I don't think this is a problem.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.