Hallo

ich bin ziemlich angetan davon, dass Filter::Simple mir erlaubt Filtering auf den Code zu beschränken.

Aber wie zuverlässig kann das funktionieren beim "flexiblen" Perl-Syntax? Weiß jemand ob sich Code-Filter so in den Perl-Parser einklinken können dass garantiert nur Code gegriffen wird?

Habe versucht eine Darstellung der Probleme von Code-Filtern zu finden, finde aber nur Allgemeinplätze wie "Code-Filtering ist des Teufels" und eval scheitert.


Weiß hier jemand näheres?

Grüße
R-o-l-f

meine empfehlung: zum ausprobieren und basteln prima, aber niemals in produktion
verwenden, denn es gibt keine garantie, dass es nicht doch bei einem bestimmten
perl-code fehlschlägt. nur der perl-interpreter kann richtig perl parsen,
die filter-module sind alle nur annähernd gut.

LanX-+2008-07-17 16:17:10--

Aber wie zuverlässig kann das funktionieren beim "flexiblen" Perl-Syntax?

Gar nicht zuverlässig, weil es Informationen gibt, die man zum parsen des Perl-Codes braucht, und die erst durch das Ausführen von Compile-Zeit-Aktionen des Compilers bekannt sind. Seihe auch
Perl cannot be parsed: a formal proof.

Ein weiteres Problem ist, dass selbst wenn man einen Source-Filter halbwegs zuverlässig hinbekommen könnte, würde er die Verwendung jedes anderen Source-Filters ausschliessen, wäre also nicht besonders flexibel.

Quote

Weiß jemand ob sich Code-Filter so in den Perl-Parser einklinken können dass garantiert nur Code gegriffen wird?

Es gibt Ansätze wie etwa Devel::Declare, die probieren so etwas umzusetzten. Du kannst auch perl 5.10.0 mit MAD aktiviert compilieren und dir dann das Perlscript als XML ausgeben lassen und das dann verarbeiten.

Quote

Habe versucht eine Darstellung der Probleme von Code-Filtern zu finden, finde aber nur Allgemeinplätze wie "Code-Filtering ist des Teufels" und eval scheitert.

1. Prinzipiell nicht möglich, zuverlässig zu machen (s.o)
2. Sklaieren nicht (s.o)
3. Schlechte Erfahrung. Es passiert z.B. immer wieder, dass ein größeres Script, in das man "use Switch;" einbaut, einfach einen quasi unverständlichen Syntax-Fehler schmeisst, selbst wenn man die Features dieses Modules noch gar nicht benutzt. Womit wir auch zum nächsten Punkt kommen:
4. Die Fehlermeldungen sind meistens alles andere als hilfreich.

Danke erstmal für die Auflistung :-)

> 1. Prinzipiell nicht möglich, zuverlässig zu machen (s.o)

Die Paradoxie ist doch: Adam Kennedy zeigt das Perl unparsable ist und entwickelt trotzdem PPI.

> 2. Sklaieren nicht (s.o)

Gutes Argument. Zumindest Smart::Comments sollte noch laufen ;-)

> 3. Schlechte Erfahrung. Es passiert z.B. immer wieder, dass ein größeres Script, in das man "use Switch;"

OK aber Switch ist auch etwas komplex... und zum Glück braucht mans wohl nicht mehr.

> 4. Die Fehlermeldungen sind meistens alles andere als hilfreich.

Das ist wohl war...

LanX-+2008-07-18 11:04:26--

> 1. Prinzipiell nicht möglich, zuverlässig zu machen (s.o)

Die Paradoxie ist doch: Adam Kennedy zeigt das Perl unparsable ist und entwickelt trotzdem PPI.

Nur ist die Intention eine andere. PPI soll Perl-Sourcecode als Dokumente parsen, mit Source-Filtern will man es als Programm parsen.

Normalerweise setzt man PPI ja auch für Sachen ein, wo es nicht so schlimm ist, wenn etwas falsch geparst wird, z.B. Syntax-Hilighting oder Perl::Critic. Das sind üblicherweise keine Fälle, wo du aus Versehen mal alle Kundendaten löschst, wenn da was falsch geparst wird. Klar ist das auch bei Source-Filtern unwahrscheinlich, kann aber durchaus passieren.

Schönes Wochenende,
Moritz

LanX-+2008-07-18 11:04:26--

> 1. Prinzipiell nicht möglich, zuverlässig zu machen (s.o)

Die Paradoxie ist doch: Adam Kennedy zeigt das Perl unparsable ist und entwickelt trotzdem PPI.

Er ist während der Entwicklung erst darauf gekommen. Und daher gab es einen Focus-Shift.

Ich frage mich, ob es nicht möglich wäre herauszufinden, welcher Perl-Code parsable ist und welcher nicht. Denn nicht überall werden Begin-Blöcke, evals u.ä. verwendet. Man könnte dann ja in einem "unsave mode" weiterzuparsen versuchen. Und man könnte dann bei Doppeldeutigkeiten eine Schätzung machen, was vermutlich gemeint ist. (Das macht Perl ja sogar selbst manchmal.)

Manchmal wünsche ich mir schon, dass mein Syntax-Colorer klüger wäre.

Aber zu welchem Zweck wird ein Parser eingesetzt, der dann tatsächlich Code ausführt? Hat da jemand ein Beispiel?