Presentati i principi di design del compilatore Nimony per il futuro Nim 3.0

Durante lo sviluppo del linguaggio di programmazione Nim 3.0, è stato creato un nuovo compilatore chiamato Nimony, il cui principio fondamentale di progettazione è raggiungere la prevedibilità del tempo di esecuzione nel caso peggiore (Worst Case Execution Time, WCET). Questa esigenza è dettata dall'orientamento verso sistemi di tempo reale rigoroso, dove un comportamento non deterministico è inaccettabile. Di conseguenza, l'architettura Nimony esclude l'uso di compilatori JIT e raccolte di oggetti con tracciamento (tracing garbage collectors), poiché le loro operazioni possono introdurre ritardi imprevedibili.

Per raggiungere la prevedibilità, 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ù trasparente tra il codice sorgente e il codice macchina generato.

Nel campo della gestione automatica della memoria (MM), Nimony si allontana dalla varietà di opzioni disponibili in Nim 2.0, offrendo una singola modalità standardizzata: «mm:atomicArc». Questo metodo si basa sul conteggio dei riferimenti utilizzando operazioni atomiche, integrato con la semantica del movimento (move semantics) e la chiamata dei distruttori alla distruzione dell'oggetto, avvicinando così l'approccio alle pratiche comuni in Rust e nel moderno C++.

Una delle principali innovazioni è 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, è necessaria un'annotazione esplicita tramite la pragma .cyclic. Si segnala che è in fase di sviluppo un nuovo algoritmo per la raccolta dei riferimenti circolari, ma attualmente non è garantita la sua prontezza per l'uso in produzione. Un vantaggio del MM basato sui distruttori è la sua componibilità: 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.

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ò incapsulare lo stato di errore, si suggerisce di utilizzare una variabile locale al thread (thread-local) per segnalare.

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.

Come alternativa o complemento, viene introdotto un nuovo tipo enumerativo ErrorCode. Questo tipo è type-safe e richiede un'elaborazione esaustiva di tutte le possibili varianti (simile a case per enum). ErrorCode è progettato per poter essere mappato sui codici di errore standard di vari sistemi e protocolli, come POSIX errno, codici di errore Windows API e stati HTTP. L'obiettivo è unificare la gestione degli errori tra diverse librerie e consentire la traslazione diretta degli errori di sistema (ad esempio, "disco pieno") nei corrispondenti codici di stato (ad esempio, HTTP 507) senza ulteriori trasformazioni. L'uso di ErrorCode permette anche di gestire e propagare gli errori senza allocazione di memoria nel heap, il che è cruciale per gestire situazioni di esaurimento della memoria (OOM).

Обработка ситуаций исчерпания памяти (Out of Memory, OOM) в Nimony реализована с отходом от распространенной практики аварийного завершения программы («die on OOM»). Вместо этого предлагается механизм, позволяющий приложению продолжить работу. Контейнеры и операции выделения памяти, которые не могут выполнить запрос, вызывают переопределяемый обработчик oomHandler. Реализация по умолчанию записывает размер неудавшегося запроса в потоко-локальную переменную и позволяет выполнению продолжиться. Состояние нехватки памяти для текущего потока может быть проверено вызовом threadOutOfMem().

Разработчик может предоставить собственную реализацию oomHandler, например, для логирования или аварийного завершения приложения, если такое поведение является предпочтительным. Важным аспектом является обработка операций конструирования ссылочных объектов (ref object), которые могут завершиться неудачей из-за OOM. В Nimony результат таких операций (например, через new или аналогичные конструкторы) может быть nil, и компилятор форсирует обработку этого случая аналогично работе с опциональными типами (Option), предотвращая таким образом ошибки разыменования нулевого указателя. В контексте процедур, аннотированных {.raises.}, возвращаемое значение nil может быть автоматически преобразовано в ErrorCode.OutOfMemError.

Механизм обобщённого программирования (generics) в Nimony получил развитие по сравнению с Nim 2.0. Ключевое улучшение заключается в том, что полная проверка типов обобщённого кода теперь выполняется на этапе его определения, а не только при инстанцировании конкретными типами. Ожидается, что это позволит выявлять ошибки на более ранних стадиях компиляции, предоставлять более информативные сообщения об ошибках и улучшить поддержку со стороны средств разработки (IDE), в частности, автодополнение кода.

Концепции (concepts), уже присутствующие в Nim, сохраняют свою роль как механизм статического описания требований к типам-параметрам обобщённых функций и типов. Они позволяют формально указать, каким операциям или свойствам должен удовлетворять тип для использования в данном обобщённом контексте.

Nimony стремится к унификации моделей асинхронного и многопоточного программирования под единой конструкцией spawn. Решение о том, будет ли задача, запущенная через spawn, выполняться в том же потоке (асинхронно) или в отдельном потоке из пула (многопоточно), принимается планировщиком во время выполнения (runtime). Это накладывает определённые требования на аргументы, передаваемые в spawn: они должны быть потокобезопасными.

Внутренняя реализация модели конкурентности будет основана на продолжениях (continuations), а компилятор будет выполнять преобразование программы в стиль передачи продолжений (Continuation-Passing Style, CPS). Отмечается, что сама конструкция spawn реализована не как встроенная возможность языка, а как плагин компилятора.

Параллелизм рассматривается как более простая задача по сравнению с конкурентностью. Для написания чисто параллельного кода, ориентированного на вычисления (например, обработка массивов данных), Nimony предложит специальные конструкции, такие как параллельные циклы for, обозначаемые оператором «||». Это позволит реализовывать параллельные алгоритмы без необходимости использования переменных потока управления (flow vars), что может быть удобно для задач научных вычислений или программирования для GPU.

Система метапрограммирования Nim, известная своими макросами, в Nimony эволюционирует в сторону плагинов компилятора (compiler plugins). Плагины представляют собой код, который компилируется в нативные инструкции и выполняется на поздних стадиях работы компилятора, после этапа проверки типов. Это даёт плагинам доступ к полной информации о типах и семантике анализируемого кода.

Обещаны улучшенные и более удобные API для разработки плагинов. Использование промежуточного формата NIF (Nim Intermediate Format) также должно упростить реализацию различных трансформаций кода. Плагины могут выполняться инкрементально и параллельно, что способствует повышению производительности компиляции.

Типы плагинов:

• Плагины для шаблонов (Template Plugins): Привязываются к конкретным шаблонам и обрабатывают код, связанный с их вызовами.
• Модульные плагины (Module Plugins): Получают на вход AST (Abstract Syntax Tree) всего модуля и и должны вернуть преобразованное дерево. Конструкция spawn является примером реализации через модульный плагин.
• Плагины для итераторов: Аналогичны плагинам для шаблонов, но применяются к итераторам.
• Plugin per tipi di dati nominali: Possono essere collegati a specifici tipi di dati, sostituendo il meccanismo dei "macro di riscrittura dei termini" (term rewriting macros) di Nim. Questo consente di implementare ottimizzazioni, come l'eliminazione di oggetti temporanei durante l'esecuzione di operazioni matriciali.

Per la documentazione di Nimony è previsto un sito completamente generato dall'IA e verificato dall'autore di Nim per la sua accuratezza.

Fonte: opennet.ru