O
Так в хаскеле односвязные или двусвязные списки? Просто для односвязного вот это вот будет стоить O(n+m), а для двусвязного просто O(n), где n - аргумент функции, а m - колво элемов в листе.
Size: a a a
2021 February 10
[
чистые массивы как буфферы на памяти дорого увеличивать, в итоге все равно какие-то слайсы в виде деревьев нужны
>чистые массивы, как буферы памяти дорого увеличивать
Но в основном используются именно такие реализации) Просто надо понимать, что в коллекции довольно редко надо добавлять 100500 элементов, а после сразу же удалять. Но когда такие кейсы вознакают, то тут клнечно, без списка никуда.
Но в основном используются именно такие реализации) Просто надо понимать, что в коллекции довольно редко надо добавлять 100500 элементов, а после сразу же удалять. Но когда такие кейсы вознакают, то тут клнечно, без списка никуда.
к
т.е. чисто теоретически можно написать свой двусвязный с такими же красивыми операциями в матчинге?
по поводу красивых матчингов - тут почти в любом случае ответ да, потому что есть две фичи:
- ViewPatterns, которые позволят матчить результат функции на значение в месте паттерна:
f (getPrev -> Just x) = x
- PatternSynonyms, которые позволят спрятать сложные вью-паттерны внутрь синтаксиса конструкторов
так что какая бы страшная реализация не была, зачастую есть возможность сделать достаточно красивый апи вот этими вот штуками
- ViewPatterns, которые позволят матчить результат функции на значение в месте паттерна:
f (getPrev -> Just x) = x
- PatternSynonyms, которые позволят спрятать сложные вью-паттерны внутрь синтаксиса конструкторов
так что какая бы страшная реализация не была, зачастую есть возможность сделать достаточно красивый апи вот этими вот штуками
ЗП
по поводу красивых матчингов - тут почти в любом случае ответ да, потому что есть две фичи:
- ViewPatterns, которые позволят матчить результат функции на значение в месте паттерна:
f (getPrev -> Just x) = x
- PatternSynonyms, которые позволят спрятать сложные вью-паттерны внутрь синтаксиса конструкторов
так что какая бы страшная реализация не была, зачастую есть возможность сделать достаточно красивый апи вот этими вот штуками
- ViewPatterns, которые позволят матчить результат функции на значение в месте паттерна:
f (getPrev -> Just x) = x
- PatternSynonyms, которые позволят спрятать сложные вью-паттерны внутрь синтаксиса конструкторов
так что какая бы страшная реализация не была, зачастую есть возможность сделать достаточно красивый апи вот этими вот штуками
можно еще призмами
AA
это хоть и дерево, но доступ с концов очень дешёвый
это контейнер, который практически не используется примерно никогда, потому что имеет какие-то преимущества в полутора экзотических случаях
AA
>чистые массивы, как буферы памяти дорого увеличивать
Но в основном используются именно такие реализации) Просто надо понимать, что в коллекции довольно редко надо добавлять 100500 элементов, а после сразу же удалять. Но когда такие кейсы вознакают, то тут клнечно, без списка никуда.
Но в основном используются именно такие реализации) Просто надо понимать, что в коллекции довольно редко надо добавлять 100500 элементов, а после сразу же удалять. Но когда такие кейсы вознакают, то тут клнечно, без списка никуда.
лол, когда все функции принимают и возвращают коллекции в основном такие кейсы и возникают, каждому циколу в императивном программировании соотвествует такой кейс в функциональном
MK
а обсудили уже, что паттерн матчинг в питоне будет сразу с or-patterns?
K
а обсудили уже, что паттерн матчинг в питоне будет сразу с or-patterns?
А можно ссылку на PEP?
MK
А можно ссылку на PEP?
ВЩ
и guardы