там баги

достаточно только типов

написал и можно идти пить чай

чай важно

код нет

извините

чай - важно!

solution = curry $ (/2) . abs . sum . uncurry (zipWith (*)) . (***) shiftedSum shiftedFSub ^Это считается за point-free abuse?

Это норм

на самом деле нет :)

на самом деле нет :)

Хорошо, а как бы вы написали? Я ненастоящий штангист, я только учусь

Написал бы с аргументами

solution xs ys = (/2) . abs . sum $ zipWith (*) xs ys

solution xs ys = (/2) . abs . sum $ zipWith (*) xs ys

ну, это малость не то

((/2) . abs . sum . zipWith (*)) <$> shiftedSum <*> shiftedFSub

(не проверял в ghci)

((/2) . abs . sum . zipWith (*)) <$> shiftedSum <*> shiftedFSub

Скобочки слева длинные :/

Вот да, instance Applicative ((->) a) и тут полезен

они может и не нужны

Можно без скобок вокруг первой композиции, т.к. у (.) приоритет выше, чем у (<$>)

только будет таки сечение композиции, кмк (((/2) . abs . sum) .) . zipWith (*) т.к. левая часть данного аппликативного выражения должна принять два аргумента

Подскажите, вот здесь https://wiki.haskell.org/Typeclassopedia Exercises Implement Functor instances for Either e and ((->) e). Под Either e имеется в виду взять для e конкретный тип? Например Either Int?

Нет

instance Functor (Either e), так и пишешь

Это значит, что инстанс будет работать для любого e

Можешь даже явно так и написать, "для любого" (т.е. "forall"): instance forall e. Functor (Either e) where

Для этого надо только -XExplicitForAll включить.

То есть должен получиться функтор над конструктором типа

Функтор и так требует * -> *

Понял, значит не имеется в виду конкретный тип) Счас буду догонять

То есть он всегда "над конструктором типа"

а всё. уяснил. то есть мы просто игнорируем первый параметр

> I'd imagine we want the nursery to fit in L1 or L2 caches (where applicable) and the Gen1 heap to fit in the rest of the Cache left in Level3 after we account for nurseries?

традиционный конкурс "угадай эксперта"

впрочем, эксперт всякий раз один и тот же

а всё. уяснил. то есть мы просто игнорируем первый параметр

Я бы лучше посоветовал использовать расширение InstanceSigs. И написать инстанс так: instance Functor (Either e) where fmap :: (a -> b) -> Either e a -> Either e b fmap = ... Если сравнивать с определением класса Functor, то сразу появлятся смысл в таком инстансе: class Functor f where fmap :: (a -> b) -> f a -> f b Можно считать, что если вместо f подставить Either e, то сойдётся.

Спасибо, интересно, то есть можно продублировать сигнатуру в инстансе, действительно более явно получается

а всё. уяснил. то есть мы просто игнорируем первый параметр

Скорее, не игнорируем, а связываем. Это как частичное применение функции двух аргументов к своему первому аргументу.

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

мы же не фиксируем тип левой части

это похоже на частичное применение, только второго аргумента, а не первого - но только похоже.

А какие есть пакеты упрощающие работу с TH?

Скорее, не игнорируем, а связываем. Это как частичное применение функции двух аргументов к своему первому аргументу.

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

но только применили не к конкретному типу а к переменной типа

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

Конструктор типа - это то, что находится слева от знака равно. А то, что справа - это конструктор данных. Он может иметь такое же название, как и конструктор типа, или же другое название - но в любом случае конструкторы типа и данных обитают в разных пространствах имен. При этом конструктор данных одновременно является и функцией, которую мы применяем к аргументам, чтобы получить значение нашего типа.

Это я знаю, но в описании инстанса у нас конструктор типа.

В описании инстанса тип. Это может быть и частично/полностью применённый (сконструированный) тип - всё зависит от кайнда

Разве конструктор типа не является типом? (HOT)

(покапитанствовал :))

Является, конечно

ок)

Что совсем ничего? Я не верю, что не существует библитечки позволяющей перебирать AST более комфортно :(

Куда уж там упрощать?

И так сравнительно нормально

Это не сложно, но муторошно :( складывается впечатление, что приходится писать много лишнего. Да и результат выглядит не очень красивою

Это чтобы не злоупотребляли :)

Не как не могу добиться, чтобы оно меня эстетически удовлетворило.

Это чтобы не злоупотребляли :)

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

TH-код не должен выглядеть эстетично, он должен выглядеть "немного не очень" - чтобы не хотелось его использовать без необходимости :)

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

Generic?

TH, это же про "по-быстрому нашаблонизируем то, что копипастить лениво"

Есть еще такая идея

Generic?

Смотрел, не то. Суть в том, что у меня есть разные акторы и им всем идут разные сигналы. Часть из этих сигналов образуют пересекающиеся множества.

Что быстрее?

Копипастить?

Или придумывать?

Придумыввать дженерики - интереснее

ERROR: S client not available

А копипастить - быстрее

без дженериков

А копипастить - быстрее

К чёрту, это потом невозможно править и поддерживать.

Копипаста плохо сопровождается, да

Соглашусь

Но

Есть вопрос

Нужно ли это?

Сопровождаемость?

И вообще как сделать разные типы с пересекающимися множествами без TH не знаю.

Поддержка?

Что "нужно ли это"?

Вам хочется писать каждый инстанс ToJSON руками?

В болших проектах - да

Ну нет же

есть, я не знаю fasterxml

или что там

Тот код, который не написал программист средней руки, а нагенерила либа - более лучший

Вам хочется писать каждый инстанс ToJSON руками?

Мне нравится, как сделана Binary и её сестра серализк.

Это принципиальный вопрос?

Если что-то можно доверить компилятору (скинуть на него), то это нужно сделать.

Делать с ними сериализацию данных одно удовольствие, дериав.

Это принципиальный вопрос

Я очень люблю скала

Если что-то можно доверить компилятору (скинуть на него), то это нужно сделать.

Вот плюсую!!!

На втором месте наверное хаскел

Но блин

В Scala другие привычки и нормы

Восновном пишу на джава

Но вот вопрос то в чем

В Haskell всё, что можно отдаль компилятору, отдают ему. Птому что компилятор умнее, не страдает замыливанием глаз, не забывает, не очепятывается

Надо ли прилагать кучу интеллекстуальных усилий, чтобы найти дженерик решение?