https://youtu.be/s5qeG5hMfEE

но про сам фшарп там не особо много. В основном про то, как ФП хорошо ложится на микросервисы

А докладчик-то — автор книги по Haskell

Антону нужно было приложеньки писать под Android. Что поделать, если поддержка Котлина на этой платформе хорошая, а хаскеля - плохая?

она там не то что плохая, а вообще никакая, плохая она много где.

Я попытался смягчить :)

(но, справедливости ради надо заметить, что кросскомпилятор для андроида теперь самому собирать не надо)

есть ли какие-то способы в F# для контроля побочных эффектов?

Признаться, не представляю, что это может быть. Интересно было бы узнать.

нет таких способов

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

Никак нельзя

"Никак нельзя узнать, что не производится"

Можно руками IO написать

Чтоб было как в Хаскеле )

Нельзя запретить делать эффекты в функции.

Написать систему эффектов то можно

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

https://youtu.be/mOS5qTd7JRY?t=542 в этом видео докладчик показывает, что типо в dotNet есть аттрибут Pure и если прикрутить его к функции, то она является без побочных эффектов, по-другому никак?

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

https://youtu.be/mOS5qTd7JRY?t=542 в этом видео докладчик показывает, что типо в dotNet есть аттрибут Pure и если прикрутить его к функции, то она является без побочных эффектов, по-другому никак?

так это же не проверяется нормально, это такая подсказка, которую программист на свой страх и риск устанавливает

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

то есть со стороны dotNet это никак не будет проверяться?

Не будет

верно, комментарий сайма по этому поводу - как мы введём констрейнт на HOF

верно, комментарий сайма по этому поводу - как мы введём констрейнт на HOF

а что такое HOF?

а что такое HOF?

https://en.wikipedia.org/wiki/Higher-order_function

а понял

Ну можно наверное ещё написать анализатор , который будет чекать известные ему IO вне IO контекста

И сделать его частью своего build'а

И FSharpLint для ide настроить

Но профит от таких усилий неоч ясен + ничего нельзя сказать о сторонних библиотеках

Или просто для себя решить, что вместо IO у тебя всегда Async и RunSynchr.. ты нигде помимо старта прилодения не будешь юзать

а записи каких конференций по F# есть на youtube?

много лет проходит https://skillsmatter.com/conferences/8053-f-sharp-exchange-2017#program смотреть видео можно прямо тут залогинившись

и еще есть сайтик http://c4fsharp.net и тут Ryan давно собирает разные F# выступление в шапке есть ссылки на каналы https://vimeo.com/channels/c4fsharp и https://www.youtube.com/channel/UCCQPh0mSMaVpRcKUeWPotSA/feed

а еще есть выстепления на самом fsharp.org - http://fsharp.org/videos/1

https://github.com/ionide/ionide-vscode-fsharp/issues/404 .fsi починили

Ура-ура, готовы все видео с конференции ? Смотреть тут

Самый топчиковый доклад ? “Николай Рыжиков. ПОЛНЫЙ СТЭК НА "ОДНОМ" ЯЗЫКЕ ИЛИ ИЗОМОРФИЗМ РИЧА ХИККИ”

Самый топчиковый доклад ? “Николай Рыжиков. ПОЛНЫЙ СТЭК НА "ОДНОМ" ЯЗЫКЕ ИЛИ ИЗОМОРФИЗМ РИЧА ХИККИ”

Я смотрел, он почти "продал" мне кложур. :)

"Алексей Пирогов. СКРИПТУЕМ И АВТОМАТИЗИРУЕМ БЕЗОПАСНО С HASKELL" ждем курсы для админов =)?

я уже представляю себе их рекламную компанию

Ой, надо будет посмотреть. Кажется, у меня вот-вот освободится немножко времени

"Алексей Пирогов. СКРИПТУЕМ И АВТОМАТИЗИРУЕМ БЕЗОПАСНО С HASKELL" ждем курсы для админов =)?

Не, курсы для админов не хочу делать :)

Вот смотрю на Haskell, в нем пишется объявление функции и реализация отдельно? А можно так же на F#?

ну, на первый взгляд, при помощи пары расширений можно

параметры, по крайней мере, аннотация возвращаемого значения по другому будет выглядеть

Не, курсы для админов не хочу делать :)

Предположим, я написал скрипт на Haskell с Turtle. Потом я захотел получить отдельный исполняемый файл из этих скриптов. Мне прийдется создать отдельно проект и перетащить файлы скриптов или есть какой-то "магический" инструмент, которому я просто укажу скриптики и получу исполняемый файл?

Можно просто скомпилить бинарь. Без создания проекта

Можно просто скомпилить бинарь. Без создания проекта

вау

Можно просто скомпилить бинарь. Без создания проекта

а как со стековым скриптом-то это сделать?

stack ghc <имя_скрипта>.hs

он так разве поймет какие пакеты в соотв строчке внутри файла прописаны? Вроде ж это надо в самом файле runghc на ghc править

если скрипт - именно script, то все пакеты и так будут указаны в stack-комменте

да, но если передать скрипт фактически в ghc в окружении т.е. stack ghc разве стек вообще будет эту строчку в комменте читать?

> cat Hi.hs -- stack --resolver=lts-8.20 script --package=turtle {-# LANGUAGE OverloadedStrings #-} import Turtle main = echo "Hi!" > stack ghc Hi.hs

Всё собралось

@haskellru

Прошу извинить и больше не буду

Вот смотрю на Haskell, в нем пишется объявление функции и реализация отдельно? А можно так же на F#?

Т.е. вы хотите C/C++ с хэдер файлами?

Думаю, имеется в виду написание в виде f : Int -> Int -> Int f x y = x + y * x

в отдельном файле-то и в F# можно сигнатуры отдельно прописывать

Думаю, имеется в виду написание в виде f : Int -> Int -> Int f x y = x + y * x

да, оно самое

в отдельном файле-то и в F# можно сигнатуры отдельно прописывать

да, но только насколько я знаю через интерфейс и абстрактный класс

Думаю, имеется в виду написание в виде f : Int -> Int -> Int f x y = x + y * x

то есть похожим образом написать в F# нельзя?

да, но только насколько я знаю через интерфейс и абстрактный класс

не только, я про .fsi файлы

только в одельных файлах #f.fsi val f : int -> int -> int #f.fs let f x y = x + y * x

Я сначала просто вопрос не понял, думал, можно ли на хаскеле как на F# типы аннотировать

только в одельных файлах #f.fsi val f : int -> int -> int #f.fs let f x y = x + y * x

для .fsx так не получиться, только .fsi и .fs?

вроде да

в F# только это бесполезная фича, в других эмелях можно параметризовать модули, и типы параметров - вот такие вот сигнатуры, т.е. можно подменять "импорт" одного модуля другим, который ту же сигнатуру имплементирует

в F# только это бесполезная фича, в других эмелях можно параметризовать модули, и типы параметров - вот такие вот сигнатуры, т.е. можно подменять "импорт" одного модуля другим, который ту же сигнатуру имплементирует

а в F# можно только скрыть часть деталей реализации, получается?

а, ну да, публичность-то таким образом регулируется, так что не бесполезная

В .fsi-файлах, к сожалению, сигнатуры не влияют на вывод типов в файлах с кодом

Что-то я недовкурила эту особенность модулей в эмелях, надо будет потом наверстать

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

В .fsi-файлах, к сожалению, сигнатуры не влияют на вывод типов в файлах с кодом

то есть, мне все равно прийдется указывать тип, если система типов не сможет вывести его?

то есть, мне все равно прийдется указывать тип, если система типов не сможет вывести его?

Ага

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

Ну и ещё в них можно вынести документирующие комменты

то есть, мне все равно прийдется указывать тип, если система типов не сможет вывести его?

И ещё если в коде вдруг выводится тип, не соответствующий указанному в fsi, просто ошибка выводится.

Даже если авто-выведенный тип можно привести к типу, указанному в сигнатуре.

Ага

#f.fsi val f : TypeA -> int #f.fs let f a = a.ToInt() + 1234То есть тут мне прийдется указать: #f.fs let f (a:TypeA) = a.ToInt() + 1234Так что ли?

Вроде, да

печальненько

Надо бы, конечно, проверить. А то я всего один раз пробовал fsi-файлами пользоваться. И не использовал их больше, потому что они оказались не тем, что я ожидал.)

Даже если авто-выведенный тип можно привести к типу, указанному в сигнатуре.

странно, я думала, в сигнатуре допустим более общий тип по сравнению с тем, что вывелся

это должно от позиции (положительной/отрицательной) зависеть

странно, я думала, в сигнатуре допустим более общий тип по сравнению с тем, что вывелся

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

т.е. вообще-то в эмелях сигнатуры матчатся так что имплементация может принимать более общие типы и возвращать более конкретные (тут мне главное не перепутать)

т.е. вообще-то в эмелях сигнатуры матчатся так что имплементация может принимать более общие типы и возвращать более конкретные (тут мне главное не перепутать)

аа, это контравариантность и коваринтность

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

да

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

так. нет, наоборот должно быть

да

натупила походу

ай, это всегда мозг взрывает

да

ковариантность и контравариантность для subtyping же работает, а тут с этим параметрическим полиморфизмом по-другому. Или нет. Или да. аааа

Насчёт влияния fsi-файлов на вывод типов в файлах с реализацией: https://github.com/fsharp/fslang-suggestions/issues/522 Там в конце Дон Сайм объяснил, почему эту фичу не завезли и скорее всего не завезут.