@neftedollar а кто сказал что перформанс не имеет значение для гуя? меня лично как-то напрягают тормозные WPF приложения, может я какой-то не правильный) но гораздо приятнее когда fps большой. Вот телеграм-клиент например у меня 15 МБ (qt, unsafe) мозга. А хелуворд на WPF, safe почему то 100 МБ. Че та я за unsafe

Да пусть он этот unsafe использует внутри. А разработчику пусть его не показывает.

Странно. for внутри seq { } тоже возвращает JToken вместо KeyValuePair

если просто очень хочется использовать seq, то так работает: jObject :> IEnumerable<KeyValuePair<string,JToken>> |> Seq.iter (fun f -> printf "%s" f.Key

@neftedollar @ruzzke_mir Давайте завязывать с UI оффтопом.

Согласен. Тутор f# ничего и нет

@Dolfik Суть в том, что компилятор не может правильно выбрать интерфейс, который будет использоваться для перечисления JObject. (jObject :> seq<KeyValuePair<string, JToken>>) |> Seq.iter (fun f -> printf "%s" (f.Key)) Заведи себе функцию. let toSeq d = d |> Seq.map (fun (KeyValue(k,v)) -> (k,v))

но вообще похоже на баг

@Dolfik Суть в том, что компилятор не может правильно выбрать интерфейс, который будет использоваться для перечисления JObject. (jObject :> seq<KeyValuePair<string, JToken>>) |> Seq.iter (fun f -> printf "%s" (f.Key)) Заведи себе функцию. let toSeq d = d |> Seq.map (fun (KeyValue(k,v)) -> (k,v))

если бы вывод типов сбоил, то по идее такое должо было работать jObject |> Seq.iter (fun (f:KeyValuePair<string,JToken>) -> printf "%s" f.Key)

Он не сбоит, просто выводит ближайший тип.

ну после прямой подсказки (fun (f:KeyValuePair<string,JToken>) данных уже хватает чтобы взять нужный?

+ вопрос - почему выводит по-разному в seq и for?

Я не уверен. В Seq функциях цепочка вызовов с получением одного IEnumerable и оборачиванием в другой.

Надо смотреть конкретно, что там происходит.

@akhanteev Почему выводит по-разному, конечно, хороший вопрос. :)

Dev Привет!

прив! я пока присмотреться, прислушаться.. может когда чего спросить

f# только начал грызть

@akhanteev Логично предположить, что for просто вызывает GetEnumerator у JObject.

А при вызове, например, Seq.iter наш JObject уже интерпретируется как seq<'T>, который выводится как ближайший seq<JToken>.

И уже для этого типа получают перечисление.

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

@akhanteev @Dolfik ^

Занятно, но если не использовать пайп, то уже тип функции будет определять тип перечисления. Seq.iter (fun (f:KeyValuePair<string, JToken>) -> printf "%s" (f.Key)) jObject

Наговнокодил сериализатор DU :D

Боюсь код заливать в гит теперь

@gsomix GetEnumerator кстати выдает kvp: printfn "%A" (jObject.GetEnumerator().Current.GetType().Name)

@akhanteev Все верно.

И у него есть ещё один, от JContainer, который реализует IList<JToken>.

@Dolfik А for внутри seq это отдельная история. :)

Всего тестов: 7. Пройдено: 7. Не пройдено: 0. Пропущено: 0.

ммм

Зацените конвертер: https://github.com/Dolfik1/Funogram/blob/master/Funogram/JsonConverters.fs

Который type DuConverter() =

На ввод дается геном ДНК, строка например "aaaabbсaa" нужно преобразовать этот текст в другую строку типа "a4b2с1a2"

let zip items = let folder state item = match state with | (current, count) :: t when current = item -> (current, count + 1) :: t | _ -> (item, 1) :: state items |> Seq.fold folder [] |> List.rev

ну, кажется с seq / for ситуация прояснилась.. внутри seq.fs все работает на кастах к IEnumerable / IEnumerator, а в JToken они эксплицитно реализованы

let jObject = JObject(JProperty("1","test")) for k in (upcast jObject : IEnumerable<_>) do printf "%s" (k.GetType().Name) for k in jObject do printf "%s" (k.GetType().Name)

@akhanteev Да, это так.

Кстати, за этими разговорами о множественной реализации IEnumerable<'T>, я вспомнил про вот такой RFC. https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1031-Allow%20implementing%20the%20same%20interface%20at%20different%20generic%20instantiations%20in%20the%20same%20type.md

> Natallia Dzenisenka - Parallel Programming with F# and Hopac

Надо не забыть потом это видео с dotnetfringe посмотреть. :)

Кстати, за этими разговорами о множественной реализации IEnumerable<'T>, я вспомнил про вот такой RFC. https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1031-Allow%20implementing%20the%20same%20interface%20at%20different%20generic%20instantiations%20in%20the%20same%20type.md

О, не знал, что оно так. Даже попробовал. Действительно нельзя так в F#.

Я думаю, это вышло по недосмотру. Просто никому в голову не пришло, что это придётся отдельно обрабатывать :)

В сообщении об ошибке, кстати, пишет, что "не поддерживается в текущей версии F#"

у меня вчера что-то похожее вроде работало локально (на F# 4.1), и не работало в dotnetfiddle (там, похоже F# 4)

Пожалуйся им, пускай обновляют.

Artemy Есть ещё одна штука, которая не поддерживается. https://stackoverflow.com/questions/3857474/how-to-constrain-one-type-parameter-by-another

у меня вчера что-то похожее вроде работало локально (на F# 4.1), и не работало в dotnetfiddle (там, похоже F# 4)

Имеются в виду интерфейсы с разными параметрами?

да много где еще, похоже, F# 4.. в Azure Functions, например. причем по крайней мере в локальные тулы он зашит намертво

Имеются в виду интерфейсы с разными параметрами?

да

Просто у меня F# 4.1. И не компилится.

вечером посмотрю)

Так RFC ещё не реализовали.

Ну так да

Artemy Есть ещё одна штука, которая не поддерживается. https://stackoverflow.com/questions/3857474/how-to-constrain-one-type-parameter-by-another

По-моему, такого варианта параметров мне ещё не приходилось встречать.)

Просто у меня F# 4.1. И не компилится.

Возможно, я пробовал немного по-другому: open System.Collections open System.Collections.Generic type T () = interface IEnumerable with member x.GetEnumerator () : IEnumerator = failwith "not impl" interface IEnumerable<string> with member x.GetEnumerator () : IEnumerator<string> = failwith "not impl" type T' () = inherit T () interface IEnumerable<int> with member x.GetEnumerator () : IEnumerator<int> = failwith "not impl"

вот такая штука в dotnetfiddle не работает тоже

Это не совсем то, но интерес тоже представляет.

> The existing workaround is to add one extra hierarchy level per generic instantiation.

Ну, да.

читаю я тут статейку и у меня вопрос, а что у нас является аналогом хаскельского fmap ? https://habrahabr.ru/post/183150/

flatMap в смысле?

нууу, я не знаю, я по этому и спрашиваю =)

читаю я тут статейку и у меня вопрос, а что у нас является аналогом хаскельского fmap ? https://habrahabr.ru/post/183150/

В F# нету обобщённого fmap. Но есть List.map, Option.map, Choice.map и т.д.

Хм, как тогда понимать статью относительно F#? 0_о

Ну в стандартной библиотеке F# нету функторов, аппликативных функторов и т.п. непосредственно как типов.

Так что эту статью следует понимать чисто как общие понятия, принятые в ФП.

черт - сложно.

Вовсе нет

я хотел ручками потренироваться, мне так проще.

я пока руками не потрогаю - не понимаю.

Короче, в f# нету того, что называется HKT- Higher Kind Types, поэтому обощенный fmap нельзя написать

Просто та же функция map может делать что угодно гипотетически. Но все понимают, чего от неё ждать лишь потому ,что есть вот такое принятое понятие "функтор" с определённым оговорённым ожидаемым поведением.

Вообще, функтор в F# можно описать, как тут, например: https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/generics/statically-resolved-type-parameters

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

хм

fmap есть в FSharpPlus, смотрите: http://gusty.github.io/FSharpPlus/abstraction-functor.html

И вообще, если кто не знал (я не знал), FSharpControl теперь смержилось в FSharpPlus.

Ага

Один раз использовал FSharpPlus, чтобы использовать обобщённый оператор >>=.

http://gusty.github.io/FSharpPlus/abstractions.html — вот эта схемка любителям теорката придётся по душе.

@the_RAMZAY ↑↑

@fvnever вижу =)

это типо войдёт в стандарт?

Нет. Это просто библиотека.

(дальше личное мнение) Я считаю, что стандарт можно и не загружать этой теоретической хуергой.

Если это можно реализовать в качестве библиотеки — очень хорошо.

Самая годная реализация всех этих штук получится в Haskell

На F# это пока костыли, как я понимаю.

На F# это пока костыли, как я понимаю.

Вполне такие практичные костыли. Система типов довольно ограниченная и HKT нет, но если очень хочется — то жить можно.

Я, например, вообще сейчас вручную наворачиваю у себя в коде тайпклассы из C#-пропозала (разворачивая их в генерики со структурами), и горя не знаю :)

Ну то, как это сделано в FSharpPlus (а как именно - я пока не знаю), сделать как обучающий пример — довольно жестко.

С этим согласен.

На F# это пока костыли, как я понимаю.

Да, в f# есть более привычные инструменты

А человек хочет функторы и т.п. саморучно реализовать, чтобы разобраться. Тут, честно говоря, без понятия, что посоветовать. У самого опыта почти нет.

Я в F# это даже и не пробовал описывать.

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

@the_RAMZAY На практике с таким редко сталкиваются.

Вполне возможно

Я, например, вообще сейчас вручную наворачиваю у себя в коде тайпклассы из C#-пропозала (разворачивая их в генерики со структурами), и горя не знаю :)

А можно простой пример как это выглядит?