in reply to Re^3: Slow evolution of Perl = Perl is a closed Word (use)
in thread Slow evolution of Perl = Perl is a closed Word

Do you know whether there are any examples of this that aren't Source-Filter related issues ?
Of course there are. 
use constant FOO => 1234;

[download]
Whether or not this line is parsed/run first will change how the next line is interpreted: 
print FOO;

[download]

This will either be treated as printing a constant, or printing $_ to a filehandle FOO.

And functions with prototypes: 

foo +3

[download]
will be parsed differently if foo is declared first as 
sub foo ();

[download]
or with 
sub foo;

[download]

It means foo()+3 in the former and foo(3) in the latter case.

(It'll do the same if the sub with body is placed in the source code before the call, without the separate declarations, or in a module you use.)

And no source filter in sight.

Replies are listed 'Best First'.
Re^5: Slow evolution of Perl = Perl is a closed Word (use)
by erroneousBollock (Curate) on Sep 02, 2007 at 06:06 UTC
    Both those mechanisms are very predicable in their effect on source code. In those cases, a pre-parse of the source code could yield information which could be easily used by the static analyzer.

    Source filters are more difficult because they can have arbitrary effects on the parse of the source code. Possibly some new construct would be necessary to (at least) document the effect of a source filter on the AST.

    As tye mentioned, BEGIN {} blocks (and equivalent constructs) are much more problematic, as they are truly computed at runtime. Perl is arguably much more context-sensitive than languages like C# or Java, but with a few simple heuristics a very simple static analysis could be performed.

    I also don't see why it's all or nothing... the IDE could get it 99% right and could deal with parser/analyzer warnings in a flexible policy-based (or case-by-case) manner (perhaps with configuration from the user).

    I'm not saying it would be easy... just possible. Interest would be the limiting factor.

    -David

[reply]
[d/l]
      Both those mechanisms are very predicable in their effect on source code. In those cases, a pre-parse of the source code could yield information which could be easily used by the static analyzer.
      That would be quite a pre-parse, even for the simplest cases.

      In most cases, though, the parse-affecting statement occurs in another file, whose very location may require executing some of the perl code to determine. Or in XS.

[reply]
      No, it's not dead easy. As ysth said, you have to see what words do, prototype-wise, in other modules.

      You typically would have to know which words from that module are getting exported. There could be some system in how it's dealt with, when they're only relying on Exporter, but import is a plain class method. You can implement what it does however you like.

[reply]

In Section Meditations