Durante lo sviluppo del linguaggio di programmazione Nim 3.0, \u00e8 stato creato un nuovo compilatore chiamato Nimony, il cui principio fondamentale di progettazione \u00e8 raggiungere la prevedibilit\u00e0 del tempo di esecuzione nel caso peggiore (Worst Case Execution Time, WCET). Questa esigenza \u00e8 dettata dall'orientamento verso sistemi di tempo reale rigoroso, dove un comportamento non deterministico \u00e8 inaccettabile. Di conseguenza, l'architettura Nimony esclude l'uso di compilatori JIT e raccolte di oggetti con tracciamento (tracing garbage collectors), poich\u00e9 le loro operazioni possono introdurre ritardi imprevedibili. <\/p>\n
Per raggiungere la prevedibilit\u00e0, i tipi di dati primitivi (numeri interi, caratteri) vengono mappati direttamente su parole e byte della macchina corrispondente. I tipi compositi (strutture, oggetti) sono formati senza utilizzare l'indirizzamento indiretto (indirection), posizionandosi direttamente nello stack o all'interno di altre strutture dati. Questo approccio minimizza gli overhead e garantisce una corrispondenza pi\u00f9 trasparente tra il codice sorgente e il codice macchina generato. <\/p>\n
Nel campo della gestione automatica della memoria (MM), Nimony si discosta dalla variet\u00e0 di opzioni disponibili in Nim 2.0, offrendo un'unica modalit\u00e0 standardizzata: «mm:atomicArc». Questa modalit\u00e0 si basa sul conteggio dei riferimenti utilizzando operazioni atomiche, arricchita dalla semantica di spostamento (move semantics) e dalla chiamata ai distruttori al momento della distruzione dell'oggetto, avvicinando l'approccio alle pratiche adottate in Rust e nel C++ moderno. <\/p>\n
Una delle principali innovazioni \u00e8 la separazione esplicita degli oggetti in aciclici e potenzialmente ciclici. Per impostazione predefinita, gli oggetti sono considerati aciclici (.acyclic), il che rappresenta un nuovo comportamento. Per i tipi di dati le cui istanze possono formare riferimenti circolari, \u00e8 necessaria un'annotazione esplicita tramite la pragma .cyclic. Si segnala che \u00e8 in fase di sviluppo un nuovo algoritmo per la raccolta dei riferimenti circolari, ma attualmente non \u00e8 garantita la sua prontezza per l'uso in produzione. Un vantaggio del MM basato sui distruttori \u00e8 la sua componibilit\u00e0: la gestione delle risorse che richiedono liberazione (ad esempio, descrittori di file, socket di rete, canali) viene integrata naturalmente attraverso i distruttori dei tipi corrispondenti. <\/p>\n
L'approccio alla gestione degli errori in Nimony ha subito cambiamenti significativi. L'autore di Nim esprime insoddisfazione per i tradizionali meccanismi di eccezione e la loro simulazione tramite tipi di dati algebrici (sum types). Invece, si propone il concetto di integrazione dello stato di errore direttamente nell'oggetto dati stesso. Esempi includono: la rappresentazione degli errori nei flussi di input-output attraverso uno stato speciale, l'uso di NaN per i numeri in virgola mobile, o low(int) per i valori interi non validi. Nei casi in cui l'oggetto non pu\u00f2 incapsulare lo stato di errore, si suggerisce di utilizzare una variabile locale al thread (thread-local) per segnalare. <\/p>\n
Tuttavia, il tradizionale meccanismo di eccezioni di Nim rimane, ma con un'importante precisazione: ogni procedura capace di generare un'eccezione deve ora essere annotata obbligatoriamente tramite la pragma {.raises.}. Questa richiesta mira a designare esplicitamente potenziali passaggi di controllo non locali. <\/p>\n
Come alternativa o complemento, viene introdotto un nuovo tipo enumerativo ErrorCode. Questo tipo \u00e8 sicuro rispetto ai tipi e richiede un'adeguata gestione di tutte le possibili varianti (simile al case per l'enum). ErrorCode \u00e8 progettato per consentire la mappatura su codici di errore standard di vari sistemi e protocolli, come POSIX errno, codici di errore dell'API di Windows e stati HTTP. L'obiettivo \u00e8 unificare la gestione degli errori tra le diverse librerie e garantire la possibilit\u00e0 di traslare direttamente gli errori di sistema (ad esempio, «disco pieno») nei corrispondenti codici di stato (ad esempio, HTTP 507) senza ulteriori trasformazioni. L'uso di ErrorCode consente anche di gestire e propagare gli errori senza allocare memoria nel heap, il che \u00e8 cruciale per la gestione delle situazioni di esaurimento della memoria (OOM). <\/p>\n
La gestione delle situazioni di esaurimento della memoria (Out of Memory, OOM) in Nimony \u00e8 realizzata allontanandosi dalla pratica comune di terminazione anomala del programma («die on OOM»). Invece, viene proposto un meccanismo che consente all'applicazione di continuare a funzionare. I contenitori e le operazioni di allocazione della memoria, che non possono completare la richiesta, attivano un gestore oomHandler sostituibile. L'implementazione predefinita registra la dimensione della richiesta non riuscita in una variabile locale al thread e consente la continuazione dell'esecuzione. Lo stato di esaurimento della memoria per il thread corrente pu\u00f2 essere verificato chiamando threadOutOfMem(). <\/p>\n
Lo sviluppatore pu\u00f2 fornire la propria implementazione di oomHandler, ad esempio, per il logging o per terminare anormalmente l'applicazione, se tale comportamento \u00e8 preferito. Un aspetto importante \u00e8 la gestione delle operazioni di costruzione di oggetti referenziati (ref object), che possono fallire a causa di OOM. In Nimony, il risultato di tali operazioni (ad esempio, tramite new o costruttori simili) pu\u00f2 essere nil, e il compilatore costringe la gestione di questo caso in modo simile al lavoro con tipi opzionali (Option), prevenendo cos\u00ec errori di dereferenziazione di puntatori nulli. Nel contesto di procedure annotate con {.raises.}, il valore restituito nil pu\u00f2 essere automaticamente convertito in ErrorCode.OutOfMemError. <\/p>\n
Il meccanismo di programmazione generica (generics) in Nimony \u00e8 stato sviluppato rispetto a Nim 2.0. Il miglioramento chiave \u00e8 che il controllo completo dei tipi del codice generico viene ora eseguito al momento della definizione, e non solo all'istanza con tipi specifici. Ci si aspetta che questo permetta di rilevare errori in fasi di compilazione pi\u00f9 precoci, fornendo messaggi di errore pi\u00f9 informativi e migliorando il supporto da parte degli strumenti di sviluppo (IDE), in particolare il completamento automatico del codice. <\/p>\n
I concetti (concepts), gi\u00e0 presenti in Nim, mantengono il loro ruolo come meccanismo di descrizione statica dei requisiti per i parametri di tipo delle funzioni e dei tipi generici. Essi consentono di specificare formalmente quali operazioni o propriet\u00e0 deve soddisfare un tipo per essere utilizzato in un dato contesto generico. <\/p>\n
Nimony mira a unificare i modelli di programmazione asincrona e multithreading sotto un'unica costruzione spawn. La decisione se un compito avviato tramite spawn venga eseguito nello stesso thread (in modo asincrono) o in un thread separato del pool (multithreading) viene presa dallo scheduler durante l'esecuzione (runtime). Questo impone requisiti specifici sugli argomenti passati a spawn: devono essere thread-safe. <\/p>\n
L'implementazione interna del modello di concorrenza si baser\u00e0 sulle continuazioni (continuations) e il compilatore eseguir\u00e0 la trasformazione del programma nello stile di passaggio di continuazioni (Continuation-Passing Style, CPS). Va notato che la costruzione stessa di spawn non \u00e8 implementata come una funzionalit\u00e0 integrata del linguaggio, ma come un plugin del compilatore. <\/p>\n
Il parallelismo \u00e8 considerato un compito pi\u00f9 semplice rispetto alla concorrenza. Per scrivere codice esclusivamente parallelo, orientato al calcolo (ad esempio, nell'elaborazione di array di dati), Nimony offrir\u00e0 costrutti speciali, come i cicli for paralleli, contrassegnati dall'operatore \u00ab||\u00bb. Questo permetter\u00e0 di implementare algoritmi paralleli senza la necessit\u00e0 di utilizzare variabili di flusso di controllo, cosa che pu\u00f2 essere utile per compiti di calcolo scientifico o programmazione per GPU. <\/p>\n
Il sistema di metaprogrammazione di Nim, noto per i suoi macro, in Nimony si evolve verso i plugin per il compilatore (compiler plugins). I plugin rappresentano codice che viene compilato in istruzioni native e viene eseguito nelle fasi avanzate del lavoro del compilatore, dopo la fase di controllo dei tipi. Questo fornisce ai plugin accesso a informazioni complete sui tipi e sulla semantica del codice analizzato. <\/p>\n
Sono promessi API migliorati e pi\u00f9 user-friendly per lo sviluppo di plugin. L'uso di un formato intermedio NIF (Nim Intermediate Format) dovrebbe anche semplificare l'implementazione di varie trasformazioni del codice. I plugin possono essere eseguiti in modo incrementale e parallelo, favorendo un aumento delle performance di compilazione. <\/p>\n
Tipi di plugin: <\/p>\n