Müssen Perl 6-Programme kompiliert werden, um eingebettete Dokumente zu lesen?

8

Perl 6 Plain-Old-Documentation (vielleicht Fancy-New-Documentation) hat einige Funktionen, die es erlauben, Dokumentation für Dinge zu erstellen, die es sieht, und die Dokumentation erscheint zur Laufzeit in der $=pod -Variable.

Ich war jedoch überrascht, als ich die Dokumente nicht lesen konnte, als ich im Programmtext einen Fehler gemacht hatte. Hier habe ich ein Trennzeichen zwischen zwei Anweisungen weggelassen:

%Vor%

Wenn ich es mit dem Schalter --doc starte, ist die Programm-Syntax wichtig (und BEGIN läuft):

%Vor%

Wenn ich es repariere, bekomme ich einige Warnungen (also, Perl6 kompiliert) und die Compiler-Zeit-Compiler laufen:

%Vor%

Wir wissen bereits, dass dies in Perl 5 ein wenig gefährlich ist. Ein perl -c und ein BEGIN Block können Code ausführen. Siehe Wie überprüft man, ob ein Perl-Skript keine Kompilierungsfehler aufweist? . Ich denke nicht, dass dies gefährlicher ist als etwas, das wir bereits kennen, aber jetzt passiert es zu einer Zeit, in der ich nicht explizit etwas zum Kompilieren von Programmanweisungen abfrage.

Ich habe mich nicht mit den Details von Perl 6 pod beschäftigt und warum dies außerhalb von Deklaratorblöcken und .WHY (ein cooles Feature) notwendig ist, aber es scheint, dass dies zu Problemen führen kann. Gibt es vielleicht ein externes Programm, das den Pod extrahieren könnte? Oder eine Möglichkeit, auf die Deklaratoren zu verzichten, wenn das Programm nicht ausgeführt wird?

    
brian d foy 01.12.2016, 09:39
quelle

1 Antwort

1

Ja, die ganze Datei muss geparst werden, was wiederum das Ausführen von BEGIN und use Anweisungen und so.

erfordert

Die Programmiersprache Perl 6 ist für das Parsen in einem Durchgang von oben nach unten ausgelegt, so dass der Parser an jedem beliebigen Punkt versteht, was analysiert wird, basierend auf dem, was er bisher analysiert hat . p>

Betrachten Sie einen Code wie den folgenden:

%Vor%

Wenn Sie die Datei nur nach POD-Anweisungen durchsuchen würden, ohne sie vollständig zu analysieren, würde dies diesen Codeabschnitt falsch interpretieren.

i.e. Sie können nicht nur die POD-Teile analysieren, ohne die normalen Perl 6-Code-Teile zu analysieren, denn ohne alles von oben nach unten zu analysieren, können Sie nicht wissen, welches das ist.

PS: Theoretisch hätten die Perl 6-Entwickler POD-only-Parsing berücksichtigen können, indem sie es für normalen Perl 6-Code verboten hätten, Zeilen zu enthalten, die aussehen, als würden sie einen POD-Block starten. In diesem Szenario wäre das obige Code-Snippet ein Syntaxfehler, wenn die gesamte Datei geparst wird, da das Starten einer Zeile in einem String-Literal mit =begin pod nicht zulässig ist. Daher kann der --pod -Schalter auf alle Zeilen zurückgreifen, die mit beginnen =begin foo startet tatsächlich einen POD-Block.

Eine solche Einschränkung wäre wahrscheinlich keine große Belastung für normalen Perl 6-Code (schließlich muss =begin pod am Anfang einer Zeile in einem Zeile string literal) , aber beachten Sie, dass einer der Gründe für die One-Pass-Top-to-Bottom-Analysearchitektur darin besteht, die Spracherweiterbarkeit über Slangs zu erleichtern.
Z.B. CPAN-Module könnten Unterstützung für Benutzer hinzufügen, die eine einzelne Subroutine (oder einen anderen lexikalischen Bereich) in einer anderen Sprache oder DSL schreiben. (Das Implementieren solcher Module ist eigentlich noch nicht möglich, ohne in Rakudo Interna über NQP zu hacken, aber sobald das Makro / Slang Design fertig ist, wird es sein) Die Belastung für das Verbot von Zeilen, die aussehen, als würden sie einen POD-Block starten, würde dann an all diese Slang-Parser weitergegeben werden.

Sie könnten jedoch immer eine Feature-Anfrage für Larry und die anderen Perl 6-Designer einreichen, um dies zu berücksichtigen.

    
smls 01.12.2016 12:44
quelle

Tags und Links