@gsomix понятия не имею. но раз в языке этого нет ,а звёзд на гитхабе все 70, то что--то с Fsharpx нет так

@gsomix понятия не имею. но раз в языке этого нет ,а звёзд на гитхабе все 70, то что--то с Fsharpx нет так

SMM плохой наверно

SMM плохой наверно

не смеши :))

@gsomix понятия не имею. но раз в языке этого нет ,а звёзд на гитхабе все 70, то что--то с Fsharpx нет так

В языке и стандартной библиотеке много чего нет.

Надо код смотреть и бенчмарки.

В языке и стандартной библиотеке много чего нет.

это не есть гут.

Надо код смотреть и бенчмарки.

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

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

В электричку как залезу,попробую код расписать

Только без equatable не взлетит

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

Какую-нибудь кучу?

Да не,по факту кортеж из двух ссылок

Ну и счетчик объектов

== List.rev суммарно обработает максимум N элементов. иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? == В List.map например гарантированно List.rev вызовится на всех N. и при чём тут List.map? == Очередь (как и стек) в ФП решаются прекрасно если признаком прерасного являются костыли и дополнительный оверхэд, то да == Я так понимаю, что опыта реализации сего чуда у автора этих строк не было. let a = ResizeArray<int>() // очередь a.Insert(0,1) // put let x = a.[a.Count-1] // pop a.RemoveAt(a.Count-1) == Это банально больно, если не иметь соответствующей квалификации это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. == Я что-то не припомню, чтобы мои преподы с пеной у рта доказывали, что стеки гавно, массив форевер Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден ))

== List.rev суммарно обработает максимум N элементов. иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? == В List.map например гарантированно List.rev вызовится на всех N. и при чём тут List.map? == Очередь (как и стек) в ФП решаются прекрасно если признаком прерасного являются костыли и дополнительный оверхэд, то да == Я так понимаю, что опыта реализации сего чуда у автора этих строк не было. let a = ResizeArray<int>() // очередь a.Insert(0,1) // put let x = a.[a.Count-1] // pop a.RemoveAt(a.Count-1) == Это банально больно, если не иметь соответствующей квалификации это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. == Я что-то не припомню, чтобы мои преподы с пеной у рта доказывали, что стеки гавно, массив форевер Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден ))

Увидев мое желание прекратить беседу, решил полную чушь протолкнуть? > иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? Т.е. то что на массивах добавление элемента имеет O(1..N) тебя не смущает? Оптимизированность в том, что для каждого элемента это происходит не более одного раза в отличии от реализации на массиве, следовательно полное прохождение элемента от начала до конца будет условно стоить O(2), т.е. O(1). > и при чём тут List.map? Притом, что при такой трактовке как у тебя им вообще нельзя пользоваться. Ибо там тоже есть List.rev с суммарным объемом в N, т.е. "оверхэд". > если признаком прерасного являются костыли и дополнительный оверхэд, то да Костылей ты все еще не показал. Дополнительного оверхэда, кроме, о ужас!, хранения дополнительных ссылок, я пока не увидел. > let a = ResizeArray<int?) // очередь > a.Insert(0,1) // put > let x = a.[a.Count-1] // pop > a.RemoveAt(a.Count-1) Ты вообще понял, что написал? Ты в курсе что твой a.Insert(0,1) имеет сложность O(N)? O(N), а не O(1..N)! Это не считая того, что это нихера не иммутабельная структура. > это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. Ты умудрился запутаться в вышеприведенном коде. А ты еще ничего иммутабельного не сделал. > Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден )) В данный момент "патологический кретином" и "идиотом" выставляешь себя ты. То что динамический массив можно юзать как стек и очередь нихрена не значит, что он для этого будет эффективен. Возможно, ты путаешь динамический массив с Deque (хотя почему я должен думать за тебя, если ты даже не потрудился нормально прочитать мои замечания?), которую можно юзать вышеуказанным способом, и которая часто реализуется на динамическом массиве. 1. Динамический массив имеет: O(1..N) за вставку в конец, O(N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(N) за удаление в начале. 2. Двунаправленная очередь на динамическом массиве: O(1..N) за вставку в конец, O(1..N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(1) за удаление в начале (O(1..N) если экономим память). 3. Стек на основе массива: O(1..N) за вставку, O(1) за извлечени. 4. Стек на основе списка: O(1) за вставку, О(1) за извлечение. 5. Очередь на основе массива: O(1..N) за вставку, O(1) за извлечение. 6. Очередь на основе двух стеков (на основе списков): O(1) за вставку, O(1..N) за извлечение, причем из-за "одноразовости" переноса стека для большинства задач считается как O(1). Здесь основная претензия - это размазанность структуры данных по куче, что ввиду ссылочных данных уже не так критично. Я не знаю, что за универ тебя выпустил, и что за работодатель тебя нанял, но такое незнание матчасти в сочетании с непомерным гонором должны были вывести тебя в маргиналы еще во времена школьной скамьи. Продолжать дальнейшее обсуждение технической составляющей не буду, ибо с моей точки зрения в данном вопросе ты профан и тебе надо идти на викиконспекты зубрить теорию. Однако, терпеть незаслуженные оскорбления в адрес уважаемых мною людей не собираюсь. У меня есть претензии к современности познаний моих преподов (по прикладным предметам), но уж тот материал, что они дают, они знают на достаточном уровне (разумеется есть исключения).

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

Вроде реализован по тем статьям.

Увидев мое желание прекратить беседу, решил полную чушь протолкнуть? > иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? Т.е. то что на массивах добавление элемента имеет O(1..N) тебя не смущает? Оптимизированность в том, что для каждого элемента это происходит не более одного раза в отличии от реализации на массиве, следовательно полное прохождение элемента от начала до конца будет условно стоить O(2), т.е. O(1). > и при чём тут List.map? Притом, что при такой трактовке как у тебя им вообще нельзя пользоваться. Ибо там тоже есть List.rev с суммарным объемом в N, т.е. "оверхэд". > если признаком прерасного являются костыли и дополнительный оверхэд, то да Костылей ты все еще не показал. Дополнительного оверхэда, кроме, о ужас!, хранения дополнительных ссылок, я пока не увидел. > let a = ResizeArray<int?) // очередь > a.Insert(0,1) // put > let x = a.[a.Count-1] // pop > a.RemoveAt(a.Count-1) Ты вообще понял, что написал? Ты в курсе что твой a.Insert(0,1) имеет сложность O(N)? O(N), а не O(1..N)! Это не считая того, что это нихера не иммутабельная структура. > это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. Ты умудрился запутаться в вышеприведенном коде. А ты еще ничего иммутабельного не сделал. > Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден )) В данный момент "патологический кретином" и "идиотом" выставляешь себя ты. То что динамический массив можно юзать как стек и очередь нихрена не значит, что он для этого будет эффективен. Возможно, ты путаешь динамический массив с Deque (хотя почему я должен думать за тебя, если ты даже не потрудился нормально прочитать мои замечания?), которую можно юзать вышеуказанным способом, и которая часто реализуется на динамическом массиве. 1. Динамический массив имеет: O(1..N) за вставку в конец, O(N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(N) за удаление в начале. 2. Двунаправленная очередь на динамическом массиве: O(1..N) за вставку в конец, O(1..N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(1) за удаление в начале (O(1..N) если экономим память). 3. Стек на основе массива: O(1..N) за вставку, O(1) за извлечени. 4. Стек на основе списка: O(1) за вставку, О(1) за извлечение. 5. Очередь на основе массива: O(1..N) за вставку, O(1) за извлечение. 6. Очередь на основе двух стеков (на основе списков): O(1) за вставку, O(1..N) за извлечение, причем из-за "одноразовости" переноса стека для большинства задач считается как O(1). Здесь основная претензия - это размазанность структуры данных по куче, что ввиду ссылочных данных уже не так критично. Я не знаю, что за универ тебя выпустил, и что за работодатель тебя нанял, но такое незнание матчасти в сочетании с непомерным гонором должны были вывести тебя в маргиналы еще во времена школьной скамьи. Продолжать дальнейшее обсуждение технической составляющей не буду, ибо с моей точки зрения в данном вопросе ты профан и тебе надо идти на викиконспекты зубрить теорию. Однако, терпеть незаслуженные оскорбления в адрес уважаемых мною людей не собираюсь. У меня есть претензии к современности познаний моих преподов (по прикладным предметам), но уж тот материал, что они дают, они знают на достаточном уровне (разумеется есть исключения).

Ребята (к обоим участникам дискуссии), давайте не будем переходить на личности.

Ребята (к обоим участникам дискуссии), давайте не будем переходить на личности.

Я закончил.

Ребята (к обоим участникам дискуссии), давайте не будем переходить на личности.

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

== List.rev суммарно обработает максимум N элементов. иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? == В List.map например гарантированно List.rev вызовится на всех N. и при чём тут List.map? == Очередь (как и стек) в ФП решаются прекрасно если признаком прерасного являются костыли и дополнительный оверхэд, то да == Я так понимаю, что опыта реализации сего чуда у автора этих строк не было. let a = ResizeArray<int>() // очередь a.Insert(0,1) // put let x = a.[a.Count-1] // pop a.RemoveAt(a.Count-1) == Это банально больно, если не иметь соответствующей квалификации это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. == Я что-то не припомню, чтобы мои преподы с пеной у рта доказывали, что стеки гавно, массив форевер Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден ))

> Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины.

Вот.

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

Всё, я удаляю.

Кто тут взрослый, а кто нет — разбирайтесь приватно.

Посты с оскорблениями трутся, даже если перемешаны с обсуждениями.

> Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины.

ну так это про преподов вообще, а не про студента. Он высказал своё мнение о них, я своё. Никакие личности вроде не задеты

Патологический кретинизм - нормальное сосотояние компьютера. Мы вынуждено думаем на его уровне. Так что патологический кретинизм - нормальное состояние хорошего программиста. ?

Коллеги, кто нибудь знает,каково будущее Hopac?

Увидев мое желание прекратить беседу, решил полную чушь протолкнуть? > иными словами "выталкивании" из "очерди" на списках имеет класс сложности O(1)...O(N), а на массивах O(1). В чём же заключается оптимизированность? Т.е. то что на массивах добавление элемента имеет O(1..N) тебя не смущает? Оптимизированность в том, что для каждого элемента это происходит не более одного раза в отличии от реализации на массиве, следовательно полное прохождение элемента от начала до конца будет условно стоить O(2), т.е. O(1). > и при чём тут List.map? Притом, что при такой трактовке как у тебя им вообще нельзя пользоваться. Ибо там тоже есть List.rev с суммарным объемом в N, т.е. "оверхэд". > если признаком прерасного являются костыли и дополнительный оверхэд, то да Костылей ты все еще не показал. Дополнительного оверхэда, кроме, о ужас!, хранения дополнительных ссылок, я пока не увидел. > let a = ResizeArray<int?) // очередь > a.Insert(0,1) // put > let x = a.[a.Count-1] // pop > a.RemoveAt(a.Count-1) Ты вообще понял, что написал? Ты в курсе что твой a.Insert(0,1) имеет сложность O(N)? O(N), а не O(1..N)! Это не считая того, что это нихера не иммутабельная структура. > это больно, если мозги отравлены - легко запутаться в вышеприведенном коде. Ты умудрился запутаться в вышеприведенном коде. А ты еще ничего иммутабельного не сделал. > Сомнительные авторитеты твои преподы. Насколько я знаю, 90% "преподов" "программирования" - идиоты, 9% - патологические кретины. И то, что они доказывают, вовсе не является аксиомой не зависимо от наличия пены у рта. Если препод не догоняет, что динамический массив - это есть и стек, и очередь - то препод однозначно профнепригоден )) В данный момент "патологический кретином" и "идиотом" выставляешь себя ты. То что динамический массив можно юзать как стек и очередь нихрена не значит, что он для этого будет эффективен. Возможно, ты путаешь динамический массив с Deque (хотя почему я должен думать за тебя, если ты даже не потрудился нормально прочитать мои замечания?), которую можно юзать вышеуказанным способом, и которая часто реализуется на динамическом массиве. 1. Динамический массив имеет: O(1..N) за вставку в конец, O(N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(N) за удаление в начале. 2. Двунаправленная очередь на динамическом массиве: O(1..N) за вставку в конец, O(1..N) за вставку в начале, О(1) за удаление в конце (O(1..N) если экономим память), O(1) за удаление в начале (O(1..N) если экономим память). 3. Стек на основе массива: O(1..N) за вставку, O(1) за извлечени. 4. Стек на основе списка: O(1) за вставку, О(1) за извлечение. 5. Очередь на основе массива: O(1..N) за вставку, O(1) за извлечение. 6. Очередь на основе двух стеков (на основе списков): O(1) за вставку, O(1..N) за извлечение, причем из-за "одноразовости" переноса стека для большинства задач считается как O(1). Здесь основная претензия - это размазанность структуры данных по куче, что ввиду ссылочных данных уже не так критично. Я не знаю, что за универ тебя выпустил, и что за работодатель тебя нанял, но такое незнание матчасти в сочетании с непомерным гонором должны были вывести тебя в маргиналы еще во времена школьной скамьи. Продолжать дальнейшее обсуждение технической составляющей не буду, ибо с моей точки зрения в данном вопросе ты профан и тебе надо идти на викиконспекты зубрить теорию. Однако, терпеть незаслуженные оскорбления в адрес уважаемых мною людей не собираюсь. У меня есть претензии к современности познаний моих преподов (по прикладным предметам), но уж тот материал, что они дают, они знают на достаточном уровне (разумеется есть исключения).

== на массивах добавление элемента имеет O(1..N) нет, Ёмкость массива растёт экспоненциально при добавлении, поэтому при добавлении N эллементов требуется перенести всего лишь N * Ln(n), а не каждый раз всё подряд переносить == Притом, что при такой трактовке как у тебя им вообще нельзя пользоваться. Ибо там тоже есть List.rev с суммарным объемом в N, т.е. "оверхэд" глупости же. map связан с обходом коллекции и ни какого отношения к добавлению/удалению элементов из неё не имеет. И в массиве сложность обхода O(1), а в списках твоих O(N) Дальше лень читать. Было бы проще, если бы ты прежде разобрался в том, о чём пыешься спорить.

По существу дискуссии замечу, кстати, что реализация очереди на двух списках — интересная, но мне кажется, что List.rev там и правда всё порядочно портит. Хотелось бы посмотреть на результаты бенчмарков для такой очереди.

== на массивах добавление элемента имеет O(1..N) нет, Ёмкость массива растёт экспоненциально при добавлении, поэтому при добавлении N эллементов требуется перенести всего лишь N * Ln(n), а не каждый раз всё подряд переносить == Притом, что при такой трактовке как у тебя им вообще нельзя пользоваться. Ибо там тоже есть List.rev с суммарным объемом в N, т.е. "оверхэд" глупости же. map связан с обходом коллекции и ни какого отношения к добавлению/удалению элементов из неё не имеет. И в массиве сложность обхода O(1), а в списках твоих O(N) Дальше лень читать. Было бы проще, если бы ты прежде разобрался в том, о чём пыешься спорить.

А по поводу map — ты не перепутал сложность обхода всего массива со сложностью поиска одного элемента?

А зачем вообще объединять функциональное программирование с иммутабельностью? Одно другому не мешает ?

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

А зачем вообще объединять функциональное программирование с иммутабельностью? Одно другому не мешает ?

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

А по поводу map — ты не перепутал сложность обхода всего массива со сложностью поиска одного элемента?

я имел ввиду что сами по себе итерации по массиву бесплатны в отличие от списков. map конечно О(N), но О меньше

Ага, с этим соглашусь.

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

Скажем так - реально это inplementation detail. При учете кешей процессора и т.д. массив быстрее связгого списка по умолчанию. Но реализацию списка на массивах то же можно сделать.

Не ндо мешать вместе поведение и реализацию. Мы в мире функций. Здесь утка крякает, потому что у нее есть функция кря. А не потому что внутри есть крякалка

Боюсь, что "реализация списка на массивах" в простом варианте не будет отвечать требованиям к быстродействию (в частности, добавление в начало не будет O(1)). А в продвинутом варианте это уже персистентный вектор — довольно хорошая и практичная вещь, но всё-таки другая.

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

А это изменит поведение списка для пользователя списка? Если это список - то подменить реализацию не стоит почти ничего. В этом прелесть функционалки. Можно не думать о том как реализована функция, достаточно знать аргумент и результат. И вопрос о родной имплиментации чего бы то ни было вставать не будет. А где в интерфейсе списка есть требования к быстродействию? Вот в реализации связного списка есть констатация достигнутого быстродействия - а это, согласитесь большая разница.

Передаём привет твоему коту, или кто у тебя там :)

А это изменит поведение списка для пользователя списка? Если это список - то подменить реализацию не стоит почти ничего. В этом прелесть функционалки. Можно не думать о том как реализована функция, достаточно знать аргумент и результат. И вопрос о родной имплиментации чего бы то ни было вставать не будет. А где в интерфейсе списка есть требования к быстродействию? Вот в реализации связного списка есть констатация достигнутого быстродействия - а это, согласитесь большая разница.

Да, пользователю списка может быть важно, чтобы некоторые операции работали быстро, так скажем.

Если б пользователю это никогда не было важно, то не было бы такого ассортимента коллекций.

Так и я о том же. Если мне важно O(1) на втавке - возьму связный. O(1) на индексном доступе - массив - алгоритм работы можно не менять.

Ну представь, что я делаю какую-то функцию, скажем, бинарного поиска. Принимаю на вход коллекцию и элемент, возвращаю результат поиска. И я хочу (вот прям всерьёз) попросить вызывателя, чтоб у коллекции был поиск по индексу за O(1).

Потому что если там такой асимптотики нету, то и мой поиск им не нужен, пускай используют другой :)

Хеш таблицы

Или даже я бы хотел свою функцию поиска (уже обобщённую) перегрузить по вот этой асимптотике. Чтобы для O(1) у меня работал бинарный поиск, а для O(N) работал линейный.

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

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

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

Да вот ведь, кому я это буду говорить?

В хелп

У меня нет формального способа сообщить это пользователю. Коммент только написать.

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

Пользователь - это тот кто тебя вызывает. Не клиент. У него ктати то же есть требования. Берешь формулу производительности - подставляешь - не удовлетворяет. Ищещь другого производителя ?

А то требования в стиле - хочу феррари - но ездитла чтоб на воде - и чтоб мозеррати на старте делала. И за 2 рубля. Нет? Ну тогда пешком..

Есть куча примеров из жизни, когда ИП нагибает ФП по простоте и производительности одновременно. По мимио очевидных хэш-таблиц и очереди на массивах vs. очереди на списках на вскидку - сортировка Хоара - поиск простых чисел методом "решета Эратосфена" - хранение реактивных данных - функциональный redux тормозной и ужос-ужос, императивный mobx быстрый и простой

По существу дискуссии замечу, кстати, что реализация очереди на двух списках — интересная, но мне кажется, что List.rev там и правда всё порядочно портит. Хотелось бы посмотреть на результаты бенчмарков для такой очереди.

ты удивишься, ноесть ещё две бредовых ФП реализаций очереди, о которых "преподы" не знают))) - на основе Maybe (Option) - с использованием State монады

Очередь на Maybe? Это как?

Очередь на Maybe? Это как?

push :: a -> Queue a -> Queue a push e (Queue inb out) = Queue (e:inb) out pop :: Queue a -> (Maybe a, Queue a) pop q = case top of Nothing -> (top, emptyQueue) Just elem -> (Just elem, poppedQueue) where (top, q') = peek q poppedQueue = Queue (inbox q') (tail $ outbox q') peek :: Queue a -> (Maybe a, Queue a) peek q@(Queue [] []) = (Nothing, emptyQueue) peek q@(Queue inb []) = peek $ Queue [] (reverse inb) peek q@(Queue _ outb) = (Just $ head outb, q)

Есть куча примеров из жизни, когда ИП нагибает ФП по простоте и производительности одновременно. По мимио очевидных хэш-таблиц и очереди на массивах vs. очереди на списках на вскидку - сортировка Хоара - поиск простых чисел методом "решета Эратосфена" - хранение реактивных данных - функциональный redux тормозной и ужос-ужос, императивный mobx быстрый и простой

Это замечательно. Вот каждый раз ты пишешь здесь какой-нибудь общеизвестный факт, давая ему оценку, (хорошо, плохо, удобно, неудобно). Ты же понимаешь что субъективные суждения ведут к срачам? Если да, то зачем? Если нет, то запомни пожалуйста: субъективные суждения ведут к не нужным спорам.

push :: a -> Queue a -> Queue a push e (Queue inb out) = Queue (e:inb) out pop :: Queue a -> (Maybe a, Queue a) pop q = case top of Nothing -> (top, emptyQueue) Just elem -> (Just elem, poppedQueue) where (top, q') = peek q poppedQueue = Queue (inbox q') (tail $ outbox q') peek :: Queue a -> (Maybe a, Queue a) peek q@(Queue [] []) = (Nothing, emptyQueue) peek q@(Queue inb []) = peek $ Queue [] (reverse inb) peek q@(Queue _ outb) = (Just $ head outb, q)

data Queue a = Queue [a] deriving (Show)

Это замечательно. Вот каждый раз ты пишешь здесь какой-нибудь общеизвестный факт, давая ему оценку, (хорошо, плохо, удобно, неудобно). Ты же понимаешь что субъективные суждения ведут к срачам? Если да, то зачем? Если нет, то запомни пожалуйста: субъективные суждения ведут к не нужным спорам.

субъективно - что?

Во! Таки Хаскель! ?

Во! Таки Хаскель! ?

можно и на F#, но лень переписывать - ерунда же

субъективно - что?

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

push :: a -> Queue a -> Queue a push e (Queue inb out) = Queue (e:inb) out pop :: Queue a -> (Maybe a, Queue a) pop q = case top of Nothing -> (top, emptyQueue) Just elem -> (Just elem, poppedQueue) where (top, q') = peek q poppedQueue = Queue (inbox q') (tail $ outbox q') peek :: Queue a -> (Maybe a, Queue a) peek q@(Queue [] []) = (Nothing, emptyQueue) peek q@(Queue inb []) = peek $ Queue [] (reverse inb) peek q@(Queue _ outb) = (Just $ head outb, q)

Мне что-то кажется, что это самая примитивная реализация на списках, а не на maybe.

Ну то есть Maybe-то там только в возвращаемых типах, чтоб не падало на пустой очереди.

Уровня SleepSort

data Queue a = Queue [a] deriving (Show)

А определение типа не подходит к коду ? Там-то как раз вариант с двумя списками и нашим любимым reverse

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

ок. какую оценку ты считаешь субъективной чтоб я понел?)

А определение типа не подходит к коду ? Там-то как раз вариант с двумя списками и нашим любимым reverse

да, точно.

А в State-монаду там, наверное, пакуется мутабельная реализация?

Монада Satte type QueueState a = State (Queue a) pushQueue :: a -> QueueState a () pushQueue e = state $ \q -> ((),push e q) popQueue :: QueueState a (Maybe a) popQueue = state $ \q -> pop q

Иммутабельная очередь не имеет практического смысла.

впросем там структура данных та же

ок. какую оценку ты считаешь субъективной чтоб я понел?)

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

https://github.com/fsharp/fslang-suggestions/issues/588

Доброе утро. :)

а разве сейчас это актуально?

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

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

Отмечу, что в пятнадцатой с PowerTools тоже работал линтер :)

Привет!

Привет :-)

First preview of Forge 2.0 (using SDK based templates) available here: https://github.com/fsharp-editing/Forge/releases/tag/2.0.0-Andromeda

First preview of Forge 2.0 (using SDK based templates) available here: https://github.com/fsharp-editing/Forge/releases/tag/2.0.0-Andromeda

Это крутая новость

Это крутая новость

Forge очень не хватает хорошей справки. В том числе в CLI.

С RabbitMq кто работал? Как вы гоняли DU и records, через сериализировали?

я работал и был тот же вопрос. сейчас дам ссылку