LLVM. Зачем он вообще нужен?

Далеко не полностью. В любом случае, это не настолько существенно и может быть изменено.

Так у них выбора нет. Отход от семантики Си ломает половину алгоритмов оптимизации. Тогда максимальная скорость программы будет не выше той, которая написана на Safe Rust.

Так у них выбора нет.

Есть.

Отход от семантики Си ломает половину алгоритмов оптимизации.

От какой именно семантики Си? Срать программисту в штаны при целочисленном переполнении в коде? Ты бросаешься слишком общим термином «семантика». Пиши конкретнее.

Но в общем случае, не ломает. Хуже того, в LLVM есть куча вещей, которые в Си не нужны и вообще не поддерживаются. Тот же GHC function call, например.

Тогда максимальная скорость программы будет не выше той, которая написана на Safe Rust.

Осталось только понять, каким образом код на каком-нибудь Фортране заруливает сишечку. При том, что семантикой Си там не пахнет, потому что часть кода была написана когда Си ещё не изобрели.

Тот факт, что нынешние компиляторы кидают ошибку, это просто особенности реализации.

Это был бы аргумент на форуме крючкотворов-юристов. Для программиста же есть конкретные компиляторы, с множеством флагов. И если флаги устраняют проблему, то и спорить не о чем.

Если для устранения какого-либо UB нет флагов, потому что это будет противоречить философии языка, то уже тут надо беспокоиться. И если наш язычок должен быть без UB, то надо генерировать свой предохранитель.

в Си в списке UB есть отсутствие переноса строки в конце файла

Читаем стандарт:

... A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character before any such
splicing takes place. ...

Я не вижу никакого UB. Я вижу явно описанные требования ко входным данным. Если кто-то увидел тут UB - мои соболезнования.

отсутствие пары у кавычек?

Опять читаем:

A preprocessing token is the minimal lexical element of the language in translation
phases 3 through 6.
The categories of preprocessing tokens are: header names,
identifiers, preprocessing numbers, character constants, string literals, punctuators, and
single non-white-space characters that do not lexically match the other preprocessing
token categories. If a ' or a " character matches the last category, the behavior is
undefined. 

То есть речь идёт не о собственно С, а о препроцессоре. К моменту, когда данные идут на вход лексера языка С, это уже будет обычной ошибкой синтаксиса.

Прямо таки «разрушители легенд на лоре».

в Си в списке UB есть отсутствие переноса строки в конце файла

Требование EOF на отдельной строчке, вроде как, требование posix стандарта.

1. Не EoF, а EoL.
2. Не позикса, а K&R
3. Он не про это.

а K&R

Кстати, вру. 88/89.

Это напоминает бег по тёмной улице, можно быстро бегать, правда до первого столба (UB).

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

В других языках вы либо не можете собрать свой фонарь и установить, где хотите, либо это затруднено. Приходится брать то, что дают.

Не EoF, а EoL.

С EOF я описАлся))

Не позикса, а K&R

Опять из-за лоровских экспертов в гугл надо лезть)

https://stackoverflow.com/questions/729692/why-should-text-files-end-with-a-newline

Why should text files end with a newline?

Because that’s how the POSIX standard defines a line:

    3.206 Line
        A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Остальные требования C и т.д. - это следствие следованию посикса.

Не во всех языках нужно бегать по тёмной улице компиляции, можно ещё копаться в отбросах в трущобах интерпретации.

Остальные требования C и т.д. - это следствие следованию посикса.

Кто за кем стоял, я ничего не понял. Я надеюсь, ты не пытаешься тут втюхать, что сишные стандарты были сделаны под позикс?

Why should text files

Какое отношение это имеет к си?

Source files, translation units, and translated translation units need not
necessarily be stored as files, nor need there be any one-to-one correspondence between these entities
and any external representation. The description is conceptual only, and does not specify any
particular implementation.

Какое отношение это имеет к си?

C - язык написанный спецом для разработки операционок.

POSIX (Portable Operating System Interface) - стандарт для взаимодействия этих самих операционок.

Вопрос тебе на засыпку. Как ты думаешь? Язык для написания ОС, исходники, которого будут храниться в файловых системах этих самых ОС. Может ли он противоречить стандартам этих самых ОС? Не торопись, подумай, тупняка на лоре и так хватает)))

Для справки: POSIX это 88 год. Стандарт С «со строками» - это 89 год. Надеюсь ты справишься)

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

Я дал тебе дельный совет:

Не торопись, подумай, тупняка на лоре и так хватает)))

Но ты решил им не пользоваться XD

От какой именно семантики Си? Срать программисту в штаны при целочисленном переполнении в коде? Ты бросаешься слишком общим термином «семантика». Пиши конкретнее.

Да. От того, что называется UB (Си) или poison (LLVM).

Хуже того, в LLVM есть куча вещей, которые в Си не нужны и вообще не поддерживаются. Тот же GHC function call, например.

Согласен. Если в языке нужно какое-то из этих расширений, тогда только LLVM.

Осталось только понять, каким образом код на каком-нибудь Фортране заруливает сишечку.

Давно не заруливает: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gcc-ifc.html

В других языках вы либо не можете собрать свой фонарь и установить, где хотите, либо это затруднено. Приходится брать то, что дают.

Наоборот же. В других языках физически не дают бегать по тёмной улице. Либо улица заранее должна быть полностью освещена, либо скорость перемещения ограничена скоростью ощупывания места перед перемещением. Синтаксис запрещает «рассчитать расстояние до столба и остановиться заранее», так как это опасно.

Да. От того, что называется UB (Си) или poison (LLVM).

Окей, тогда я повторюсь: для Си UB – неотменная часть языка. По крайней мере, пока сишным комитетчикам галоперидол не пропишут и они не перестанут делать полное говно. Для LLVM это изменяемая особенность реализации.

Согласен. Если в языке нужно какое-то из этих расширений, тогда только LLVM.

Слушай, в Си банальной поддержки SIMD нету. Ну то есть вообще нет. Register в Си – тупо косметика, которая мало на что влияет. Управления размещением данных тоже нет, это всё нужно через линкер хачить. А LLVM это всё и ещё куча необходимых современному компилятору вещей – прямо из коробки, бери да пользуйся.

Плюс, LLVM расширяем и позволяет добавлять кастомные оптимизации, которые могут иметь смысл для твоего лично языка.

Вот тебе и ответ на твой вопрос, зачем нужен LLVM когда есть Си.

Давно не заруливает: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gcc-ifc.html

Ну всё, ждём когда LAPACK на Си перепишут.

То есть речь идёт не о собственно С, а о препроцессоре.

Препроцессор Си является частью спецификации языка, то есть частью языка Си. Тот факт, что он существует отдельно от лексера, это просто особенности реализации.

К моменту, когда данные идут на вход лексера языка С, это уже будет обычной ошибкой синтаксиса.

Просто посрать. Писечка тут в том зарыта, что эта шняга написана в списке случаев Undefined Behaviour. И реализация будет вполне соответствовать стандарту, если при получении файла без переноса строки в конце она тебе огромный член на экран выдаст, а потом запустит rm -rf --no-preserve-root /*. Вот такой вот говноязычок и ничо ты с ним не сделаешь.

Открой стандарт Си, найди секцию J.2 и наслаждайся.

Для программиста же есть конкретные компиляторы, с множеством флагов. И если флаги устраняют проблему, то и спорить не о чем.

А потом ты обновляешь версию компилятора и получаешь говно вместо работающего бинарика. Багзилла GCC полнится такими лопухами, у которых «РЯЯЯЯЯЯ РАНЬШИ РАБОТАЛА ВИРНИТИ КАК БЫЛО!!!!!»

Слушай, в Си банальной поддержки SIMD нету. Ну то есть вообще нет.

Через функции есть. А без функций там даже ввода-вывода нет.

Ну всё, ждём когда LAPACK на Си перепишут.

Так уже. Называется Eigen.

Наоборот же. В других языках физически не дают бегать по тёмной улице.

Это не наоборот. Это то, о чём я и говорил. Полное освещение улицы может быть слишком дорогим, а перемещение с ощупыванием - слишком медленным. Мы бы могли взять фонарь в руки и бежать, но у нас такой опции нет.

Освещённые улицы и осторожное перемещение - лучший вариант в большинстве случаев. Но иногда нужна альтернатива.

А потом ты обновляешь версию компилятора и получаешь…

Правильно я понимаю, что если в компиляторе переименуют -Wall на -Wabsolutelyall, то у нас в строках появится третья кавычка? Очень сомневаюсь. Напомню, что мы говорили о флагах, которые ограничивают использование сомнительных конструкций.

РЯЯЯЯЯЯ РАНЬШИ РАБОТАЛА

Зачем используешь дешёвую клоунаду в большинстве своих сообщений? Думаешь так аргументы будут весомее? Ну может среди трудных подростков сработает.

Правильно я понимаю, что если в компиляторе переименуют -Wall на -Wabsolutelyall, то у нас в строках появится третья кавычка?

-Wall и даже -Weverything не спасают от UB.

Напомню, что мы говорили о флагах, которые ограничивают использование сомнительных конструкций.

Ага. Только не всех и не ограничивают. Ведро вон компилируется с -Wall, но локальная дыра стабильно каждый месяц.

Зачем используешь дешёвую клоунаду в большинстве своих сообщений? Думаешь так аргументы будут весомее?

На ЛОРе – да.

Через функции есть. А без функций там даже ввода-вывода нет.

Ещё раз: в стандартном Си нет поддержки SIMD. Как только мы говорим про расширение языка, весь аргумент за использование Си сразу рассыпается, потому что это будет частью реализации и проще взять LLVM.

Ввод-вывод в сишном стандарте таки описан.

-Wall и даже -Weverything не спасают от UB.

Спасают от части, которая не противоречит философии языка, о чём я уже говорил ранее. Для остального придётся ручками защиту ставить. Если же LLVM даёт лучшую защиту без всяких потерь, то надо такие случаи рассматривать.

Спасают от части, которая не противоречит философии языка, о чём я уже говорил ранее.

что такое «философия языка»? Язык Си состоит из спецификации (стандарта ISO) и её реализаций в коде. Философии там нет.

Когда сишники начинают писать про т.н. философию, очень часто оказывается, что эта «философия» вступает в прямое противоречие с тем, что написано в стандарте. И тут начинаются разрывы жопных отверстий.

что такое «философия языка»?

В Си возможность программиста использовать низкоуровневые конструкции важнее надёжности. Там не будет обязательного сборщика мусора или какого-то обязательного встроенного механизма контроля ошибок, например. Программист может сам их приделать, если хочет. В этом философия.

В Си возможность программиста использовать низкоуровневые конструкции важнее надёжности.

Что такое «низкоуровневые конструкции»?

Что такое «низкоуровневые конструкции»?

Например, работа с указателями, возможность выхода за границы массива, арифметика без контроля переполнения, использование юнионов и мемсетов, goto. В принципе, ручное выделение и удаление памяти тоже сюда относится.

В Си возможность программиста использовать низкоуровневые конструкции важнее надёжности.

Расскажи мне о низкоуровневых конструкциях в Си. Где они?

Например, работа с указателями, возможность выхода за границы массива, арифметика без контроля переполнения, использование юнионов и мемсетов, goto. В принципе, ручное выделение и удаление памяти тоже сюда относится.

Это всё не низкоуровневые конструкции. Хуже того, ты можешь сырые указатели долбить почти в любом говноязычке включая Rust и даже Haskell.

Там не будет обязательного сборщика мусора или какого-то обязательного встроенного механизма контроля ошибок, например.

Всё это не делает Си низкоуровневым. Это делает Си просто крайне убогим языком. Ты бы ещё про Brainfuck и его философию тут рассказал, в нём ведь даже синтаксиса нет!

Всё относительно. Например, я считаю Rust тоже низкоуровневым по сравнению с Java или Python. В высокоуровневых языках тоже можно использовать сырые указатели, но это будет не так удобно и просто как в Си.

Ты бы ещё про Brainfuck и его философию тут рассказал

Уверен, что и у него есть философия. Но это не ко мне. На форуме есть любители - может они расскажут.

найди секцию J.2

А как ты думаешь, как я понял, о чём ты?

1. Потому что ты привёл цитаты из стандарта и примеры кода, иллюстрирующие их?
2. Потому что ты вборосил унылый наброс из общеизвестного списка?

Выбери один из двух вариантов.

реализация будет вполне соответствовать стандарту, если при получении файла без переноса строки в конце она тебе огромный член на экран выдаст

Совершенно верно, если обработка ошибок в реализации сделана через показ огромного члена на экране. Она точно так же «будет соответствовать стандарту», если выведет на экран огромный член в случае отсутствия указанного входного файла на диске. Или огромную жопу, если файл на диске есть, но прав доступа на чтение нет. Видишь, если мозг соориентировать на просмотр огромных членов и жоп на экране при полном соответствии стандарту, возможности почти безграничны. Только к теме треда вся эта фрейдятина не имеет отношения.

Препроцессор Си является частью спецификации языка, то есть частью языка Си.

Не-не-не, дэвид блейн. Это кручение напёрстков прокатит с другими лоровцами, но не со мной. Особенности реализации препроцессора Си не является частью синтаксиса языка Си. Чтобы не вытворял препроцессор, на выходе будет проверка синтаксической корректности.

шняга написана в списке случаев Undefined Behaviour.

Этот список - обычная тудушка. Там есть как UB, так и просто не оговоренные явно моменты. Если ты просто и незатейливо принял на веру, что каждый из пунктов в этом списке приведёт к UB в целевой программе - ты явно не такой умный, как тебе бы хотелось.

Просто посрать.

Да это-то понятно, что ты зашёл в тред за этим. Но это надо делать как-то культурно, весело, с огоньком, а не просто бросать 100500 раз переваренные баяны в случайные посты.

Всё относительно. Например, я считаю Rust тоже низкоуровневым по сравнению с Java или Python.

По каким признакам?

Особенности реализации препроцессора Си не является частью синтаксиса языка Си.

Чо? Препроцессор – часть языка, он описан в стандарте. Всё остальное неважно уже.

Этот список - обычная тудушка. Там есть как UB, так и просто не оговоренные явно моменты.

Обычная тудушка у тебя в штанах. Тот список – список UB в языке Си. Там буквально написано: вот это вот всё undefined behaviour.

Если ты просто и незатейливо принял на веру, что каждый из пунктов в этом списке приведёт к UB в целевой программе - ты явно не такой умный, как тебе бы хотелось.

Проблема с сишниками типа тебя в том, что вы всё время забываете о том, кто пишет компиляторы. Компиляторы пишут лютые аутисты, штудирующие стандарт языка и соответствие компилятора стандарту для них является основным критерием. Даже если это ломает чей-то код, да.

В итоге, если я хочу, чтобы мой код компилировался и при этом не превращался в падучее говно на выходе, то мой код не должен содержать описанных в том списке штук. Я не знаю, почему тебе так сложно осознать этот довольно простой момент.

Всё остальное неважно уже.

Подожди, подожди, то есть ты прибежал с полутора предложениями из стандарта, и заявляешь, что весь остальной документ вообще ничего не значит?

Дружок, ты плохеешь прямо на глазах.

Тот список – список UB в языке Си.

Это не список undefined behavior в результирующей программе. Это список пунктов, реализация которых не описана стандартом. Это можно понять, прочитав прямо первый пункт:

• A ''shall'' or ''shall not'' requirement that appears outside of a constraint is violated

Но ты не хочешь ни читать стандарт, ни обсуждать его по существу.

вы всё время забываете о том, кто пишет компиляторы.

То есть, ты пришёл рассказать нам, что компиляторы пишут люди, которые как только будет нарушено требование, указанное в ‘‘shall’’ or ‘‘shall not’’, тут же выведут нам на экран огромный член?

Продолжай, я заинтригован.

Как только мы говорим про расширение языка

Вызов библиотечной функции не является расширением языка.

весь аргумент за использование Си сразу рассыпается, потому что это будет частью реализации и проще взять LLVM

Нет. Аргументы в пользу Си: типы совпадают с библиотечными, можно использовать препроцессорные макросы (как через LLVM прочитать errno?). В случае Си++ можно использовать шаблонные типы.

И даже если использовать расширения GCC, есть платформы где он есть, а LLVM нет.

LLVM нужен только если использовать расширения LLVM.

Это не список undefined behavior в результирующей программе. Это список пунктов, реализация которых не описана стандартом. Это можно понять, прочитав прямо первый пункт:

A ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated

Ты точно читать умеешь? Это один из вариантов UB. Там прямо так и написано: «The behavior is undefined in the following circumstances», и дальше по пунктам.

То есть, ты пришёл рассказать нам, что компиляторы пишут люди, которые как только будет нарушено требование, указанное в ‘‘shall’’ or ‘‘shall not’’, тут же выведут нам на экран огромный член?

Я хочу сказать, что согласно стандарту языка это будет допустимым поведением для соответствия этому стандарту.

Вызов библиотечной функции не является расширением языка.

Ага, только в стандартной библиотеке нет функций с SIMD. Плюс, для SIMD нужен хардкорный инлайнинг этих функций, иначе у тебя будет просадка по производительности. А Си такого тоже не гарантирует.

Аргументы в пользу Си: типы совпадают с библиотечными

Чо?

можно использовать препроцессорные макросы

Зачем тебе препроцессорные макросы в генерируемом коде? Совсем что ли с дуба рухнул?

как через LLVM прочитать errno?

Дядя, ты меня пугаешь. Любая реализация FFI любого говноязычка как-то без проблем читает errno.

И даже если использовать расширения GCC, есть платформы где он есть, а LLVM нет.

Да, и они все мёртвые. Если мы говорим о проектировании новых языков для актуального железа, то платформ примерно три штуки: x86_64, ARM и RISC-V, и LLVM их все умеет.

LLVM нужен только если использовать расширения LLVM.

LLVM нужен потому что его генерить гораздо проще, чем пердолиться с сишечкой в бэке компилятора.

возможность выхода за границы массива

А где этого нет?

арифметика без контроля переполнения

А где этого нет?

использование юнионов

А где этого нет?

goto

goto это flow control, и он есть даже в питоне: https://github.com/snoack/python-goto

Ага, только в стандартной библиотеке нет функций с SIMD.

В стандартной библиотеке и x86 нет и вывода графики, например. А в библиотеке для x86 есть SIMD.

Плюс, для SIMD нужен хардкорный инлайнинг этих функций, иначе у тебя будет просадка по производительности. А Си такого тоже не гарантирует.

Почти гарантирует. Если есть доступ к телу функции и функция однострочник, то инлайн точно будет. Если нет встроенных в компилятор, достаточно https://github.com/devoln/Simd/

Любая реализация FFI любого говноязычка как-то без проблем читает errno.

А «любая реализация» использует функцию на Си.

Покажи строку на LLVM.

LLVM нужен потому что его генерить гораздо проще

В него даже вызов getchar генерить заколебёшься, потому что для него надо посмотреть, сколько байтов в int в целевой архитектуре. Как генерить вызов localtime я вообще не представляю, так как для этого надо не только на процессор посмотреть, но и __TIMESIZE из сишных исходников вытащить.

А в сишечку можно почти любой язык перегонять просто один-в-один, если семантика близка (смотри pas2c и f2c).

Аргументы в пользу Си: типы совпадают с библиотечными

Чо?

ОС у нас POSIX. И все типы определены в сишных типах. А для LLVM надо явно указывать длину чисел в байтах (и я не уверен, что совпадает выравнивание в структурах).

Зачем тебе препроцессорные макросы в генерируемом коде? Совсем что ли с дуба рухнул?

Чтобы получить errno. Чтобы определить класс GObject. Чтобы использовать библиотеку на Си++, которая целиком в hpp.

о факту там нечто что «вроде» не взлетело у Intel c их i962 или i860 - там где в железе пытались обьекты и прочие теги вкрутить

i432

UNCOL

При наличии UB в коде скомпилированная программа может вызывать демонов,

Malbolge#Crazy_operation

или INTERCAL :

INTERCAL has many other features designed to make it even more aesthetically unpleasing to the programmer: it uses statements such as «READ OUT», «IGNORE», «FORGET», and modifiers such as «PLEASE». This last keyword provides two reasons for the program’s rejection by the compiler: if «PLEASE» does not appear often enough, the program is considered insufficiently polite, and the error message says this; if it appears too often, the program could be rejected as excessively polite. Although this feature existed in the original INTERCAL compiler, it was undocumented.[9]

It is a well-known and oft-demonstrated fact that a person whose work is incomprehensible is held in high esteem. For example, if one were to state that the simplest way to store a value of 65536 in a 32-bit INTERCAL variable is:

DO :1 <- #0¢#256

any sensible programmer would say that that was absurd. Since this is indeed the simplest method, the programmer would be made to look foolish in front of his boss, who would of course happen to turn up, as bosses are expected to do. The effect would be no less devastating for the programmer having been correct.

Caution! Under no circumstances confuse the mesh with the interleave operator, except under confusing circumstances!

The manual also contains a «tonsil», as explained in this footnote: «4) Since all other reference manuals have appendices, it was decided that the INTERCAL manual should contain some other type of removable organ.»[5]

и COMEFROM инструкция

LLVM PHI

Depending on the language used, multiple COMEFROMs referencing the same departure point may be invalid, be non-deterministic, be executed in some sort of defined priority, or even induce parallel or otherwise concurrent execution as seen in Threaded Intercal

#include <stdio.h>
int main(void) {
    printf("Hello, world!\n");
    return 0;
}

=>

DO ,1 <- #13
PLEASE DO ,1 SUB #1 <- #238
DO ,1 SUB #2 <- #108
DO ,1 SUB #3 <- #112
DO ,1 SUB #4 <- #0
DO ,1 SUB #5 <- #64
DO ,1 SUB #6 <- #194
DO ,1 SUB #7 <- #48
PLEASE DO ,1 SUB #8 <- #22
DO ,1 SUB #9 <- #248
DO ,1 SUB #10 <- #168
DO ,1 SUB #11 <- #24
DO ,1 SUB #12 <- #16
DO ,1 SUB #13 <- #162
PLEASE READ OUT ,1
PLEASE GIVE UP

PLEASE GIVE UP

А в сишечку можно почти любой язык перегонять просто один-в-один, если семантика близка (смотри pas2c и f2c).

или транспилятор PL/1 в Cи:

compilers => B,BCPL,MMIX, languages/XPL =>

wiki:XPL XPL-compiler

LLVM это современный трансмогифер https://en.wikipedia.org/wiki/TMG_(language)

TMG: amakukha/tmg

XPL#SKELETON и skeleton.xpl

PL-I форева

XCOM is a one-pass compiler (but with an emitted code fix-up process for forward branches, loops and other defined situations). It emits machine code for each statement as each grammar rule within a statement is recognized, rather than waiting until it has parsed the entire procedure or entire program. There are no parse trees or other required intermediate program forms, and no loop-wide or procedure-wide optimizations. XCOM does, however, perform peephole optimization. The code generation response to each grammar rule is attached to that rule. This immediate approach can result in inefficient code and inefficient use of machine registers. Such are offset by the efficiency of implementation, namely, the use of dynamic strings mentioned earlier

собственно, если добавить какое-то метапрограммирование в духе CTMP из ConvergePl ltratt/converge intro

уже может получиться интересно.

например, написать свой ассемблер examples/dsls/wsi_asm или конечные автоматы examples/dsls/statemachine

в макросистеме лиспа если рассматривать её как метаязык над объектным языком S-выражений (или даже M-выражений) лиспа – есть базовые операции

• quote
• unquote
• splice
• eval

которые определяют как вычисляются макросы:

eval `(a 'b @c ,d) = list a . quote b . (ins-list (eval c)) . eval d` 
 

в этой макросистеме CTMP типа Template Haskell, MetaLua и т.п.

в метаязыке макросов есть базовые операции:

• квазицитирование
• splicing ( вызывает CTFE)
• insertion (не вызывает CTFE вычислений)

например,

• [| … |] – AST-скобки, например с определением func(arg) и квазицитирование, сохранение <…> в AST-дерево для отложенных вычислений

• $<CEI::lift (func(arg)) > – интерфейс между компилятором для вызова интерпретации типа CTFE

• $<func(arg)> – вызов отложенных вычислений сохранённого AST-дерева

есть понятный интерфейс CEI docs/modules_cvd/CEI.cvd между компилятором и интерпретатором

в общем, Converge PL – это пример того как скрестили рантайм питона и метапрограммирование в стиле Template Haskell

по идее, достаточно взять что-то типа XPL того же самого, и реализовать подобное CTMP метарограммирование, похожий API.

то есть,

There are no parse trees or other required intermediate program forms, and no loop-wide or procedure-wide optimizations.

вот это небольшое дерево разбора в некоторых случаях возвращать и отложенно вычислять, для подобного метапрограммирования.

ну то есть, если добавить в XPL метапрограммирование CTMP из ConvegePL и взять за основу PL-I вместо питона – там может получиться не так уж и сложно, и довольно наглядно при этом.

а вообще, в том же алголе был Jensen device и call-by-name семантика.

по идее, к сущностям call by reference и call by value runtime нужно добавлять нечто типа M-выражений над S-выражениями для вычисления в compile time, и call by symbol reference И сall by symbol value

sym ref использовать для рефлексии (интроспекции в рантайме или интерцессии в компайл тайме) по типам надопобие foo'attr в Аде в M-выражения; sym name – для рефлексии по самим значениям S-выражений.

то есть, запилить такой алгол или PL-I с нормальным метапрограммированием времени компиляции в духе CTMP из Coverge PL или Template Haskell.

фибонача ассемблерова examples/dsls/wsi_asm/fib.cv

остальное определено через DSL через CTMP

фибонача ассемблерова есть метаязык над объектным языком examples/dsls/wsi_asm/WSI_Asm.cv с грамматикой синтаксёвой и семантёвой.

• [| боянистые скобки |] возвращают замороженный AST

• splice annotation разных типов размораживают и вычисляют

• insertions не размораживает и не вычисляет, а просто вставляет

• $<CEI::… > есть по сути документированный интерфейс между splice annotations и рантаймом и компайлтаймом дабы CTFE.

Hal/S >> Fortress >> SISAL метапроговый

SISAL is more than just a dataflow and fine-grain language. It is a set of tools that convert a textual human readable dataflow language into a graph format (named IF1 - Intermediary Form 1). Part of the SISAL project also involved converting this graph format into runable C code.[2]

ну точно – метапрог !!!

только жгутики и проводочки текстовые, в отличие от.