оч красиво

Да по закону Мура все что может случится случается. Вот этот пример всегда смущал что тот же Scott Wlaschin его приводит как крутую вещь в F# но везде и всегда показывает только с двумя значениями. А в реальной жизни далеко не два и даже не три значения приходится хранить как информацию о клиенте

одностроник не нужен , но мне кажется что let rec fib = function | 0 | 1 -> 1 | n -> fib (n-1) + fib (n-2) выглядит лучше

есть варик с бесконечной последовательностью)

let t = Seq.unfold (fun (u,v) -> Some(u,(u+v,u))) (1I,1I) let fibI = t |> Seq.filter(fun x->x.ToString().Length=4) |> Seq.head

например)

let t = Seq.unfold (fun (u,v) -> Some(u,(u+v,u))) (1I,1I) let fibI = t |> Seq.filter(fun x->x.ToString().Length=4) |> Seq.head

уточним задачу, нужно показать "лаконичный код" )

поэтмоу хоть код изначальный и гораздо лушче, но он не тот фибоначи который все знают с hello world'a )

поэтмоу хоть код изначальный и гораздо лушче, но он не тот фибоначи который все знают с hello world'a )

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

let rec fib n a b = match n with | 0 -> a | 1 -> b | _ -> fib (n - 1) b (a + b) как можно сократить?

это?

это?

ну только без 0

ну только без 0

точно вот что смущало, до 0 и не дойдет же.

но 0 могут подать на n

но можно | 0 | 1 ->

а, не) низя.

да можно сделать на сиквенсах опять же

можно через анфолд

толку-то в этом? F# операции над Seq никак не оптимизирует. и привет новые енумераторы почем зря

можно через анфолд

а онфолд - это каждое значение обернуть в option, который класс. то есть на каждое число - объект-компаньон в мусоре

так себе однострочники)

Просили лаконичный код...

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

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

Да по закону Мура все что может случится случается. Вот этот пример всегда смущал что тот же Scott Wlaschin его приводит как крутую вещь в F# но везде и всегда показывает только с двумя значениями. А в реальной жизни далеко не два и даже не три значения приходится хранить как информацию о клиенте

А что за случай, когда обязательно вводить тип-произведение вида «каждый кейс с каждым»? Как на других языках это решается? Может быть, тут вообще нужно другое решение? Давайте обсудим :)

А что за случай, когда обязательно вводить тип-произведение вида «каждый кейс с каждым»? Как на других языках это решается? Может быть, тут вообще нужно другое решение? Давайте обсудим :)

ну собственно именно об этом и был мой вопрос. Почему делается тип где перечислается выбор из трех значений где третий это комбинация двух первых?

С тем, что пример немного искусственный, я согласен.

в императивном стиле это было бы что то вроде модели предметной области который выбрасывал бы исключение в негативных сценариях

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

в императивном стиле это было бы что то вроде модели предметной области который выбрасывал бы исключение в негативных сценариях

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

да идею то я понял - но что если мне нужно теперь еще третье значение добавить?

как тогда разрулить это?

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

как вариант можно сделать какой нибудь Builder который собирает модель

и один метод Validate который проверяет что хотя бы одно значение задано

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

вот небольщой трешак набросал в многословном императивном стиле:

public class BaseModel : Dictionary<string, object> { protected void SetValue<T>(string key, T value) { this[key] = value; } protected T GetValue<T>(string key) { if (this.ContainsKey(key)) { return (T)this[key]; } return default(T); } }

ну и собственно сама модель:

public class ContactModel : BaseModel { public string Email { get { return GetValue<string>("email"); } set { SetValue("email", value); } } public string Phone { get { return GetValue<string>("phone"); } set { SetValue("phone",value);} } public bool Validate()=>this.Any(); }

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

конечно многословно но можно AOP либу (Fody) замутить для того что бы намного меньше слов было и осталось что то вроде Email {get; set;}

ну это если совсем заморочится

как тогда разрулить это?

Агрегат.

type CaseOfDu = { Id: string; Phone: string } type Du = CaseOfDu of CaseOfDu

Это если в "строчке" больше двух трёх-значений появляется.

@SherievAkhmed Задача в том, чтобы избежать полностью незаполненный ContactInfo?

А кто мне пример скидывал из Suave?

С конфигом)

@SherievAkhmed @fvnever Кажется, есть у меня решение этой задачи. Доберусь до работы -- проверю.

https://github.com/SuaveIO/suave/blob/f0831e3ed00c611f78a04ac30d3a065403470274/src/Suave/Web.fs#L69 вот как suaveio работает с кучей значений. и вот как это выглядит в коде startWebServer defaultConfig (Successful.OK "Hello World!")

Не, что-то не то)

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

Вчера же было!

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

Не вариант

Не могли блин нормальные опциональные аргументы завезти

Не могли блин нормальные опциональные аргументы завезти

А не думал вообще замутить билдеры на своем DSL?

А не думал вообще замутить билдеры на своем DSL?

И как это должно выглядеть?

И как это должно выглядеть?

приведи пример запроса

Telegram.getUpdates offset limit timeout msgFilter

Все параметры опциональные

@SherievAkhmed @fvnever Добрался до работы. Мне пришло одно "почти" решение в голову. Вместо комбинирования различных кейсов в DU, мы можем использовать non-empty list. Это избавит нас от невалидного пустого состояния.

Почему это "почти" решение? Потому что в списке может информация дублироваться.

Не могли блин нормальные опциональные аргументы завезти

С опциональными аргументами в языке с каррированием всё очень сложно. И поэтому они есть, но только в местах, в которых каррирование запрещено: в объявлениях методов и конструкторов. См. https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/parameters-and-arguments#optional-parameters

@SherievAkhmed @fvnever Добрался до работы. Мне пришло одно "почти" решение в голову. Вместо комбинирования различных кейсов в DU, мы можем использовать non-empty list. Это избавит нас от невалидного пустого состояния.

А ты понимаешь, какую задачу мы вообще решаем? Я вот подумал над решением и понял, что задачи я не понимаю %)

С опциональными аргументами в языке с каррированием всё очень сложно. И поэтому они есть, но только в местах, в которых каррирование запрещено: в объявлениях методов и конструкторов. См. https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/parameters-and-arguments#optional-parameters

Ну хотя бы в записях сделали

Там же ломать нечего

@fvnever Мы хотим make illegal state unrepresentable, как обычно.

А какое состояние там нелегальное?

ERROR: S client not available

Вроде бы любое легальное, не?

В оригинальном примере illegal state -- это отсутствие email и post.

Или одно задано, или другое, или оба.

А, ок.

Да, хорошо.

Можно придумать пример побольше.

Пусть у нас система оповещает пользователя в соцсетях.

Их может быть много.

В DU не скомбинируешь все варианты.

@fvnever https://hastebin.com/cutepifota.fs

Синтаксически выглядит не очень красиво.

cutepifota

Мне нравятся URL на хастебине :)

Синтаксически выглядит не очень красиво.

И в рантайме будет очень тормозить :(

Прям очень-очень? :)

Ну, как связный список.

Можно побыстрее написать.

Не суть же.

:(

Согласен, да, можно сделать чтоб не тормозило. Обмазать всё через struct и массив вместо списка жахнуть.

Я думаю, как это синтаксически менее мерзко сделать.

Обязательно нужно active patterns навернуть, чтобы из Accounts нужную информацию вытаскивать.

@fvnever А еще можно не париться. :)

Преждевременная деоптимизация — это очень вредно.

Так же вредно, как и преждевременная оптимизация.

@fvnever Я про задачу в общем.

Хорошо бы всегда неправильное состояние делать непредставимым.

Но еще бы читабельность сохранить при этом.

@fvnever Поэтому пример с Email и Post можно всем показывать и радоваться, а вот то, что я сочинил лучше закопать.

Как мне кажется.

@fvnever @SherievAkhmed Вечером сделаю полноценный пример.

http://fsharplang.ru до сих пор не работает