AR
Stream.unfold({0, 1}, fn {curr, next} -> {curr, {next, next + curr}} end)ну и потом носишься с этим аккуратно думая что ты уже вычислил, а что еще нет и кешируешь ручками
Size: a a a
2020 May 25
AR
или перевычисляешь каждый раз
AR
не говоря уже про декларативную силу рекурсивных определений )
AB
не говоря уже про декларативную силу рекурсивных определений )
вот насчет этого я бы поспорил, к ним нужно привыкать
AB
имхо, unfold сильно читабельнее для неподготовленного человека
PG
1) да, потому что стримы сделаны для галочки, у нас тут не call by need
2) какая сила если у нас даже head/tail от стрима не возьмешь?
2) какая сила если у нас даже head/tail от стрима не возьмешь?
LL
не говоря уже про декларативную силу рекурсивных определений )
Ну,
elixir/erlang достаточно императивные в мире функциональных языковPG
стримы делают свою работу, но во многих случаях, когда хочется пофлексить ленивостью, списки будут быстрее
LL
ну и потом носишься с этим аккуратно думая что ты уже вычислил, а что еще нет и кешируешь ручками
Поэтому стримами редко пользуются, есть классные
concurrency паттерны, которые удобно и идиоматично заменяют большие и сложные стримыAR
имхо, unfold сильно читабельнее для неподготовленного человека
НА САМОМ ДЕЛЕ, под "неподготовленным" в данном контексте считается человек, который 10 лет писал на сишках / js-ах, и ему вот такие нотации непривычны. кмк, еще большой вопрос, что является более _понятным_ для человека — мышление в рамках одной операции или более глобальными сущностями
AR
1) да, потому что стримы сделаны для галочки, у нас тут не call by need
2) какая сила если у нас даже head/tail от стрима не возьмешь?
2) какая сила если у нас даже head/tail от стрима не возьмешь?
ну воображаемая сила. не, в рамках того, что есть все круто, просто было бы круто унифицировать Stream и условные enum операции на списках, я к этому привык в кложе, но мне вот объяснили в чате, что на beam это не сделать нормально
LL
На
beam вообще с любой мемоизацией всё очень плохо. Единственные нестрашные мемоизации которые я знаю - это через process dictionary в рамках одного процесса или через Cachex в рамках системыPG
хаскель в этом плане довольно специфичный язык, во всех строгих/тотальных языках стримы и списки это разные сущности
AR
На
beam вообще с любой мемоизацией всё очень плохо. Единственные нестрашные мемоизации которые я знаю - это через process dictionary в рамках одного процесса или через Cachex в рамках системыо, process dictionary, не знал
AR
хаскель в этом плане довольно специфичный язык, во всех строгих/тотальных языках стримы и списки это разные сущности
ага, но КРАСИВО же )
LL
ага, но КРАСИВО же )
Да и борщи тоже вкусные, буду хаскеллистом
LL
1) да, потому что стримы сделаны для галочки, у нас тут не call by need
2) какая сила если у нас даже head/tail от стрима не возьмешь?
2) какая сила если у нас даже head/tail от стрима не возьмешь?
Так надо уже давно реализовать человеческие стримы на
elixir-ах. А то даже со всеми лимитациями beam-а текущая реализация всё равно сосёт, я уверен можно и лучшеАЮ
V
Котаны, а кто использовал кастомные ecto-типы (Ecto.Type) в запросах?
Например
Например
defmodule Player doЧто указать вместо
schema "players" do
field(:id, :integer)
field(:gender, Gender)
end
end
defmodule Gender do
use Ecto.Type
def cast(:male), do: 1
def cast(:female), do: 2
def load(1), do: :male
def load(2), do: :female
end
query = from p in Player,
where: p.gender = ???
select: p
???? Варианты :male и 1 не работают. Доки читал, книжки скачивал, у гугла спрашивал, все молчат.Попробуй
where: p.gender == ^:male.V
Попробуй
where: p.gender == ^:male.Спасибо. Я уже нашёл способ
where fragment("?", p.gender) == type(^:male, p.gender)
но и твой вариант попробую.АЮ
Вообще, если либа ecto_enum, которая позволяет не писать такие определения типов руками.