to post messages and comments.

Устанавливать старый опасный OCaml 3.12.1 не пришлось, FAR arclite справился с форматом NSIS. Директорию выбрал C:\ocamlmgw, как зашито в бинарники, потому что они там ищут библиотеки. Пришлось выжечь калёным HIEW из каждого flexlink.exe аргумент -mno-cygwin, который современный gcc не в силах потерпеть. Доустановить hg clone git+https://gitlab.camlcity.org/gerd/lib-findlib.git . Поставить make и perl из msys2. Закомментировать строчку 2202 в cpc.ml. И получилось собрать!

Без pthread и libev под Windows примеры не работают, но я всё равно под Windows только препроцессор хотел. Перловая обёртка вполне успешно собирает ошки, в том числе с сохранением промежуточных файлов. Для того, чтоб собрать ошки, рабочая реализация рантайма не нужна. Нужно отпрепроцессировать выбранным транслятором, потом отпрепроцессировать cpc cilly, потом оттранслировать обычным транслятором, вот такие этапы делает перловая обёртка. Смотрел промежуточный результат, вроде похоже на правду.

Промежуточный результат не такой оптимальный, как я надеялся. Скажем, g() в loops.cpc делает cps_yield(), имея аргумент c и переменную i. Я бы ожидал, что c и i между cps_yield() как сидели в контексте, так и оставались, но вместо этого __g_while_continue_2_push() постоянно принимает на вход c и i, перевыделяет под них место и копирует из своих аргументов в структуру. А процедуры, на которые ссылаются продолжения, постоянно открывают структуры со своими аргументами, вытаскивают оттуда c и i и под конец вызывают одну из _push() с этими c и i. И так по кругу. Чем больше стек процедуры, преобразованной в асинхронный вид, тем больше круговорот.

Прошлый раз потерпел неудачу с запуском Continuation Passing C, и вроде это было связано с устареванием CPC и встроенной в него версии CIL относительно OCaml. Так что в этот раз пытаюсь взять старый OCaml. В cpc/README указан Ocaml >= 3.12. Вот, значит, лучше всего и взять. Нашёл установщик OCaml 3.12.1. В предупреждении написано, что он уничтожит PATH, если переменные среды занимают больше 1024 байт, но я к этому могу подготовиться. На установщиках IBM VisualAge и Apple WebObjects уже натренирован.

Пытаюсь запустить Continuation Passing C
cpc.native.exe завершается с ошибкой: Программа "cpc.native.exe" не работает. Возникшая проблема привела к прекращению работы программы. Windows закроет эту программу, а если есть известный способ устранения проблемы, уведомит вас об этом.
cpc.byte.exe создаёт файл, который его просят, но виснет.

Почему-то типично для всяких Аллегро Лиспов и Окамлей

Нативный OCaml в телефоне — ygrek.org.ua
Вообще termux очень удобная штука оказалось, легко устанавливается, куча пакетов с привычным софтом — ssh, git, rsync, итд. Даже gdb работает!

TEHDRAMA в github.com закончилась добровольным признанием автора в бесплодности попыток изменить божественный калемвский stdlib. Но революционно настроенные массы не теряют надежды в github.com

Открыл Википедию ==> увидел ;; ==> закрыл Википедию. Не считая лиспов и Хаскеля, у функциональщины синтаксис какой-то идиотский.

Похоже, я не писал в жуйк о чудесном эксперименте с сортировкой флоатов, который я когда-то проводил. Предлагаю провести его и вам(@SannySanoff, например, тебе). Итак, основа для эксперимента — задачка с Ponder This: domino.research.ibm.com
Если очень кратко: представьте, что вы стоите в саду на плоскости, в точке 0,0. В каждой точке с целыми координатами растёт дерево определенного радиуса. Сам сад тоже имеет радиус — 9801, за пределами сада деревья не растут. Начиная с определенного радиуса деревьев вы не сможете увидеть край сада. Нужно определить радиус, начиная с которого это произойдёт.
Но я хотел рассказать о подзадаче, которая может возникнуть при решении в лоб. Для определённого радиуса деревьев для каждого дерева(если забить на остальные деревья) у вас есть угол, начиная с которого дерево блокирует зрение, и угол, начиная с которого дерево больше ничего не блокирует. Подзадача: для каждого дерева в первой кварте (половина первой четверти) построить пары таких флоатов и затем лексикографически эти пары отсортировать. Пар должно быть около 40 миллионов.
Интересны результаты для разных языков, если писать в лоб и использовать стандартные фичи. С++ очень шустр, требует мало памяти (около 300мб, ЕМНИП). СPython помедленней, но ест тоже совсем чуть-чуть, 500-600мб. PyPy намного быстрее CPython, но и памяти съедает больше гига. OCaml съедал два гига. Другая OCaml версия с чьей-то помощью приближалась к Python по потреблению памяти, обгоняя его по скорости. Java версия сжирала 4 гига, работала очень медленно. А если VM ограничить по памяти, то вообще ооочень медленно. Благодаря помощи джавистов удалось загнать Java в рамки 2-х гигов, но качество кода пострадало. Haskell версию заставить нормально работать я не смог, падала по памяти. JS версия тоже не пережила такие запросы по памяти.
Теперь дополнительно, по выразительности по версиям, которые показывали максимальную производительность при минимальном потреблении памяти:
1 место — Python. Никаких оптимизаций проводить не понадобилось. Сортируем стандартные таплы, получаем малое потребление.
2 место — С++. Никаких оптимизаций проводить не понадобилось. Сортируем пары, получаем скорость и малое потребление.
5 место — Java. Пришлось отказаться от использования стандартных средств языка для работы с парами как с объектами.
8 место — OCaml. После оптимизаций код на OCaml стал больше походить на С, чем на функциональщину.
Обратите внимание на отсутствие 3,4,6 и 7 места. Это из-за разрыва в читабельности. Вывод: Python и C++ — офигенные языки, в которых выразительность не принесена в жертву memory footprint, а в случае с С++ — и скорости. Функциональные языки очень расстроили своим непредсказуемым потреблением памяти. Java удивила тем, насколько простая задача может требовать ручных оптимизаций.
Если кто считает, что я не прав — пишите программы, сравнивайте. Буду рад почитать.