ICFP 2020 — двадцать пятая конференция под эгидой ACM SIGPLAN. В этом году конференция будет проводиться онлайн, и все события, проходящие в её рамках, будут онлайн.

Соревнование ICFP по программированию будет проводиться с 17 июля по 20 июля 2020 года (то есть, уже через два дня).

Сама конференция будет проходить с 24 по 26 августа 2020, и укладываться в два тайм-слота. Первый слот будет проходить с 9:00 до 17:30 по времени Нью-Йорка, и будет включать как технические, так и социальные мероприятия. Второй тайм-слот будет проходить с 9:00 до 17:30 по Пекинскому времени, на следующий день, и будет с незначительными вариациями повторять содержимое предыдущего дня, включая технические и социальные мероприятия.

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

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

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

В прошлой пилюле мы собрали свою первую деривацию. Правда, она не делала ничего полезного, и эту оплошность надо исправить.

В очередной — седьмой — пилюле от Люка Бруно создадим деривацию, которая реально собирает и устанавливает программу в хранилище Nix.

Дорогой Хабр, через два месяца мне предстоит организовать и провести фестиваль компьютерного искусства, поэтому я уже сейчас собираю информацию про необычные проявления демосцены, на которые обычно никто не обращает внимания. Язык программирования для генеративной музыки ByteBeat — это как раз то, что я ищу.

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

Послушать пример из заглавной картинки: [sarpnt][greggman]

Совсем недавно команда разработки Dart выпустила 3-ю версию языка, которая привнесла много новых крутых штук и возможностей. Одним из нововведений стали модификаторы классов, которые довольно сильно расширили выразительные возможности Dart. С одной стороны, новые модификаторы ложатся в стройную картину и даже логичны; с другой - чувствуется некоторая многословность ( abstract interface class вместо общепринятого interface) и появление ряда ограничений, которых ранее не было. Новые модификаторы классов безусловно интересны и требуют внимания, но сегодня мы будем говорить не о них). Оставим уже вышедшие модификаторы для одной из следующих статей. Логично задаться вопросом: о чем тогда сейчас пойдет речь? Заинтригованы? Тогда добро пожаловать под кат.

В данной статье рассматривается создание расширяемого алгоритма строкового калькулятора, который позволяет пользователю самостоятельно определять операции и константы, с которыми работает калькулятор. Основная цель статьи - предоставить описание процесса разработки и реализации такого алгоритма, а также продемонстрировать его гибкость и возможности для настройки под индивидуальные нужды пользователей.

В данной статье исследуется метод оценки параметров систем дифференциальных уравнений на основе неточных наблюдений. Автор проводит численный эксперимент с использованием языка программирования Scala для оценки реальных результатов и более подробного изучения предложенного алгоритма. Алгоритм оценки параметров включает подготовку данных, генерацию неточных наблюдений, использование численных методов для решения системы уравнений и оценку приближенных значений параметров. Эксперимент проводятся на системе Лоренца, и результаты оценки параметров сравниваются с реальными значениями. Заключение статьи делает выводы о применимости метода и его эффективности при оценке параметров систем дифференциальных уравнений на основе неточных наблюдений.

В этом ознакомительном учебном пособии мы рассмотрим концепцию замыканий в Groovy, являющуюся ключевой особенностью этого динамичного и мощного языка JVM. Концепцию замыканий поддерживают и многие другие языки, включая Javascript и Python. Однако в разных языках характеристики и функционирование замыканий различаются. Мы рассмотрим ключевые аспекты замыканий в Groovy, попутно демонстрируя примеры их использования.

Статья предполагает, что читатель имеет опыт работы с интерактивным программным средством доказательства теорем — Coq.

Статья является адаптированной русскоязычной версией моей статьи, написанной во время работы над формальной верификацией протокола криптовалюты Tezos.

В данной статье мы рассмотрим прием, который используется для работы с рекурсивными функциями, которые не проходят проверку завершаемости (тотальности) в Coq. Под «горючим» мы будем понимать натуральное число, которое вводится как дополнительный параметр в тело функции, чтобы обозначить верхнюю границу числа итераций, которые функция может совершить. Таким образом функция трансформируется в завершаемую, удобную для работы, и радушно принимаемую компилятором Coq. В литературе термин встречается под названиями: petrol, fuel, gas и т.д.

Положим, перед нами стоит задача: необходимо верифицировать функцию, написанную на каком-либо языке программирования. Мы разбираемся в том, что делает эта функция, уже прикидываем, какие леммы сформулируем, чтобы доказать, что она ведет себя именно так как ожидается. Переводим функцию на Coq (вручную, или с помощью автоматических переводчиков, если только таковые имеются для требуемого языка), и видим, что проверка Coq на завершаемость нашей функции (termination check) провалилась.

Это значит Coq не может определить какой аргумент на каждом шаге итерации будет уменьшаться. Можно попробовать явно указать Coq на аргумент, который, мы точно знаем будет уменьшаться на каждом шаге {struct уменьшаемый_аргумент}:

Статья предлагает взглянуть на опыт разработки парсер комбинаторов для Python, что вылилось в библиотеку PGPC для разработки парсеров на Python. Библиотека была вдохновлена Parsec.
Особый интерес представляет эмуляция do-нотации через Python генераторы, отсюда и название библиотеки: Python Generator based Parser Combinator library.

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

Введение

Как узнать, что человек понял, что такое монады? Он сам вам об этом расскажет в первые 5 минут общения и обязательно попробует объяснить. А ещё напишет об этом текст и по возможности где-нибудь его опубликует, чтобы все остальные тоже поняли, что такое монады.

Среди функциональных программистов, особенно на Haskell, монады стали чем-то вроде локального мема. Их часто пытаются объяснить, отталкиваясь от частных случаев и сразу приводя примеры использования. Из-за этого слушатель может не уловить основную суть понятия, а монады так и останутся чёрной магией, ну или просто средством костылизации побочных эффектов в чисто функциональных языках.

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

Моё изложение во многом основывается на книге Бартоша Милевски "Теория категорий для программистов", которая создавалась как серия блогпостов, доступна в PDF, а недавно вышла в бумаге.

Примеры приводятся на Haskell, предполагается, что читатель знаком с синтаксисом и основными понятиями языка. В упомянутой книге есть примеры и на С++, можете сравнить чистоту и понятность кода.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи "A tale on Semirings" автора Luka Jacobowitz.

Когда-нибудь задумывались, почему сумма типов называется суммой типов. Или, может, вы всегда хотели узнать, почему оператор <*> записывается именно так? И что это имеет общего с полукольцами? Заинтересовавшихся прошу под кат!

Введение в функциональное программирование

ПАЛИНДРО́М
Мужской родСПЕЦИАЛЬНОЕ
Слово или фраза, которые одинаково читаются слева направо и справа налево.
«П. «Я иду с мечем судия»»

function getPalindrom (str) {
  const regexp = /[\.,\/#!$%\^&\*;:{}=\-_`~()?\s]/g;
  str = str.replace(regexp, '').toLowerCase().split('').reverse().join('');
  //далее какой-то аякс запрос в словарь или к логике, которая генерирует фразы по переданным буквам

  return str;
}

function isPalindrom (str) {
  const regexp = /[\.,\/#!$%\^&\*;:{}=\-_`~()?\s]/g;
  str = str.replace(regexp, '').toLowerCase();
  return str === str.split('').reverse().join('');
}

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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