Часть 3/3. Компилятор идеальной VM для ICFPC 2009, на Haskell, с популяризаторскими комментариями

[mikhanoid]

+1, но вот не нужно так нажимать на 'формальное' или 'математическое' мышление, к которому, якобы, склоняют функциональные языки. IMHO, сиё есть заблуждение. Математика не позволяет описывать динамические объкеты. Описывать их свойства позволяет, но сами объекты — нет. Собственно в Haskell мы с этим сталкиваемся, когда нужно устроить ввод/вывод. Кроме того, функциональным языкам уже лет 50 (они старше даже, чем Си), но при этом, люди, которых сложно обвинить в недостатке математического мышления: физики-теоретики, 'распознаватели' образов, математические моделисты и прочие — предпочитают всякие C и Java. Так что, это неправильно считать, что людям с математическим мышлением в Haskell всё ясно. Математика тоже допускает различные стили мышления.

И ещё… Когда программа вот так на куски разбита довольно сложно следить за её общей структурой. Можно, конечно, всё в блокнотик скопировать последовательно, но лень же :)

[VoidEx]

Можете уточнить, с чем именно, не описываемым математикой, мы сталкваемся в Haskell при вводе-выводе?
С задачами же распознавания образов все, по-моему, достаточно банально — там нужна высокая производительность.

[San13]

В моем предыдущем посте была ссылка на исходный код как он есть. Про структуру программы — в следующий раз придумаю, как ее сверху вниз рассматривать, спасибо. Этот же пост задуман для людей, которым любопытно узнать как оно вообще, а есть ли жизнь на марсе?

[khayrov]

Класс. А я убоялся связываться с VM на Haskell, написал на C++, логику стал писать на OCaml и в итоге ничего не успел за сутки, которые удалось выделить.
Оптимизирующий компилятор из кода регистровой машины в Haskell — это пять. Ещё бы скормить AST LLVM и получилась бы самая быстрая реализация VM.

И ещё: для чтения опкодов наверное удобнее было бы использовать Data.Binary вместо FFI.