В прошлой части мы освоили самые азы альтернатив. Познакомились с Alt, Alt.choose и коммитом. В этой части мы научимся собирать сложные альтернативы на основе базовых, а также скрывать этап их подготовки при необходимости.
Hopac -- самостоятельный асинхронный движок, написанный специально под F#.
Он стоит на 4 китах, одним из которых является перенаправление потоков вычисления через явное противопоставление конкурирующих задач.
Конкурирующие задачи (или ветки) реализуются через концепцию альтернатив (или Alt), которую я хочу осветить в этом цикле из трёх статей.
F#, несмотря на строгую типизацию, отлично подходит для решения разовых задач и исследований. В статье описываются исследования несложной олимпиадной математической задачи при помощи этого языка. В спойлерах приведены пояснения по синтаксису для новичков в F#.
Грокнув Traversable, вы удивитесь, как вы вообще раньше жили без него. Попытки понять Traversable просто глядя на сигнатуру типа никогда не доставляли мне особого удовольствия. Поэтому, в этом посте мы используем другой подход и сами придумаем его в процессе решения реальной задачи. Так мы прочувствуем момент осознания, когда наконец поймем, как он работает, и где его можно применять.
В предыдущем посте мы открыли Аппликативный функтор, а если точнее, изобрели функцию apply. С ее помощью мы решили проблему валидации полей кредитной карты. Функция apply позволила легко объединить результаты каждой функции, отдельно проверяющей одно поле - номер карты, срок действия и CVV - в объект типа Result<CreditCard>, который представляет финальный результат проверки всех данных кредитной карты на корректность. Возможно, вы также помните, что в случае если у нас есть несколько ошибок валидации, мы решили пойти простым путем и просто возвращать первую из них.
В прошлой части мы разобрали базис тестового фреймворка Expecto. В этой рассмотрим основные подходы написания тестов в контексте Expecto и постепенно перейдём к обобщённым преимуществам-следствиям концепции “тест-объект”. Часть выводов по ходу статьи могут быть полезны и не F#-истам. Однако, как говорилось в первой части, изначально это был монолитный текст, что был разделён почти механически, и я не берусь оценить усвояемость данного материала в отрыве от первой части.
Аппликативный функтор, возможно, наименее известный брат монады, но он столь же важен и решает похожую проблему. В этом посте мы постараемся разобраться, что он из себя представляет.
Expecto — фреймворк для тестирования, написанный на F# и для F#. Он довольно хорошо известен в рамках F#-сообщества, и у разработчиков, сумевших отгородиться от C# в достаточной степени, используется как платформа для тестов по умолчанию. Новички в F#, а также мимо проходящие C#-еры, как правило, не обращают внимания на данный фреймворк до первого красного теста. А после знакомства впадают в лёгкий аналитический паралич. Ибо то, что со стороны выглядит как ещё один @"{Prefix}Unit" фреймворк для тестирования, на практике оказывается переосмыслением привычных практик.
В данной статье я попробую широкими мазками описать онтологический аппарат Expecto и показать наиболее естественный путь его подчинения. Это не рулбук, а одноразовое введение, которое я предпочёл бы видеть вместо (или до) существующего README.md в официальном репозитории. Также я постараюсь обойтись максимально локальными примерами кода, дабы текст можно было прочитать, не слезая с самоката.
Это перевод статьи из целого цикла постов "Грокаем функциональное программирование" Мэта Торнтона. Я позволил себе немного поменять порядок постов. В оригинале, функторы идут после монад, что мне показалось неверным. Всякая монада - это функтор, но не всякий функтор - это монада. Также я убрал дублирование из поста про монады и добавил необходимые пояснения. Мне нравится практическая направленность материала. Он довольно подробно останавливается на базовых вещах, так что скорее предназначен для тех, кто только знакомится с функциональным программированием.
В этом посте мы постараемся разобраться, что такое функтор собственноручно переизобретая его на рабочем примере.
В предыдущем посте мы переизобрели Монаду на рабочем примере. У нас получился базовый механизм в виде функции andThen для типа option, но мы еще не достигли нашей конечной цели. Мы надеялись, что получится написать код, так же как если бы нам не нужно было обрабатывать значения option. Мы хотели писать в более "императивном" стиле. В этой части мы увидим как достичь этого при помощи технологии computation expressions языка F#, а также углубим наше понимание Монад.
Всем привет. Среди многих интересных концепций, имеющихся в F#, меня привлекли Discriminated Unions. Я задался вопросом, как их реализовать в C#, ведь в нем отсутствует поддержка (синтаксическая) типов объединений, и я решил найти способ их имитации.
Discriminated Unions - тип данных, представляющий собой размеченные объединения, каждый из которых может состоять из собственных типов данных (также именованных).
Идея в том, что мы имеем ограниченное количество вариантов выбора, и каждый вариант может состоять из своего набора данных, никак не связанных с другими, но все варинанты объединены общим подтипом.
Для создания своих Discriminated Unions будем использовать эту мысль
Самый распространенный способ объяснить монаду - зайти через теорию категорий. Знать, что монада - это моноид в категории эндофункторов и увлекательно и полезно для общего развития, но слабо помогает в практическом смысле. Второй, равный по популярности прием - прибегнуть к помощи образов, и вот мы уже складываем значения в коробочки и достаем их оттуда (или, вообще кошмар, катимся по железной дороге). Не спорю, образы - хороший способ посмотреть на явление, но тут мы равно удалились и от теории категорий и от практики.
Автор, подобно лектору по математике, у которого вылетело из головы доказательство теоремы и он доказал ее прямо у доски, ориентируясь на интуитивное представление, как бы хотелось решить задачу, постепенно пробирается от корявого куска кода к лаконичному.
Задачу я встретил, решая упражнения из книги Структура и Интерпретация Компьютерных Программ).
Раздел 2.3 посвящён цитированию в LISP и символическим вычислениям.
Обычные — несимволические — вычисления сводятся к расчётам с помощью арифметических операций. Если я попрошу вас вычислить производную функции 
в точке 
, вы можете сделать это по формуле при каком-нибудь не очень большом значении 
.
Что может быть лучше десятка пары часов проведенных с дженериками и compile time safety в C#?
В этом очерке о единицах измерения, а точнее о том, как можно сделать потенциально очень крутую систему с полной проверкой на этапе компиляции, автоматической конверсией единиц измерения, кастомизированностью и расширяемостью во все стороны! Да, и еще неплохой производительностью. И вообще!
Вы можете быть новичком в .NET или опытным разработчиком C#/VB.NET, который хочет расширить свои горизонты. В любом случае, F# -- отличный язык для изучения.
F# позволяет легко писать сжатый, надежный и производительный код. Он имеет легкий синтаксис, который требует очень мало кода для создания ПО. Он поддерживается мощной системой типов, удобной библиотекой и средой выполнения .NET, которой вы можете доверять создание правильных, быстрых и надежных программ.
Если вы хотите изучить F#, сейчас идеальное время -- у нас есть много свежих видео, курсов и многого другого, чтобы помочь вам начать работу уже сегодня.
Четыре месяца работы вместе с небольшим количеством новых контрибьютеров наконец-то дали свои плоды в виде нового большого релиза, с которым с удовольствием автор хочет Вас познакомить
Теперь в AngouriMath есть инструменты работы с матрицами, улучшенный парсер, много новых функций, практически полностью переписанный пакет Interactive (для работы в Jupyter) и многое другое.
Эта статья повествует о большом обновлении в FOSS библиотеке символьной алгебры для .NET
Этот пост служит для того, чтобы освежить в памяти, а некоторых познакомить с базовыми возможностями функционального программирования на языке Python. Материал поста разбит на 5 частей:
Главная задача этого поста – показать один мало применяемый на языке Python архитектурный шаблон под названием «функциональное ядро - императивная оболочка», в котором функциональный код концентрируется внутри, а императивный код выносится наружу в попытке свести на нет недостатки каждого из них. Известно, что функциональные языки слабы при взаимодействии с «реальным миром», в частности с вводом данных пользователем, взаимодействием с графическим интерфейсом или другими операциями ввода-вывода. В рамках такого подхода весь императивный код выталкивается наружу, и внутри остается только функционально-ориентированный.
