Обычно рекомендуется избавляться от явной рекурсии

ну тут не согласен) рекурсия очень даже идиоматична для фп

В ФП принято использовать всякие комбинаторы и т.п. вроде fold

я всё же не очень понимаю, можно подробнее?

Свёртка - это паттерн. Паттерны, это хорошо

Правильно написать рекурсию может не каждый, да и выделение повторяющейся логики - обработки edge cases, отделения головы от хвоста - стоит выносить. Вот и вынесли уже в функции свёртки

Никто же не переписывает код с map на ручную рекурсию. Вот и со свёрткой та же ситуация

Ручной рекурсии место там, где по-другому никак. Mutual recursion например

"Пишешь рекурсию с аккумулятором? Скорее всего тебе нужна свёртка!"

фильтер, мап, редюс

в математике это свёртка, поэтому названия типа reduce (или inject вообще) - только запутывают людей :) Только fold!

математика, люди синуса не знают а вы о математике

А зачем тогда они в ФП лезут вообще? Придётся же всё равно хоть в каком-то объеме изучить :)

А зачем тогда они в ФП лезут вообще? Придётся же всё равно хоть в каком-то объеме изучить :)

Затем же, зачем математики лезут в программирование. Тоже ничего не понимают, но очень хочется

А за объяснение спасибо

Если деуствительно хочется, то и математики небольшого кол-ва не испугаются :)

Да, не испугаются. Но насколько я вижу, ФП требует понимания программирования, а не понимания математики

Да кстати не всегда, квантовую химию сложно понять, а вот объяснить ещё сложнеею Про квант мех я вообще молчу

Пока писал уже удалил)

побоялся что поколотят

Да, не испугаются. Но насколько я вижу, ФП требует понимания программирования, а не понимания математики

"не понимание математики" - вот здесь неправда.

побоялся что поколотят

21 век, бояться что поколотят в чате телеграма

в математике это свёртка, поэтому названия типа reduce (или inject вообще) - только запутывают людей :) Только fold!

Aggregate в LINQ

просто есть проблема "бродячих мифов" то от рекурсии надо избавляться то еще чтонибудь

вот и избавляются от рекурсий и пишут циклы

не надо избавляться от рекурсии. Просто рекурсию с аккумулятором, написанную руками, можно и нужно упрощать до свёртки

Единственная причина не использовать свёртку - необходимость прервать рекурсию до того, как сворачиваемые данные кончатся.

Единственная причина не использовать свёртку - необходимость прервать рекурсию до того, как сворачиваемые данные кончатся.

в приведённом мной коде так и есть

Ваш конкретный пример вполне нормально написан - тут рекурсия к месту, ИМХО

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

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

цикл в F# кстати тоже может заметно тормозить из-за того во что всякие n .. 2 .. k компилируются

Внутри свёртки может быть цикл :) Но выглядет будет функциональненько :)

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

так же дотнетный IEnumerable<T> довольно тормозной по сравнению со своими аналогами из других языков

Печаль

поэтому в горячем месте со всем этим комбинированием комбинаторов в F# особо не разгуляешься.

В более прохладных местах то можно :)

вот так всегда неделанье оптимизаций и обосновывают!

вот так всегда неделанье оптимизаций и обосновывают!

Что там страшнейшее из зол?

Оптимизировать корректное всегда проще, чем корректировать оптимизированное

вот так всегда неделанье оптимизаций и обосновывают!

если у тебя IO работает 300 ms, то выгрызать ns у fold ты не будешь :)

и какое-то довольно громкое заявление про IEnumerable<T>) Лев Толстой, поди

Оптимизировать корректное всегда проще, чем корректировать оптимизированное

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

если у тебя IO работает 300 ms, то выгрызать ns у fold ты не будешь :)

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

К проблемам приводит забивание гвоздей микроскопом. В 99% случаев производительности хватает и так, а в 1% все равно нужна возможность подхачить ручками.

В яве нет генериков в рантайме и непримитивных значений - это как раз мешает сделать код быстрее даже руками

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

» с нормальной скоростью работали what is normalnaya skorost`?)

А не надо думать про тормоза до того как они возникают - преждевременная оптимизация что у нас по Кнуту?

В яве нет генериков в рантайме и непримитивных значений - это как раз мешает сделать код быстрее даже руками

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

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

А для непримитивов даже накостылять не могут. Вот это бяда

Я предлагаю направить разговор в другом направлении: вот код, вот бенчмарк, давайте обсуждать.

А в шарпе - сделал чтобы работало, потом МОЖЕТ БЫТЬ в 1 месте из 100 нужно (и можно) подхачить

Я предлагаю направить разговор в другом направлении: вот код, вот бенчмарк, давайте обсуждать.

Немного в другом не сходимся - я вообще не вижу смысла бенчмаркать и т.п., пока не нарушены нефункциональные требования

А для непримитивов даже накостылять не могут. Вот это бяда

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

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

Как и напоминать про тормозные итераторы в том же дотнете ;)

Как и напоминать про тормозные итераторы в том же дотнете ;)

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

> Потому что это проблема не решенная Как именно не решенная? Код на итераторах можно руками превратить в быстрый. В 99% случаев медленность итераторов вообще не трогает.

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

Обсуждение хорошо известной проблемы без предложения решения - неконструктивно

почему без предложения? Я приводил пример имплементации более эффективных "итераторов" в другом языке.

почему без предложения? Я приводил пример имплементации более эффективных "итераторов" в другом языке.

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

существует вполне рабочий подход для эффективной имплементации таких штук как "свертки" (обычно там не чистая свертка, так что в кавычках) существуют даже костыли, которые эмитят оптимизированный код или используют уже существующие оптимизации (не очень успешно) https://arxiv.org/pdf/1406.6631.pdf просто это все должно в компиляторе быть, а не прикостылено

Как по мне, использование коробочных решений by default предпочтительнее, ведь их рано или поздно опимизируют в отличае от моего кода

Как по мне, использование коробочных решений by default предпочтительнее, ведь их рано или поздно опимизируют в отличае от моего кода

Именно. Нет смысла оптимизовать руками, пока к этому не принуждает проект здесь и сейчас

Я обычно понимаю оптимизацию, как правильную комбинацию коробочных инструментов

а не написание своих

Переписывание Seq в F#, кстати, застопорилось. https://github.com/Microsoft/visualfsharp/pull/2745

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

это просто пруф оф концепт для того что должно быть в компиляторе ФЯ но нету

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

это просто пруф оф концепт для того что должно быть в компиляторе ФЯ но нету

Потому что этот ФЯ - побочка к ООП-рантайму

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

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

зато какие это полтора человека) 1 фпшник > 100 оопшников, очевидно же

Переписывание Seq в F#, кстати, застопорилось. https://github.com/Microsoft/visualfsharp/pull/2745

А из-за чего начали переписывать?

А из-за чего начали переписывать?

Производительность хотели улучшить.

Это очень долгая тема, я уже не верю, что когда-нибудь смержат.

То есть уже третий PR к ряду, и там около 8к LoC нового кода с конфликтами.

всем чатиком пулим и резолвим

Это очень долгая тема, я уже не верю, что когда-нибудь смержат.

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

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

Не припоминаю.

всем добрый день, вопрос такой: если мэтчим, например, простой инт, то можем перечислять несколько вариантов таким образом: match x with | 1 | 3 | 8 -> "good" | _ -> "bad" если же мэтчим опциональный тип с каким-то условием, было бы классно писать что-то типа match option with | None | Some when <...> -> "good" | _ -> "bad", но компилироваться это не хочет, приходится писать match option with | None -> "good"| Some when <...> -> "good" | _ -> "bad", т.е. если вместо "good" будет что-то достаточно большое, придётся либо копипастить, либо выносить в функцию (но кода всё равно становится больше, его модификация требует лезть уже как минимум в два места) можно ли как-то это обойти штатными методами?

как вариант вижу попользовать AP, наверное

всем добрый день, вопрос такой: если мэтчим, например, простой инт, то можем перечислять несколько вариантов таким образом: match x with | 1 | 3 | 8 -> "good" | _ -> "bad" если же мэтчим опциональный тип с каким-то условием, было бы классно писать что-то типа match option with | None | Some when <...> -> "good" | _ -> "bad", но компилироваться это не хочет, приходится писать match option with | None -> "good"| Some when <...> -> "good" | _ -> "bad", т.е. если вместо "good" будет что-то достаточно большое, придётся либо копипастить, либо выносить в функцию (но кода всё равно становится больше, его модификация требует лезть уже как минимум в два места) можно ли как-то это обойти штатными методами?

match option with | None | Some when <...> -> "good" | _ -> "bad"

Так работает?

нет

всем добрый день, вопрос такой: если мэтчим, например, простой инт, то можем перечислять несколько вариантов таким образом: match x with | 1 | 3 | 8 -> "good" | _ -> "bad" если же мэтчим опциональный тип с каким-то условием, было бы классно писать что-то типа match option with | None | Some when <...> -> "good" | _ -> "bad", но компилироваться это не хочет, приходится писать match option with | None -> "good"| Some when <...> -> "good" | _ -> "bad", т.е. если вместо "good" будет что-то достаточно большое, придётся либо копипастить, либо выносить в функцию (но кода всё равно становится больше, его модификация требует лезть уже как минимум в два места) можно ли как-то это обойти штатными методами?

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

match option with | None | Some when <...> -> "good" | _ -> "bad"

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

А если написать все же None | Some 1 | Some 3 | Some 8 -> good

А если написать все же None | Some 1 | Some 3 | Some 8 -> good

да, так работает, но бывают нужны более сложные условия :)

Если параметр в Some используется, то возникает различный набор переменных, в случае None такой переменной не существует, вот он и ругается.

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

просто вдруг уже есть какой-то стандартный active pattern для подобных вещей

А можно пример синтаксиса такого шаблона?

А то мне в голову не приходит, как его можно зауниверсалить.

пытаюсь написать, но, похоже, я тупой

вот это компилируется: let (|NoneOrCond|Other|) condition option = match option with | None -> NoneOrCond | Some x when condition x -> NoneOrCond | _ -> Other

но я теперь не знаю как это использовать потому что на let test cond t = match t with | NoneOrCond cond -> "good" | Other cond -> "bad" компилятор ругается

а что если "разобрать" значение опционального типа и после уже сравнивать в match?

всм всё это делать в AP?