Projekte

Das Arbeiten mit 􊨖lgola soll natürlich von Anfang an so einfach wie möglich sein. 􊨖lgolab sieht sich deswegen in der Verantwortung, mit der Freigabe der Sprache auch den Kern der Infrastruktur zu liefern. Dazu beschäftigen wir uns unter anderem mit den folgenden Projekten.

Dokumentation

Zumindest für einen Entwickler ist eine vernünftige Dokumentation deutlich wichtiger als das fertige Produkt. Zur Dokumentation zählen allerdings nicht nur das Dokumentieren und Kommentieren des Compiler-Codes, was bereits während der Entwicklung erledigt wurde, sondern auch das Bereitstellen von Dokumenten für unterschiedliche Gruppen von Anwendern.

Beispielsweise wird noch eine Einführung für Programmieranfänger benötigt. Sehr hilfreich wären vielleicht auch Überblicke für Umsteiger von diversen Sprachen, die besonders auf die Unterschiede und Erweiterungen eingehen – mindestens für Java-Entwickler. Darüber hinaus besteht ein Bedarf an Meta-Dokumenten, die Entwicklern dabei helfen sollen, Dokumente und Programme zu schreiben sowie Änderungen bei 􊨖lgola anzuregen und durchzuführen.

Bis zur Freigabe sollen alle Dokumente (auch) in Englisch verfügbar sein; sie werden aber aktuell noch in Deutsch verfasst.

Compiler

Das wichtigste Projekt ist natürlich der 􊨖lgola-Übersetzer selbst. Im Zusammenhang mit der Finalisierung der Spezifikation muss die Entwicklung des Compilers abgeschlossen sein. Anschließend will dieser noch optimiert werden, was sowohl das Parsen als auch das Generieren von Code betrifft.

Gegenwärtig wird aus 􊨖lgola-Quellcode zunächst intermediärer 􊨖ir-Code erzeugt, aus dem Bytecode für die JVM generiert wird. Neben der Unterstützung der JVM sollen zukünftig (optimalerweise noch bis zur Freigabe im September) weitere virtuelle Maschinen unterstützt werden, allen voran die LLVM und mittelfristig auch die CLR; langfristig sollen auch Quellen für andere Sprachen generiert werden, beispielsweise ECMAScript oder C/C++.

Standardbibliothek

Obwohl mit der Bindung an die JVM der unschätzbar umfangreiche Fundus des Java-Ökosystems zur Verfügung steht, muss es eine Bibliothek geben, die auch den über Java hinausgehenden Ansprüchen von 􊨖lgola genügt. Dazu gehört etwa eine Vereinheitlichung der Schnittstellen, bei denen Einheiten (etwa zur Angabe von Zeitdauern) zum Einsatz kommen. Darüber hinaus wollen Pakete neu verpackt werden, sodass zum Beispiel Berechnungen mit BigInteger-Werten mit Operatorensymbolen (+, −, ⋅, ÷) durchgeführt werden können.

Des Weiteren sollen die Collections derart aufgebohrt werden, dass sie

• unveränderliche Varianten bieten, die ggf. lokal mit Buildern aufgebaut werden können;
• die korrekten Symbole verwenden (etwa ∈, ∉, ⊂, ⊄, ⊆, ⊈, …);
• die nötige Unterstützung für die Quantoren ∀ und ∃ mitbringen; und
• im Zusammenhang mit Generatoren, wie beispielsweise bei
      {(x, y) ∣ x ∈ S, y ∈ T, y ∉ S},
  eingesetzt werden können.

Schließlich wollen noch einige Klassen verallgemeinert und spezialisiert werden, speziell im Hinblick auf die in 􊨖lgola zusätzlich zur Verfügung stehenden Typen (etwa nicht negative Zahlen ℕ oder Register mit mehreren Zahlen 𝔽₃₂⁴). Bei der Gelegenheit kann auch die Bezeichnung verbessert und vereinheitlicht werden, um Klassen intuitiver zu benennen (beispielsweise File vs. Path, Collection vs. Container, Vector vs. List, …).

Integrierte Entwicklungsumgebung (IDE)

Nicht nur weil 􊨖lgola viele Zeichen aus dem Unicode nutzt, bedarf es einer besonderen Unterstützung für IDEs. Beispielsweise werden Zuweisungen durch einen Pfeil symbolisiert (etwa x ← 0) und Vergleiche durch die „korrekten“ Vergleichsoperatoren <, ≤, =, ≠, >, ≥ dargestellt (etwa a ≤ b < c). Neben einer auf NetBeans basierenden vollständigen Umgebung soll es Plug-ins für Eclipse, IntelliJ IDEA und NetBeans geben.

Diese Erweiterungen verlangen nach den üblichen Hilfsmitteln – vom vollständigen Übersetzen beim Abspeichern bis hin zur Code-Vervollständigung. Dies hat ebenso Auswirkungen auf das Design des 􊨖lgola-Compilers, der auch für diesen Zweck zur Verfügung steht. Jener ist deswegen in der Lage, eine Quelle auch nur in Teilen (etwa nur eine Methode) zu übersetzen. Auf diese Weise werden Effekte verhindert, die beispielsweise gelegentlich in der Java-Welt auftreten: Programme, die sich innerhalb von Eclipse übersetzen lassen, aber nicht in NetBeans.

Forschung

Unabhängig von den praktischen Anforderungen gibt es noch eine Reihe interessanter Ideen, die einer weiteren Erforschung bedürfen. Dabei soll die folgende Liste an – aus „Geheimhaltungsgründen“ – eher nicht so spannenden Fragen nur einen Vorgeschmack geben, was es noch zu untersuchen gilt.

• Ist es beispielsweise mit vertretbarem Aufwand möglich, Collections automatisch in eine andere Repräsentation zu überführen, wenn dies die Daten oder das Nutzungsverhalten nahelegen?
• Inwieweit kann der Compiler (möglicherweise mithilfe von Annotationen) effizienten Code für SIMD-unterstützende Prozessoren generieren, ohne den Entwickler a priori damit zu belasten?
• Gibt es ein elegantes Modell samt Umsetzung von (Software oder Hardware) Transactional Memory für 􊨖lgola?
• Welche Berechnungen können zur Übersetzungszeit ausgeführt werden, ohne dabei die Dauer des Übersetzungsvorgangs unverhältnismäßig zu verschlechtern? Wie können diese verzögert ausgeführt werden, ohne das unmittelbare Feedback zu behindern? Wie können solche wiederverwendbaren Vorberechnungen fälschungssicher (und im Sinne der Wiederverwendbarkeit durch Dritte verteilbar) abgelegt werden? Und wie kann sichergestellt werden, dass die Neuberechnungen so selten wie möglich, aber immer wenn nötig durchgeführt werden?

Dabei ist es unter Umständen nur von Interesse, wie bereits vorhandene Ideen und ihre Lösungen auf 􊨖lgola – ohne Bruch der Prinzipien – übertragen werden können.