Die IdeeMit GHC API Haskell Quellen zu Core- und Core auf binäre
Hallo zu kompilieren! Ich möchte ein Programm erstellen, das Haskell Core generiert und GHC API verwendet, um es weiter in eine ausführbare Datei zu kompilieren. Aber bevor ich es mache, möchte ich ein sehr einfaches Beispiel konstruieren, das zeigt, wie wir Haskell-Quellen einfach in CORE und dann in die Binärdatei kompilieren können.
Das Problem
Ich habe eine Menge von Dokumentation und versucht, viele Methoden von GHC Api, aber jetzt ohne Erfolg lesen. Ich habe mit Official GHC Api introduction begonnen und die Beispiele erfolgreich zusammengestellt. Die Beispiele zeigen die Verwendung der folgenden Funktionen: parseModule, typecheckModule, desugarModule, getNamesInScope und getModuleGraph, deckt jedoch nicht den abschließenden Kompilierungsschritt ab. Auf der anderen Seite gibt es einige Funktionen in der API, deren Namen auf das Problem bezogen sind, wie HscMain.{hscCompileOneShot, hscCompileBatch} oder GHC.{compileToCoreModule, compileCoreToObj}. Ich habe versucht, sie zu benutzen, aber ich bekomme Laufzeitfehler, wie in diesem Beispiel:
import GHC
import GHC.Paths (libdir)
import DynFlags
targetFile = "Test.hs"
main :: IO()
main = do
res <- example
return()
example =
defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
let dflags' = foldl xopt_set dflags
[Opt_Cpp, Opt_ImplicitPrelude, Opt_MagicHash]
setSessionDynFlags dflags'
coreMod <- compileToCoreModule targetFile
compileCoreToObj False coreMod "foo" "bar"
return()
, die mit ghc -package ghc Main.hs zusammengestellt werden können und die Ergebnisse in der folgenden Fehler während der Laufzeit:
Main: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-linux):
expectJust mkStubPaths
die natürlich kann das Ergebnis einer falschen API-Verwendung sein, insbesondere wegen der Zeile compileCoreToObj False coreMod "foo" "bar", wenn die Zeichenfolge nur zufällige Zeichen sind, weil die Dokumentation nicht viel über sie aussagt. Wenn wir in die Quellen schauen, scheint es, dass der erste der Name der Ausgabe ist und der zweite "extCore_filename" ist, was auch immer es sein könnte.
Eine weitere beunruhigende Sache ist der Kommentar in der Dokumentation neben die compileCoreToObj Funktion:
[...] Das hat bisher nur mit einem einzigen eigenständigen Modul getestet.
Aber ich hoffe, es wird keine weiteren Probleme einführen.
Die Frage
Was ist die beste Art und Weise, diese Lösung zu schaffen? Wie können wir ein minimales Arbeitsbeispiel erstellen, das Haskell-Quellen lädt, sie in das CORE kompiliert und dann den Kern zur finalen ausführbaren Datei kompiliert (unter Verwendung der GHC-API). Der Zwischenschritt wird für das weitere Ersetzen durch benutzerdefiniertes CORE benötigt.
Als Neben Frage - ist es derzeit möglich GHC mit externen Core-Dateien zur Verfügung zu stellen oder diese Funktion ist noch nicht implementiert, und ich werde den Core manuell konstruieren muß, mit GHC.Api (bezogen auf: Compiling to GHC Core)
aktualisiert
konnte ich endlich ein kleines Beispiel erstellen ermöglicht ein Modul zu laden und es zu .hi und .o Dateien zu kompilieren.Dies ist keine Lösung für das Problem, weil es nicht erlaubt, mich um den Kern zu ersetzen und es keine Verknüpfung die Objektdateien in ausführbaren Dateien noch:
import GHC
import GHC.Paths (libdir)
import DynFlags
import Linker
import Module
targetFile = "Test.hs"
main :: IO()
main = do
res <- example
return()
example =
defaultErrorHandler defaultFatalMessager defaultFlushOut $ do
runGhc (Just libdir) $ do
dflags <- getSessionDynFlags
let dflags2 = dflags { ghcLink = LinkBinary
, hscTarget = HscAsm
}
let dflags' = foldl xopt_set dflags2
[Opt_Cpp, Opt_ImplicitPrelude, Opt_MagicHash]
setSessionDynFlags dflags'
setTargets =<< sequence [guessTarget "Test.hs" Nothing]
load LoadAllTargets
return()
Die Entwickler der [ghc-Mailingliste] (https://www.haskell.org/mailman/listinfo/ghc-devs) sind wahrscheinlich diejenigen, die die Antworten haben, nach denen Sie suchen. – gxtaillon
Ich glaube, dass in letzter Zeit Arbeit geleistet wurde, Plugins Kern-zu-Kern-Umwandlungen innerhalb der GHC-Pipeline zu ermöglichen. nicht genau das, was du willst. Vielleicht könnten Sie kurz erklären, warum Sie diesen präzisen Arbeitsablauf durchführen möchten. –
@ChristianConkle Ich möchte nicht 'CORE -> CORE' Plugin. Ich erstelle meine eigene Sprache und möchte sie zum Kern kompilieren und dann GHC-Pipeline verwenden. Entschuldigung für Unklarheiten. –