В прошлой части я говорил про адаптацию API Godot к F#. Далее в планах было разобраться с общей структурой приложения, но я столкнулся с необходимостью закрыть серьёзный пробел в публичном корпусе текстов. Так что в этой и последующих частях я буду объяснять нечто странное — как из обычной функции путём эволюции получается работающая программа на Godot.

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

В прошлый раз я в основном говорил о трудностях, которые возникают при попытках совместить F# и Godot. Это была вынужденная мера, так как нас в первую очередь интересовало «стандартное» поведение на случай, когда нестандартное и удобное почему-то не сработало. Можно сказать, что мы учились падать без серьёзных последствий перед тем, как научимся совершать броски и болевые приёмы. Нужный ход, если мы не хотим за пару занятий инвалидизировать большую часть группы, но всё-таки это не то, за чем мы пришли в секцию. Теперь пришло время перейти к рутине, а за ней — и к более агрессивным техникам.

В прошлой части мы проецировали внешние контракты в DTO на примере REST. В этой будем проецировать методы контрактов в нечто, что позволит вызывать их вот так:

let! issues = gitflic.project.["kleidemos"].["myFirstProject"].issue.GET(limit = 24)

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

В данном цикле я хочу поговорить об одном из вариантов представления REST-клиента. Но я буду обсуждать частное (REST), чтобы использовать его как точку опоры для перехода к общему — проблеме проекций внешних контрактов. В первых двух частях я сосредоточусь на синтаксисе и «архитектурных» ходах, а потом поговорю о генераторах кода. Сложность будет расти с каждой частью, но предлагаемые подходы даже в рамках одной части можно применять независимо. Например, сейчас мы поговорим про DTO (Data Transfer Object), в следующий раз — про перенос методов и их иерархии. Это близкие модули, но их взаимное влияние осознанно будет сведено к минимуму.

Ранее я накатал большой цикл по локальному F#-кодогену и высказал намерение периодически возвращаться к генераторам на примере каких-то узконаправленных задачек. Данный цикл — пробный шар в этом направлении. Он логически вытекает из последних двух частей цикла, так что осилившие «Большой код» смогут посмотреть на уже знакомые концепции немного под другим углом.

Godot — игровой движок, который имеет нативную поддержку dotnet. К сожалению, эта поддержка до такой степени заточена под C#, что F# она выходит боком. Почти все проблемы разрешимы, но при недостатке опыта они скатываются в большой пластилиново-волосатый валик у самого входа в подземелье, который иногда приводит к преждевременной и бессмысленной гибели. Чтобы избежать этого в данной статье я дам программу-минимум, которая позволит выжить в Godot, но не выжать из него максимум.

Это не значит, что у сочетания F# + Godot нет своих плюшек. Просто мне хотелось съесть вначале сосредоточить всех мух в одном месте, а котлетами заняться потом и в более свободной манере. Также я предполагаю, что на данную статью будут натыкаться как новички в F#, так и новички в Godot, поэтому местами я буду дублировать базовые руководства.

В прошлой части мы научились определять собственные типы и модули. Мы облекли все достопримечательности в конкретные типы и теперь можем снабдить их индивидуальными свойствами-ребрами (см. рисунок ниже).

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

В прошлых двух частях мы ознакомились с синтаксической моделью F#-кода и с инструментами для неё. Объёмный пример туда уже не влез, но необходимость в нём осталась. Так родились ещё две заключительные части цикла. Их объединяет общий проект, но в остальном они представляют собой сборную солянку фактов, практик и наблюдений, которые было бы трудно разместить в каталогизированной документации.

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

• на какие ноды AST стоит обратить внимание в первую очередь;
• где Fantomas-у нельзя доверять;
• где можно хакать;
• где лучше придерживаться пуризма;
• и как на F# можно строить Fluent API.

В этой части мы сосредоточимся на общей организации генератора, входных данных и основных элементах AST. В следующей сделаем то же самое, но на более сложном уровне, сместив повествование в сторону устройства Fluent API.

В прошлой части мы познакомились с Abstract Syntax Tree (AST).
В этой займёмся его сборкой в полезных объёмах и генерации конечного кода.

В этом многословном, но сравнительно простом цикле я дам введение в генерацию F#-кода.
Как правило, для этих целей в сообществе рекомендуют использовать Myriad, что, по-моему, не совсем правильно, но на его примере можно увидеть, что тема кодогенерации очень объёмна.

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

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

Hopac -- самостоятельный асинхронный движок, написанный специально под F#.
Он стоит на 4 китах, одним из которых является перенаправление потоков вычисления через явное противопоставление конкурирующих задач.

Конкурирующие задачи (или ветки) реализуются через концепцию альтернатив (или Alt), которую я хочу осветить в этом цикле из трёх статей.