Im Rahmen der Entwicklung der Programmiersprache Nim 3.0 entsteht der neue Compiler Nimony, dessen grundlegendes Entwurfsprinzip die Vorhersehbarkeit der Laufzeit im schlimmsten Fall (Worst Case Execution Time, WCET) ist. Diese Anforderung ergibt sich aus dem Fokus auf Systeme mit harter Echtzeit, bei denen undeterministisches Verhalten nicht akzeptabel ist. Infolgedessen schlie\u00dft die Architektur von Nimony den Einsatz von JIT-Compilern und tracing garbage collectors aus, da deren Aktionen unvorhersehbare Verz\u00f6gerungen verursachen k\u00f6nnen. <\/p>\n
Um Vorhersehbarkeit zu erreichen, werden primitive Datentypen (Ganzzahlen, Zeichen) direkt auf Maschinenw\u00f6rter und Bytes der entsprechenden Architektur abgebildet. Zusammengesetzte Typen (Strukturen, Objekte) werden ohne den Einsatz von indirekter Adressierung (Indirection) gebildet und befinden sich direkt im Stack oder innerhalb anderer Datenstrukturen. Dieser Ansatz minimiert den Overhead und gew\u00e4hrleistet eine transparentere \u00dcbereinstimmung zwischen dem Quellcode und dem generierten Maschinencode. <\/p>\n
Im Bereich des automatischen Speicher-Managements (MM) weicht Nimony von der Vielzahl an Optionen ab, die in Nim 2.0 verf\u00fcgbar sind, und bietet einen einzigen standardisierten Modus: \"mm:atomicArc\". Dieser Modus basiert auf der Referenzz\u00e4hlung unter Verwendung atomarer Operationen, erg\u00e4nzt durch die Semantik von Verschiebungen (move semantics) und dem Aufruf von Destruktoren beim Zerst\u00f6ren von Objekten, was den Ansatz mit den Praktiken, die in Rust und modernem C++ verwendet werden, n\u00e4herbringt. <\/p>\n
Eine der wichtigsten Neuerungen ist die klare Trennung von Objekten in azyklische und potenziell zyklische. Standardm\u00e4\u00dfig werden Objekte als azyklisch (.acyclic) betrachtet, was ein neues Verhalten darstellt. F\u00fcr Datentypen, deren Instanzen zyklische Verweise bilden k\u00f6nnen, ist eine explizite Anmerkung mit der Pragmanotwendigkeit .cyclic erforderlich. Es wird angemerkt, dass ein neuer Algorithmus zur Verwaltung von zyklischen Verweisen entwickelt wird, jedoch ist seine Verwendbarkeit in der Industrie derzeit nicht garantiert. Ein Vorteil von MM, das auf Destruktoren basiert, ist seine Komponierbarkeit: Das Management von Ressourcen, die freigegeben werden m\u00fcssen (zum Beispiel Dateideskriptoren, Netzwerksockets, Kan\u00e4le), wird nahtlos durch die Destruktoren der entsprechenden Typen integriert. <\/p>\n
Der Umgang mit Fehlerbehandlungen in Nimony hat sich erheblich ver\u00e4ndert. Der Autor Nim zeigt sich unzufrieden mit traditionellen Ausnahmebehandlungsmechanismen und deren Emulation durch algebraische Datentypen (Summentypen). Stattdessen wird das Konzept vorgeschlagen, den Fehlerstatus direkt im Datenelement zu integrieren. Beispiele hierf\u00fcr sind: die Darstellung von Fehlern in Ein- und Ausgabestr\u00f6men durch einen speziellen Status, die Verwendung von NaN f\u00fcr Gleitkommazahlen oder low(int) f\u00fcr ung\u00fcltige Ganzzahlwerte. In F\u00e4llen, in denen ein Objekt den Fehlerstatus nicht kapseln kann, wird vorgeschlagen, eine thread-lokale Variable zur Signalisierung zu verwenden. <\/p>\n
Dennoch bleibt der traditionelle Ausnahmebehandlungsmechanismus von Nim erhalten, jedoch mit einer wichtigen Klarstellung: Jede Prozedur, die eine Ausnahme ausl\u00f6sen kann, muss nun zwingend mit der Pragmas {.raises.} annotiert werden. Diese Anforderung zielt darauf ab, potenzielle nicht-lokale Kontroll\u00fcberg\u00e4nge eindeutig zu kennzeichnen. <\/p>\n
Alternativ oder erg\u00e4nzend wird ein neuer enumerierter Typ ErrorCode eingef\u00fchrt. Dieser Typ ist typensicher und erfordert eine vollst\u00e4ndige Behandlung aller m\u00f6glichen Varianten (\u00e4hnlich wie bei case f\u00fcr enums). ErrorCode ist so gestaltet, dass er auf Standardfehlercodes verschiedener Systeme und Protokolle, wie z.B. POSIX errno, Windows API-Fehlercodes und HTTP-Statuscodes, abgebildet werden kann. Ziel ist es, die Fehlerbehandlung zwischen verschiedenen Bibliotheken zu vereinheitlichen und die direkte \u00dcbersetzung von Systemfehlern (z.B. \"Festplatte voll\") in die entsprechenden Statuscodes (z.B. HTTP 507) ohne zus\u00e4tzliche Umwandlungen zu erm\u00f6glichen. Die Verwendung von ErrorCode erm\u00f6glicht es zudem, Fehler zu verarbeiten und weiterzugeben, ohne Speicher im Heap zuzuweisen, was entscheidend f\u00fcr die Handhabung von Speicherengpass-Situationen (OOM) ist. <\/p>\n
Die Behandlung von Speicherermangel-Situationen (Out of Memory, OOM) in Nimony erfolgt unter Verzicht auf die g\u00e4ngige Praxis des notfallm\u00e4\u00dfigen Programmabbruchs (\"die on OOM\"). Stattdessen wird ein Mechanismus angeboten, der es der Anwendung erm\u00f6glicht, weiterzulaufen. Container und Speicherzuweisungsoperationen, die eine Anfrage nicht erf\u00fcllen k\u00f6nnen, rufen einen \u00fcberschreibbaren Handler oomHandler auf. Die Standardimplementierung speichert die Gr\u00f6\u00dfe der gescheiterten Anfrage in einer thread-lokalen Variablen und l\u00e4sst die Ausf\u00fchrung fortfahren. Der Speicherengpasszustand f\u00fcr den aktuellen Thread kann mit dem Aufruf von threadOutOfMem() \u00fcberpr\u00fcft werden. <\/p>\n
Der Entwickler kann eine eigene Implementierung von oomHandler bereitstellen, beispielsweise f\u00fcr die Protokollierung oder das Notabschalten der Anwendung, falls ein solches Verhalten gew\u00fcnscht ist. Ein wichtiger Aspekt ist die Handhabung der Konstruktion von Referenzobjekten (ref object), die aufgrund von OOM fehlschlagen kann. In Nimony kann das Ergebnis solcher Operationen (zum Beispiel \u00fcber new oder \u00e4hnliche Konstruktoren) nil sein, und der Compiler erzwingt die Verarbeitung dieses Falls \u00e4hnlich wie bei optionalen Typen (Option), um so Nullzeiger-Dereferenzierungsfehler zu vermeiden. Im Kontext von Verfahren, die mit {.raises.} annotiert sind, kann der R\u00fcckgabewert nil automatisch in ErrorCode.OutOfMemError umgewandelt werden. <\/p>\n
Der Mechanismus der generischen Programmierung in Nimony hat im Vergleich zu Nim 2.0 Fortschritte gemacht. Die wesentliche Verbesserung besteht darin, dass die vollst\u00e4ndige Typpr\u00fcfung von generischem Code jetzt bereits beim Definitionstage erfolgt, anstatt nur beim Instanziieren mit konkreten Typen. Dies soll dazu beitragen, Fehler fr\u00fcher im Kompilierungsprozess zu erkennen, informativere Fehlermeldungen bereitzustellen und die Unterst\u00fctzung durch Entwicklungsumgebungen (IDEs) zu verbessern, insbesondere die Code-Autovervollst\u00e4ndigung. <\/p>\n
Die Konzepte, die bereits in Nim vorhanden sind, behalten ihre Rolle als Mechanismus zur statischen Beschreibung der Anforderungen an Typparameter in generischen Funktionen und Typen. Sie erm\u00f6glichen es, formell anzugeben, welche Operationen oder Eigenschaften ein Typ erf\u00fcllen muss, um in diesem generischen Kontext verwendet werden zu k\u00f6nnen. <\/p>\n
Nimony verfolgt die Vereinheitlichung von asynchroner und multithreaded Programmierung unter der einheitlichen Struktur von spawn. Die Entscheidung, ob eine durch spawn gestartete Aufgabe im gleichen Thread (asynchron) oder in einem separaten Thread aus dem Pool (multithreaded) ausgef\u00fchrt wird, trifft der Scheduler zur Laufzeit. Dies stellt bestimmte Anforderungen an die Argumente, die an spawn \u00fcbergeben werden: Sie m\u00fcssen threadsicher sein. <\/p>\n
Die interne Implementierung des Wettbewerbsmodells basiert auf Fortsetzungen (Continuations), und der Compiler wird das Programm in den Fortsetzungs\u00fcbergabestil (Continuation-Passing Style, CPS) umwandeln. Es wird angemerkt, dass die Konstruktion spawn nicht als integrierte F\u00e4higkeit der Sprache, sondern als Compiler-Plugin realisiert ist. <\/p>\n
Parallelismus wird als einfachere Aufgabe im Vergleich zur Konkurrenz betrachtet. F\u00fcr das Schreiben von rein parallelem Code, der auf Berechnungen ausgerichtet ist (z.B. Verarbeitung von Datenarrays), wird Nimony spezielle Konstrukte anbieten, wie parallele for-Schleifen, die durch den Operator \"||\" gekennzeichnet sind. Dies erm\u00f6glicht die Umsetzung paralleler Algorithmen, ohne dass Steuerflussvariablen (flow vars) verwendet werden m\u00fcssen, was f\u00fcr wissenschaftliche Berechnungen oder Programmierungen f\u00fcr GPUs von Vorteil sein kann. <\/p>\n
Das Metaprogrammierungssystem von Nim, das f\u00fcr seine Makros bekannt ist, entwickelt sich in Nimony zu Compiler-Plugins. Plugins sind Code, der in native Anweisungen kompiliert wird und in einer sp\u00e4ten Phase des Compilervorgangs, nach der Typ\u00fcberpr\u00fcfung, ausgef\u00fchrt wird. Dies gibt den Plugins Zugang zu vollst\u00e4ndigen Informationen \u00fcber die Typen und die Semantik des analysierten Codes. <\/p>\n
Es wurden verbesserte und benutzerfreundlichere APIs zur Entwicklung von Plugins versprochen. Die Verwendung des Zwischenformats NIF (Nim Intermediate Format) sollte zudem die Implementierung verschiedener Code-Transformationen erleichtern. Plugins k\u00f6nnen inkrementell und parallel ausgef\u00fchrt werden, was die Kompilierungsleistung steigert. <\/p>\n
Plugin-Typen: <\/p>\n