Ну это типа стандартные контролы UI.Next

По сути WebSharper.Forms — надстройка над UI.Next

Или же WebSharper.Piglets для UI.Next

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

Кстати, вот статья про WebSharper.Forms: https://kimsereyblog.blogspot.com.by/2016/03/create-forms-with-websharperforms.html

Этот хорошийчеловек много статей по WebSharper написал.

Artemy точнее даже так, провтыкал параметр, он мне жаловался что возврщает функцию string -> Form, в общем провтыкал один параметр((

msg?)

Да, у меня ошибка типа "я возвращаю тебе string -> Form, а мне нужен Form". Ох..))

За ссылочку спасибо)

Сам изначально про msg забыл и такую же ошибку получал.

Да, где-то на этого чувака натыкался помню, ссылка где-то в Pocket лежит)

Неудивительно. Он чуть ли не единственный, кто про WebSharper пишет.

Особенно из более-менее нового.

Можно как-то переписать более идиоматично (есть два варианта и они оба плохие)? Тут компилятор ругается (warning) на <> if doc.XPathSelectElement("//channel/item") <> null then parseRss doc else if doc.XPathSelectElement("atom:feed//atom:entry", ns) <> null then parseAtom doc else [] Тут ну как-то странно, хотелось бы матчить как not null match doc.XPathSelectElement("//channel/item") with | null -> match doc.XPathSelectElement("atom:feed//atom:entry", ns) with | null -> [] | _ -> parseAtom doc | _ -> parseRss doc

А если с active pattern? Как-то так, например - https://dotnetfiddle.net/RAQzM6

Основная проблема была в <> и тут _ when (XPathSelectElement doc "rss") <> null -> Rss компилятор точно так же ругается Lint: `x <> null`; suggestion: Consider using pattern matching, or if you're using F# 4 then `isNull`.

А вот за ative-pattern и синтаксис “метод this args” спасибо (никогда его раньше не юзал)

а что тогда мешает написать так: let (|Rss|Atom|) doc = match doc with | _ when not <| isNull (XPathSelectElement doc "rss") -> Rss | _ when not <| isNull (XPathSelectElement doc "atom") <> null -> Atom | _ -> failwith "unkonwn document type"

Да ничего, кроме того что изначально 3 строчки, а тут уже 17

Можно и компактней, но уже без активных паттернов let parseDoc' doc = match doc with | _ when not <| isNull (XPathSelectElement doc "rss") -> parseRss doc | _ when not <| isNull (XPathSelectElement doc "atom") -> parseAtom doc | _ -> failwith "unkonwn document type"

4 строчки

isNull x |> not - почему не так?l

исключительно дело вкуса :)

not последним мне не нравится, легко пропустить

Я об начальном варианте:

if doc.XPathSelectElement("//channel/item") |> isNull |> not then parseRss doc else if doc.XPathSelectElement("atom:feed//atom:entry", ns) |> isNull |> not then parseAtom doc else []

Да, тоже вариант. В общем спасибо всем, дальше я как нибудь сам выберу

Хм, а на сиквенсах даже интереснее получается: let tryParse xPath parseFun doc = if (not <| isNull (XPathSelectElement doc xPath)) then Some(parseFun doc) else None let parseDoc''' doc = [ tryParse "rss" parseRss doc; tryParse "atom" parseAtom doc; Some("default value") ] |> Seq.pick id

JetBrains Rider EAP 24 is out: performance optimization, F# Interactive, Unity fixes, better web.config support https://blog.jetbrains.com/dotnet/2017/06/29/rider-eap-24-includes-performance-fixes-f-interactive/

о, репл сделали

Какую бы такую иммутабельную структуру данных использовать для FIFO очереди под Fable?

Какую бы такую иммутабельную структуру данных использовать для FIFO очереди под Fable?

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

двух списков? мне пока пришло в голову сделать цепочку: type Item<'a> = { item: 'a; rest: Queue<'a> } and Queue<'a> = | Empty | Item of Item<'a>

двух списков? мне пока пришло в голову сделать цепочку: type Item<'a> = { item: 'a; rest: Queue<'a> } and Queue<'a> = | Empty | Item of Item<'a>

2 мин.

Есть же Nessos.Streams

Вполне под данную задачу ложатся

под Fable пойдёт?

двух списков? мне пока пришло в голову сделать цепочку: type Item<'a> = { item: 'a; rest: Queue<'a> } and Queue<'a> = | Empty | Item of Item<'a>

Если интересно как это вообще делается, то вот ссыль на курс от Сошникова. Там в начале. https://study.courses.mipt.ru/courses/course-v1:MIPT+f_sharp+autumn_2016/courseware/770f94f54a7849ec8ee5caddbfe29ec4/6759c5c2503e4e0e918ec4c695d7aae9/ // Придется залогиниться.

а, тоже прикольно

Какую бы такую иммутабельную структуру данных использовать для FIFO очереди под Fable?

а System.Collections.Deque нет что ли в Fable?

OMG, какой изврат...

ща гляну

нету

есть только вот это

System.Collections.Generic.List Array System.Collections.Generic.HashSet Set System.Collections.Generic.Dictionary Map

OMG, какой изврат...

какие тогда альтернативы?

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

OMG, какой изврат...

Кроме того, что он не имеет нормальной обертки (что для учебного курса совершенно нормально) в чем извращенность?

module Fable.EdIlyin.Queue type 'a queue = | Queue of 'a list * 'a list let empty = Queue ([], []) let singleton item = Queue ([item], []) let push (Queue (l, r)) item = Queue (l, item :: r) let ofList list = Queue (list, []) let rec peek (Queue (l, r)) = match l with | [] -> match r with | [] -> None | _ -> List.rev r |> ofList |> peek | h::_ -> Some h let rec pull (Queue (l, r)) = match l with | [] -> match r with | [] -> None | _ -> List.rev r |> ofList |> pull | h::t -> Some (h, t) let length (Queue (l, r)) = List.length l + List.length r

Какую бы такую иммутабельную структуру данных использовать для FIFO очереди под Fable?

Тот же вопрос был про sorted list. Выше были примеры реализации

Тот же вопрос был про sorted list. Выше были примеры реализации

разве это одно и тоже?

System.Collections.Generic.List Array System.Collections.Generic.HashSet Set System.Collections.Generic.Dictionary Map

в таком случае Array/. Deque более оптимизирована для fifo данных чем Array, ни каких других бонусов не даёт

разве это одно и тоже?

Нет, но близко)

Кроме того, что он не имеет нормальной обертки (что для учебного курса совершенно нормально) в чем извращенность?

в упор не вижу пойнт бесполезных на практике "учебных" примеров. Смысл deque не в том, чтобы урезать функциональность обычного массива, а в том, чтобы оптимизировать структуру данных коллекции для специфического апи fifo. В примере ни какой оптимизации нет и близко

в упор не вижу пойнт бесполезных на практике "учебных" примеров. Смысл deque не в том, чтобы урезать функциональность обычного массива, а в том, чтобы оптимизировать структуру данных коллекции для специфического апи fifo. В примере ни какой оптимизации нет и близко

Она там вполне оптимизированна, при этом иммутабельна, как и просилось.

она ни фига не оптимизирована, потому что List.rev. Такое прокатывает только в hello world. Иммутабельность ради иммутабельности - это и есть изврат.

она ни фига не оптимизирована, потому что List.rev. Такое прокатывает только в hello world. Иммутабельность ради иммутабельности - это и есть изврат.

Каждый элемент подпадает под List.rev лишь однажды. Чтобы нагадить этим, надо будет хорошо постараться. Тем более мне неизвестна причина по которой требуется иммутабельность. Так что вопрос о ее целесообразности надо ставить отдельно.

Возможно с иммутабельностью я погорячился. Просто хочеться чего-то в функциональном стиле

== Каждый элемент подпадает под List.rev лишь однажды ну то есть колекция N раз реверсируется. Классная оптимизация ,ага. == Тем более мне неизвестна причина по которой требуется иммутабельность Вообще то апи определяет выбор структур данных, а не на оборот. Иногда требуется иммутабельное апи. Из этого ни разу не следует, что структуры данных обязаны быть иммутабельными. Если конечно обойтись без фанатизма.

== Каждый элемент подпадает под List.rev лишь однажды ну то есть колекция N раз реверсируется. Классная оптимизация ,ага. == Тем более мне неизвестна причина по которой требуется иммутабельность Вообще то апи определяет выбор структур данных, а не на оборот. Иногда требуется иммутабельное апи. Из этого ни разу не следует, что структуры данных обязаны быть иммутабельными. Если конечно обойтись без фанатизма.

Если она реверсировалась N раз, значит в нее N раз добавили и изъяли элемент. Какова сложность List.rev на списке в 1 элемент? Вот человек сейчас будет пилить убер машину для Queue на массивах и деревьях лишь потому, что за List.rev это ужас и гулаг? Что за бред? Можно подумать у классического мутабельного Queue нет своих косяков. Давайте устроем плач по копированию массива при переполнении.

Если она реверсировалась N раз, значит в нее N раз добавили и изъяли элемент. Какова сложность List.rev на списке в 1 элемент? Вот человек сейчас будет пилить убер машину для Queue на массивах и деревьях лишь потому, что за List.rev это ужас и гулаг? Что за бред? Можно подумать у классического мутабельного Queue нет своих косяков. Давайте устроем плач по копированию массива при переполнении.

== Какова сложность List.rev на списке в 1 элемент? то есть данная очередь по перформансу прекрасно подходит для хелуворда, где количество элементов в колекции мизерное и выбор структуры данных не имеет ни какого значения, с чем ни кто и не спорит ? == убер машину для Queue на массивах и деревьях человек возьмёт array и будет счастлив, поскольку вся функциональность queue в нём есть и ничего велосипедить не надо ? == Давайте устроем плач по копированию массива при переполнении. Нет, давайте лучше притягивать за уши функциональшину туда, где она на фиг не впёрлась!

Возможно с иммутабельностью я погорячился. Просто хочеться чего-то в функциональном стиле

а каким образом у тебя будет хранится очередь - в мутабельной переменной или изолированном стейт-контейнере?

== Какова сложность List.rev на списке в 1 элемент? то есть данная очередь по перформансу прекрасно подходит для хелуворда, где количество элементов в колекции мизерное и выбор структуры данных не имеет ни какого значения, с чем ни кто и не спорит ? == убер машину для Queue на массивах и деревьях человек возьмёт array и будет счастлив, поскольку вся функциональность queue в нём есть и ничего велосипедить не надо ? == Давайте устроем плач по копированию массива при переполнении. Нет, давайте лучше притягивать за уши функциональшину туда, где она на фиг не впёрлась!

> то есть данная очередь по перформансу прекрасно подходит для хелуворда, где количество элементов в колекции мизерное и выбор структуры данных не имеет ни какого значения, с чем ни кто и не спорит ? Я пояснил, что ты неправильно понимаешь момент выполнения List.rev. > человек возьмёт array и будет счастлив, поскольку вся функциональность queue в нём есть и ничего велосипедить не надо ? > Нет, давайте лучше притягивать за уши функциональшину туда, где она на фиг не впёрлась! Я имею ввиду сложность написания иммутабельной структуры данных на мутабельных коллекциях внутри. Если нужна иммутабельность, то игнорирование списков - есть жутчайший велосипед. А то что в случае изменяемых коллекций можно взять готовое, никто не оспаривает.

а каким образом у тебя будет хранится очередь - в мутабельной переменной или изолированном стейт-контейнере?

очередь у меня храниться в иммутабл стейте

а иммутабл стейт - это что в данном случае?

это рекорд

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

в MailboxProcessor'е

module Fable.EdIlyin.Throttle open System type Model = { quantity: int millisecond: int queue: int Queue.queue } and Msg<'a> = | Die | Fetch of (unit -> 'a) * AsyncReplyChannel<'a> let execute func (channel: AsyncReplyChannel<_>) model = do func () |> channel.Reply { model with queue = Queue.push model.queue DateTime.Now.Millisecond } |> Debug.log "executed" let fetch model func channel = async { do! match Queue.pull model.queue, Queue.length model.queue with | None, _ -> async.Return () | _, l when l < model.quantity -> async.Return () | _, l when l >= model.quantity -> async.Return () | Some (was, tail), _ -> DateTime.Now.Millisecond - was |> (-) model.millisecond |> Async.Sleep return execute func channel model } let body model (agent: MailboxProcessor<_>) = let rec loop state = async { let! msg = agent.Receive () return! match msg with | Die -> async.Return () | Fetch (func, channel) -> async { let! newModel = fetch state func channel return! loop newModel } } loop model let agent quantity millisecond = body { quantity = quantity millisecond = millisecond queue = Queue.empty } |> MailboxProcessor.Start

в MailboxProcessor'е

то есть ни каких особых причин делать очередь иммутабельной нет. можно с таким же успехом хранить стейт в массиве и апдейтить его в цикле while

@edvail Большие куски кода, пожалуйста, выкладывайте в пастебин или gists.

@edvail Большие куски кода, пожалуйста, выкладывайте в пастебин или gists.

понял

понял

Спасибо!

то есть ни каких особых причин делать очередь иммутабельной нет. можно с таким же успехом хранить стейт в массиве и апдейтить его в цикле while

нету, кроме того, что у меня боязнь

не очкуй!

а я очкую

:)

> то есть данная очередь по перформансу прекрасно подходит для хелуворда, где количество элементов в колекции мизерное и выбор структуры данных не имеет ни какого значения, с чем ни кто и не спорит ? Я пояснил, что ты неправильно понимаешь момент выполнения List.rev. > человек возьмёт array и будет счастлив, поскольку вся функциональность queue в нём есть и ничего велосипедить не надо ? > Нет, давайте лучше притягивать за уши функциональшину туда, где она на фиг не впёрлась! Я имею ввиду сложность написания иммутабельной структуры данных на мутабельных коллекциях внутри. Если нужна иммутабельность, то игнорирование списков - есть жутчайший велосипед. А то что в случае изменяемых коллекций можно взять готовое, никто не оспаривает.

== Я пояснил, что ты неправильно понимаешь момент выполнения List.rev всё зависит от сценария использования == сложность написания иммутабельной структуры данных на мутабельных коллекциях внутри а зачем это нужно? Если апи иммутабельное, то какая половая разница на каких структурах данных оно реализовано? == А то что в случае изменяемых коллекций можно взять готовое, никто не оспаривает. вопрос в том зачем вообще брать сложное, не стандартное и не эффективное при наличии простого, стандартного и эффективного

а я очкую

что именно пугает?

Все никак не соберусь Окасаки прочитать про функциональные типы данных и алгоритмы.Мне кажется, проблема с очередью там должна решаться

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

точнее - графы

более или менее хорош вектор в виде дерева хэшей в clojure, но в F# к сожалению ничего подобного нет

Есть ли в F# готовая такая функция: (fun x y -> x, y) ?

что именно пугает?

Я себя как программиста боюсь. Я опять чтонить сделаю так, что меняя один объект будут меняться ещё куча других. У меня мозг маленький - я всё упомнить не могу и не хочу :) А потом это всё траблшутить для меня убийственно. Или когда синхронизация данных в две стороны - это тоже меня вгоняло в депрессию. Хочу что бы данные шли только в одном направлении и что бы компилятор меня контроллировал

более или менее хорош вектор в виде дерева хэшей в clojure, но в F# к сожалению ничего подобного нет

Persistent vector?

@angmarr https://github.com/fable-compiler/fable-react_native-demo/pull/20#issuecomment-312308422

ладно, раз уж я пишу под Fable то для очереди буду использовать Emit javascript var queue = []; queue.push(2); // queue is now [2] queue.push(5); // queue is now [2, 5] var i = queue.shift(); // queue is now [5]

== Я пояснил, что ты неправильно понимаешь момент выполнения List.rev всё зависит от сценария использования == сложность написания иммутабельной структуры данных на мутабельных коллекциях внутри а зачем это нужно? Если апи иммутабельное, то какая половая разница на каких структурах данных оно реализовано? == А то что в случае изменяемых коллекций можно взять готовое, никто не оспаривает. вопрос в том зачем вообще брать сложное, не стандартное и не эффективное при наличии простого, стандартного и эффективного

Последний раз пишу. > всё зависит от сценария использования List.rev суммарно обработает максимум N элементов. В List.map например гарантированно List.rev вызовится на всех N. > а зачем это нужно? Если апи иммутабельное, то какая половая разница на каких структурах данных оно реализовано? Я так понимаю, что опыта реализации сего чуда у автора этих строк не было. Это банально больно, если не иметь соответствующей квалификации. > вопрос в том зачем вообще брать сложное, не стандартное и не эффективное при наличии простого, стандартного и эффективного Такое можно было сказать, лишь напрочь потеряв весь контекст диалога. > Проблема с очередью в ФП не решаеттся от слова вообще. Очередь (как и стек) в ФП решаются прекрасно. Вообще, мне не понятно, реализацию очереди двумя способами: через кольцо и два стека проходят на 1-2 курсе профильных специальностей (это если в школе не было программирования). Реализация на двух списках является клоном 2-ух стекового варианта. Я что-то не припомню, чтобы мои преподы с пеной у рта доказывали, что стеки гавно, массив форевер. На экзе дрючили оба варианта.

Есть ли в F# готовая такая функция: (fun x y -> x, y) ?

Насколько я помню нет. От таких фций в стандартной библиотеке отказались.

Persistent vector?

ага. http://hypirion.com/musings/understanding-persistent-vector-pt-1

ага. http://hypirion.com/musings/understanding-persistent-vector-pt-1

А persistent vector в FSharpX иначе реализован?