F# *

До конференции DotNext 2024 осталась всего пара недель, и уже хорошо известно обо всех докладах, которые там будут. Все они делятся на четыре основных категории:

— Best practices: скажем, «Как собирать проекты просто» или «Как использовать АОП в .NET»
— Архитектура: например, про DDD или Serverless
— Internals: как в .NET всё устроено «под капотом»
— «Расширяем горизонты»: всё, что не подходит предыдущим категориям, но тоже полезно дотнетчикам. Например, знали ли вы, что «монады есть у нас дома», то есть в .NET есть аналог этой концепции?

Темы бывают и фундаментальными, вроде «Асинхронность за пределами async/await», и экзотическими, вроде «.NET для чайников» (ну то есть физических чайников с кухни). И вишенкой на всём этом — выступление о саморазвитии от Максима Дорофеева, который хорошо известен многим разработчикам своими материалами о продуктивности.

В этом посте — описания сразу всех докладов, разделённые на эти четыре блока:

Скотт Влащин продолжает рассказ о вычислительных выражениях в F#.

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

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

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

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

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

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

Скотт Влащин продолжает рассказ о вычислительных выражениях в F#. Вычислительные выражения очень похожи на монады из Haskell, но у них есть свои особенности.

Одной из необычных особенностей Haskell являются ленивые (отложенные) вычисления. В F# вычисления энергичные, как и в большинстве других языков, поэтому там нельзя просто так взять и "прервать" вычисление.

Но если очень хочется, то можно. В этой статьей Скотт рассказывает, как сделать ленивые вычислительные выражения в F#.

Вычислительные выражения — поистине неисчерпаемая тема. Мы научились возвращать пустые значения, а теперь нам предстоит разобраться, как возвращать множественные. Скотт Влащин рассказывает, как использовать метод Combine.

Шестая статья из цикла про вычислительные выражения. Скотт Влащин начинает рассказывать детали реализация, и это в два раза интереснее, чем раньше.

Пятая статья из цикла про вычислительные выражения, написанная популяризатором Скоттом Влащиным.

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

Четвёртая статья из цикла Вычислительные выражения Скотта Влащина. Скотт рассказывает о типах-обёртках и об их глубокой связи с вычислительными выражениями.

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

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

Третья статья из цикла про вычислительные выражения в F#. Продолжаем разбираться с функциями-продолжениями и исследуем метод "Bind".

Вторая часть из цилка статей про вычислительные выражения в F#. Здесь Скотт Влащин рассказывает про функции-продолжения. Сложная, но очень важная тема.

Скотт Влащин — безусловный гуру в мире F#, написавший введение в язык, которое рекомендуют новичкам вместо официального руководства.

Группа энтузиастов давно (и с переменным успехом) пытается перевести руководство Скотта на русский.

Я завершаю перевод цикла, посвящённого одной из самых сакральных тем языка — вычислительным выражениям. Это как монады, только в .NET.

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

Далее передают слово автору. Перед вами — первая статья цикла.

По многочисленным просьбам, мы поговорим про тайны вычислительных выражений, о том, что они из себя представляют и как могут применяться на практике (и я постараюсь избегать запрещённого слова на букву М).

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

Введение

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

С одной стороны, их достаточно легко применять. Любой, кто написал достаточно кода на F# наверняка использовал стандартные конструкции, такие как seq{...} или async{...}.

Но как вы можете создать новую похожую конструкцию? Как они работают за кулисами?

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

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

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

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

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

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

Привет, Хабр!

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

В ходе разработки на F# поднимать локальные web-серверы приходится гораздо чаще, чем это принято на C#. Связано это с большим количеством нехарактерных для C# активностей. То, что в C# делают плагины для IDE, у нас делают скрипты, причём их сферы ответственности пересекаются где-то наполовину. Если не понимать этого аспекта, то можно навечно увязнуть в ситуации перманентного нытья о недостаточной поддержке F# со стороны MS.

В этой статье я расскажу про устойчивую комбинацию из Suave, Fable.Remoting и Hopac, которая может стать для вас молотком универсальным решением для реализации локальных служебных серверов.

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

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

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

В этой статье я расскажу, как засунуть F# в Yandex Cloud Functions. Навыка работы с Serverless у меня нет, так что это будет не компиляция моего опыта, а отчет о вполне успешном эксперименте.

Судя по всему, разработчики Yandex Cloud Functions считают, что dotnet = C#. Поэтому документация для dotnet написана только c позиции C#-разработчика. О том, что делать F#-разрабу - ни слова. Однако это не означает, что это невозможно в принципе.