Представени са принципите на дизайна на компилятора Nimony за бъдещето Nim 3.0

В процеса на разработка на програмния език Nim 3.0 се развивава нов компилатор Nimony, чийто основен проектен принцип е постигането на предсказуемост на времето за изпълнение в най-лошия случай (Worst Case Execution Time, WCET). Това изискване произтича от ориентацията към системи с жестки реални времеви ограничения, където недетерминираното поведение е неприемливо. В резултат на това архитектурата на Nimony изключва използването на JIT компилатори и сборници на боклук с трасировка, тъй като техните операции могат да въвеждат непредсказуеми забавяния.

За постигане на предсказуемост, примитивните типове данни (цели числа, символи) директно се отразяват на машинни думи и байтове на съответната архитектура. Композитните типове (структури, обекти) се формират без използване на косвена адресация, разполагащи се директно в стека или вътре в други структури данни. Този подход минимизира разходите и осигурява по-прозрачно съответствие между изходния код и генерирания машинен код.

В областта на автоматично управление на паметта (MM), Nimony се отклонява от разнообразието от опции, налични в Nim 2.0, предлагайки единен стандартизиран режим: "mm:atomicArc". Този режим се основава на броене на референции с използване на атомарни операции, допълнени със семантика на преместване (move semantics) и извикване на деструктори при унищожаване на обекта, което сближава подхода с практиките, приети в Rust и съвременен C++.

Ключовото нововъведение е явно разделение на обектите на ациклични и потенциално циклични. По подразбиране обектите се считат за ациклични (.acyclic), което е ново поведение. За типове данни, екземплярите от които могат да формират циклични препратки, е необходима явна анотация с прагма .cyclic. Отбелязва се, че се разработва нов алгоритъм за събиране на циклични препратки, но готовността му за индустриална употреба към момента не е гарантирана. Предимството на MM на базата на деструктори е неговата композируемост: управлението на ресурси, които изискват освобождаване (например, файлови дескриптори, мрежови сокети, канали), се интегрира естествено чрез деструкторите на съответните типове.

Подходът към обработката на грешки в Nimony претърпя значителни промени. Авторът на Nim изразява недоволство от традиционните механизми за изключения и тяхното емулиране чрез алгебрични типове данни (sum types). Вместо това се предлага концепцията за интегриране на състоянието на грешката директно в самия обект с данни. Като примери се дават: представяне на грешки в входно-изходни потоци чрез специално състояние, използването на NaN за числа с плаваща запетая или low(int) за невалидни цели стойности. В случаите, когато обектът не може да инкапсулира състоянието на грешката, се предлага да се използва потоко-локална (thread-local) променлива за сигнализиране.

Все пак, традиционният механизъм за изключения на Nim остава, но с едно важно уточнение: всяка процедура, която може да генерира изключение, сега трябва задължително да бъде анотирана сpragma {.raises.}. Това изискване е насочено към явното обозначаване на потенциални нелокални преходи на управление.

Като алтернатива или допълнение се въвежда нов избираем тип ErrorCode. Този тип е типобезопасен и изисква изчерпателна обработка на всички възможни варианти (аналогично на case за enum). ErrorCode е проектиран с предвидимостта за отразяване на стандартни кодове за грешки на различни системи и протоколи, като POSIX errno, кодове за грешки на Windows API и статуси HTTP. Целта е да се унифицира обработката на грешки между различни библиотеки и да се осигури възможността за пряка транслация на системни грешки (например, "дискът е пълен") в съответстващи кодове на статус (например, HTTP 507) без допълнителни преобразувания. Използването на ErrorCode също позволява обработка и разпространение на грешки без заделяне на памет в купчината, което е критично за обработка на ситуации с недостиг на памет (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, ще се изпълнява в същия поток (асинхронно) или в отделен поток от пул (многопоточно), се взема от планировчика по време на изпълнението. Това поставя определени изисквания за аргументите, предавани на 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 е пример за реализиране чрез модулен плъгин.
• Плъгини за итератори: Подобни са на плъгините за шаблони, но се прилагат към итератори.
• Плъгини за номинални типове: Могат да бъдат свързани с определени типове данни, заменяйки механизма „макроси за преписване на термини“ (term rewriting macros) от Nim. Това позволява реализирането на оптимизации, като премахване на временни обекти при изпълнение на матрични операции.

За документацията на Nimony е предвиден сайт, напълно генериран от ИИ и проверен от автора на Nim за достоверност.

Източник: opennet.ru