`__attribute__(section())`

кто мешает пользоваться метапрограммированием на OCaml + LLVM?
назвал бы Picat как хост-язык, но вроде нет там пока биндинга на LLVM
PS: работы по реализации компилятороной библиотеки там конечно море, но принципиально никто не мешает ни парсить (дельфятные?) исходники, ни писать трансформации для оптимизации

Не понятно, зачем это делать. Какова цель разделения? В системном программировании на Си довольно часто приходится со стеком работать именно как с куском обычной памяти... Речь не о каких-нибудь там while (*p++) { ... }, а именно о том, что нам нужно взять какую-нибудь задачу и повешать указатель на её стек в какой-нибудь динамический список, который лежит в куче у другой задачи. Ну и всякие тому подобные сценарии. То есть, в системном программировании у нас есть состояние задачи: задача не исполняется. И в этом состоянии с её стеком можно делать всякое разное.

Тем, собственно, Си и хорош для таких системных дел.

цель разделения - уберечься от получения висячего указателя при возврате из функции, когда очищается её стек. Если очень надо, будет возможность кастовать к нужному указателю

Уже придумали более общее решение - лайфтаймы

Практика показывает, что частные, "инженерные" решения проблем в языках приводят к боли и кастрированным решениям (отсутствие функторов, монад во многих языках, как пример, вместо них частные случаи - async/.await, LINQ, etc)

а перечисленное действительно нужно в системном языке? Вот возможность написать загрузчик ядра ОС, не прибегая к ассемблеру - вот это интересно было бы

Можно посмотреть на Either, Option, Iterator, Result (и старую версию Future до кучи). Что видим? Десятки методов скопипастчены, причём некоторых пришлось и приходится ждать, другие разбросаны по отдельным крейтам, а если хотеть своё подобие монады (функтора, аппликатива, etc) - копипастить и тестировать уже самому. С монадами бы многие методы достались за бесплатно после реализации четырёх-пяти.

Нужны ли системному языку монады? Если брать пример с Rust - то да, нужны, но изначально я хотел показать на примере монад, что частных решений проблем лучше избегать, если есть более общее.

по отзывам Rust как системный язык что-то не заходит, там по-прежнему пишут на Си

Потому что Расту лет пять от роду, а Си сорокет с хвостом?

HKT в Rust не завезли по каким-то веским причинам, а не потому что разработчики языка были против и счастливы копипастить код. Насколько я помню, что-то связанное с мономорфизацией.

У Нико была серия постов про HKT и все его подводные камни в rust

Мономорфизация хкт не мешает.

Вон, в хаскеле можно specialize повесить на код с хкт, спокойно сделает версию под нужный тип

Это не подтверждает что это нужно в системных языках. Это подтверждает что ФП подход хорош. Но делать их системного языка фпшный не стоит.

Что из вышеперечисленного не нужно в системном языке?  Option, Either или Future?
При условии что все реализованы эффективно.
Вместо  Option/Either лучше error код ручками везде прокидывать как в Go?)

Есть некая философская проблема. Системный язык нужен, чтобы писать не функции, а процессы, которые интерпретируют эти самые монады. Интерпретатор монады на монадах не написать. Нужна какая-то базовая вещь, типа IO. Но IO на чём-то надо кодить, и это что-то должно иметь семантику процессов (pi-исчисления, то есть).

Как-то так. Тут была недавно об этом презентация.

Почему нужна базовая вещь IO? Монады ведь ещё не означают, что мы хотим делать язык чистым

Надо уточнить, что подразумевается в таком случае под наличием монад?

Тайп-классы Functor, Applicative, Monad, и пучок отдельных функций над монадами?