да

кстати

У этой штуки же будет тип unit, это не функция вообще. А recread - функция, ещё и рекурсивная

понятно, но рекурсивные объекты в f# тоже есть

хммм..

А подскажите) пишу в ВС , но там вроде с порядком файлов беда какая-то... я так понимаю для организации файлов нужен FAKE?

рекурсивные объкты

вопрос-то не в функция-нефункция, а в том, почему не компилируется

А подскажите) пишу в ВС , но там вроде с порядком файлов беда какая-то... я так понимаю для организации файлов нужен FAKE?

какая беда?

Я добавил файл, но ВС его не видел, пока в fsproj не поменял порядок (наверное так было)

Я добавил файл, но ВС его не видел, пока в fsproj не поменял порядок (наверное так было)

«не видел» — это в смысле компилироваться не хотело?

Да, не понимало, что он к меня есть

порядок файлов важен, там можно в контекстном меню выбрать Move Up или Move Down

Я читал что-то про порядок файлов

А fake для чего нужен?

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

А fake для чего нужен?

FAKE — это F# Make. это чтоб билды собирать )

А что значит собирать? В exe или как? ВС этого не делает?

порядок файлов важен, там можно в контекстном меню выбрать Move Up или Move Down

там — это в Solution Explorer в смысле

А что значит собирать? В exe или как? ВС этого не делает?

ну да, в exe или dll. VS не делает, это делает MSBuild, а VS только говорит MSBuild, что надо сделать. FAKE по сути делает то же самое, только ты можешь на F# написать MSBuild инструкции, как тебе нужно собрать сборку или что ты там хочешь собрать (+ запустить тесты, задеплоить результать куда-нибудь и так далее).

Ааа, спасибо!

а теперь можно поподробнее про рекурсивные объекты?)

вот

кстати ничего не мешает узнать у автора, он же вроде тут сидит

скрин с книги

c# какойто

c# какойто

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

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

поэтому будет сразу учить неправильно?

а потом переучивать?

Он не учит "неправильно", он показывает пример кода, который будет понятен читающему с императивным опытом.

Т.е. показывает переложение известных конструкций на f#.

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

Он не учит "неправильно", он показывает пример кода, который будет понятен читающему с императивным опытом.

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

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

не нашел http://knigorazvitie.ru/book/81-funkcionalnoe-programmirovanie-na-yazyke-f-shamshev-an-b/19-22-struktura-dannyx-odnomernyj-massiv.html

хотя подмена автора занятна

И как надо переписать это пример в ФП, если в данном месте дается пример ResizeArray? "Другим типом, который стоит упомянуть, является тип List<_> библиотеки .NET. Во избежание конфликта имен в библиотеке F# этот тип переименован в ResizeArray. "

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

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

раздел называется "2.2. структура данных: одномерный массив" причем в оригинале они еще и почему то рекурсивные. возвращается вообще string list (почему-то). зачем там вообще ResizeArray - никому неясно

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

плохое в этом то что они застревают в императивном мире. и собственно не видят другого способа решения задач.

скачал с оф сайта код к книге

// "Неровные" многомерные массивы // ------------------------------ // Строим треугольник Паскаля let pascal n = let rec pas L n = let A::t = L in if n = 0 then L else pas (((1::[for i in 1..(List.length A-1) -> A.[i-1]+A.[i]])@[1])::L) (n-1) pas [[1;1]] n pascal 10;;

в каком месте это массив? чему книга учит?

раздел называется "2.2. структура данных: одномерный массив" причем в оригинале они еще и почему то рекурсивные. возвращается вообще string list (почему-то). зачем там вообще ResizeArray - никому неясно

Чтобы накапливать состояние не забивая человеку голову fold-ом, я уже года два с половиной агитирую с разной интенсивностью за F#, и у большинства начинаются адовые затупы на reduce/fold/(и даже aggregate для C#). Рецепта быстрого объяснения этой штуки я не нашел, ощущение, что человека просто надо оставить на несколько часов/дней рефлексировать, чтобы до него это дошло. Думаю Сошников столкнувшись с этим на практике пришел к аналогичным выводам (либо почерпнул их из другой ФП литературы)

в каком месте это массив? чему книга учит?

Здесь согласен, хотя контекста не видел.

там не нужно накапливать состояние, это просто построение массива/списка

там не нужно накапливать состояние, это просто построение массива/списка

Массив неопределенной длины? -> ResizeArray Список? А чем это не накопление состояния?

ResizeArray - зачем?

памяти и процессора много? а потом говорят что F# медленный и жрет много

"Список? А чем это не накопление состояния?" уточню что для построения списка ResizeArray для накопления состояния не нужен

да и fold не нужен если что

Это пример для ResizeArray (много восклицательных знаков), случаев когда можно его осмысленно использовать в F# не так много, и все подобные примеры будут достаточно велики, чтобы уделять им много места в книге про ФП. Про память и проц не понял, при ResizeArray вроде может быть даже поэкономнее. Про fold: Смотря как строить список. // Хотя все равно под капотом будет крутиться его разновидность.

"Про память и проц не понял, при ResizeArray вроде может быть даже поэкономнее." в конце List.ofSeq. весело гоняем по коллекциям

"Про память и проц не понял, при ResizeArray вроде может быть даже поэкономнее." в конце List.ofSeq. весело гоняем по коллекциям

Зато можно сразу список создать на основе IList начиная с конца за один проход.

он и так создается сразу и за 1 проход. профит то в чем?

Как это за один? Сначала получится инверсированный список, который придется сворачивать обратно.

нет

сразу

...

Как?

Ты сначала читаешь.

Соответственно первый окажется в конце.

ты читаешь и сразу ложишь в список. последовательно

И что у тебя будет в Head?

Последний элемент.

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

Пример в студию.

Для начала кода, который за один проход считает у пользователя список.

эх....

let ReadLines() = let rec loop() = [ match Console.ReadLine() with | "." -> () | x -> yield x yield! loop() ] loop()

По твоему под капотом этой штуки не будет инвертированного списка?

а какие причины для его появления?

я ж могу и seq объявить. откуда там инвертирование появится?

Ну может быть такие: что на момент yield x она не сможет его никуда присоединить, т.к. окончания списка еще не существует. Соответственно придется содержать некое скрытое состояние.

В seq тоже самое будет.

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

Ибо это уже адовые штуки которые не должны покидать FSharp.Core.

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

ты про что?

Ну список можно условно представить в виде: { Value : 'a Tail : 'a list } Если сделать Tail изменяемым в рамках класса/либы и т.п., то можно юзать хук, в виде установки Tail после создания списка. В этом случае единоразовый проход вполне возможен.

ты сейчас о List.ofSeq?

О нем в том числе.

Ибо это уже адовые штуки которые не должны покидать FSharp.Core.

ну так оно в нем и живет. в чем проблема то?

разница в примерах только в том что у меня нет ResizeArray

В том, что это оптимизации свойственные компилятору, а не смертным. Если представить список в виде DU, то подобное решение будет недоступно.

Еще раз напоминаю, пример про ResizeArray.

Еще раз напоминаю, пример про ResizeArray.

ну я уже понял что в книге каша. этого примера вообще не должно было быть

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

ну я уже понял что в книге каша. этого примера вообще не должно было быть

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

В том, что это оптимизации свойственные компилятору, а не смертным. Если представить список в виде DU, то подобное решение будет недоступно.

доступно. правда в стек упрется

доступно. правда в стек упрется

Я про невозможность изменения tail говорю.

Я в режиме ридонли до вечера.

Я про невозможность изменения tail говорю.

type A = | X of string * A seq | Null let ReadLines() = let rec loop() = seq { match Console.ReadLine() with | "." -> yield Null | x -> yield X (x, loop()) } loop()

сжирает до ляма записей без проблем

А мне, если честно, без рекурсии больше нравится. Как-то так: seq { while true do yield (System.Console.ReadLine()) } |> Seq.takeWhile ((<>) ".") |> Seq.toList

тоже вариант

type A = | X of string * A seq | Null let ReadLines() = let rec loop() = seq { match Console.ReadLine() with | "." -> yield Null | x -> yield X (x, loop()) } loop()

К чему пример? Не говоря уже о том, что она не материализованна. Вот каноническое определение list: type 'a MyList = | Empty | MyList of head : 'a * tail : 'a MyList В один проход это считать невозможно.

А мне, если честно, без рекурсии больше нравится. Как-то так: seq { while true do yield (System.Console.ReadLine()) } |> Seq.takeWhile ((<>) ".") |> Seq.toList

Есть: Seq.initInfinite (fun _ -> System.Console.ReadLine())

Есть: Seq.initInfinite (fun _ -> System.Console.ReadLine())

Спасибо! Так лучше)

F# Weekly #1, 2018 – F# Applied II #fsharp https://sergeytihon.com/2018/01/07/f-weekly-1-2018-f-applied-ii/

string myFunc() { var x; try { x = badFunc(); } catch { return "Error"; } //much code return goodFunc(x,y,z); } Такое вообще можно в фшарпе написать? Мне пока приходит на ум только весь код после кэтча внутрь трая запихнуть, но это как-то некрасиво, хочется только опасную функцию обернуть

Монадкой можно. Result.map или как его.

Лисп - динамически типизирован

Можно сделать статически типизированный лисп.

А разве на f# есть такие же персистентные коллекции в кложуре из коробки?

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

А чем они лучше system.collection.immutable?

А я что-то там не вижу персистентного вектора, к примеру.