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.
  • You are working under the assumption that you won't be able to reuse the existing toolchain to write these tools.

    The approach that everyone seem to be aiming for is that instead of writing PPI all over again for Perl 6, you are supposed to get decent enough support form the actual grammar that ships with the compiler in order to do your own interesting things with it.

    Secondly, since Perl 6 supports separate compilation units in many ways this is actually much simpler than Perl 5 - there is no more possibili
    • > In other cases, if it's safety you're after, in not running the compile time code, then theoretically you just use something like perl 5's Safe on all the macros and grammar extensions.

      Only if you can solve the Halting Problem.

      In Perl 5, even trivial Perl examples involve BEGIN blocks (use strict) and grammar modification (operator/operand switching).

      This problem applies to Perl 5 to.

      Simon Cozens has a never-released parser based on the Perl internal parser.

      It works just fine, as long as the code compi
      • The halting problem only applies to code you cannot introspect.

        If you have a function, and that's all, then you can't find out what's in it.

        But given a compiled optree, you have much more information.

        If you parse the BEGIN { } block under the current rules, then you wind up with an optree which you can then examine, to see what it does.

        As for simon's project - perl 5's parser was never designed to make this easy, it was designed to emit an interpreter optimized optree. This is very different from the design
        • We probably need to escalate this to a formally trained mathematician here, but as I understand it, it applies to any case with "arbitrary" code whether introspectable or not.

          You CAN prove something will finish in finite time, you just can't prove how long that finite time is, which may be longer than the heat death of the universe.
          • Errm, you would have done well to follow your own advice and stop at the end of the first sentence. :-)

          • No, that is just plain wrong.

            You can very easily prove that the program 1 + 1 will return in finite, and short time, and it has nothing to do with heat death of the universe (very long != infinity).