data X = A | B

тут то зачем? здесь всё выравнивается нормально :)

К слову, type level lists в коде у нас сильно меньше, чем всего остального. Зато единообразие присутствует везде.

даже дата сверху выглядит приятнее, чем '[

вот для этого стиль и нужен, потому что от обсуждения кому что приятнее - профессиональное пригорание

Я пригорал, помнится

А теперь у меня в 99% случаев стайлчекер сразу доволен :)

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

это долго все выбирали, в итоге какими-то моментами поступились(вроде тех же тайп-левел листов) для простоты правил

миллион корнеркейсов все равно никто держать в голове не может

вообще это реально неприятная роль - гайдом по стилю заниматься

Все кругом недовольны, кругом корнеркейсы и потом все выглядит по меньшей мере так себе. Зато в команде боли субъективно меньше(тут зависит от того у какого процента горит от разметки, это случается не у всех).

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

как типы связаны с инструментарием?

нормальный инструментарий просто позволяет смотреть типы где надо, куда-то их писать для этого не нужно

we must overcome our type inference training and learn to see types as pushing requirements inwards, as well as pulling guarantees out

© conor mcbride

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

а пока превозмогать привычку к выводу типов рановато

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

в скале нету вывода же

в скале нету вывода же

Смешно

грустно

> Scala has a built-in type inference mechanism which allows the programmer to omit certain type annotations.

реконструкция есть, а вывода нет

* that barely works even in one direction

реконструкция есть, а вывода нет

Опять эти ваши термины из каких-то паперов 90-х

реконструкция есть, а вывода нет

Ничего не знаю, в официальном мануле по языку сказано "инференс" - значит, инференс 😛

реконструкция есть, а вывода нет

Это же синонимы

нет

летс терминоложи баттл бегинс

нет

В чем разница тогда ?

вывод - это дамас-милнер и модификации, а реконструкция - все остальное

"потому что я так сказал"

потому что между этими двумя случаями есть существенная, практически значимая разница

на самом деле, если смотреть в этом ключе то и "дамас-милнер и модификации" можно разделить на три практически различающиеся вещи

Вот в C# и джаве хороший тон начать с интерфейсов и тестов, а потом переходить к имплементации. Т.е., типы важны потребителям кода (напр., мученикам из поддержки). Даже если компилятор обойдётся.

но аннотировать даже в хаскеле принято больше, чем только это

топлевельные определения, которые частью интерфейса не являются тоже аннотируются

потому что между этими двумя случаями есть существенная, практически значимая разница

Странно понятия делить по практической разнице, следует их разделять согласно сущности, ну. Уж "всё остальное" никакой сущностью не обладает, это просто произвольное случайное объединение.

если кому-то интересная моя борьба с красотой, 5 переменными и линзами, то я переписал State+Bookkeeper+OverloadedLabels на ST. получилось почти столь же компактно, да ещё и работать стало на порядок быстрее

и хуже чем пять парамеров?

и хуже чем пять парамеров?

нет, лучше

и хуже чем рекорд и леннартовский пм для него

а что такое "леннартовский пм"?

RecordWildCards

и хуже чем рекорд и леннартовский пм для него

только если бы его можно было объявлять в скоупе функции

не принципиально

через genericToJSON все таки сделал нужный мне инстанс ToJSON

теперь захотел вынести код вотдельную функцию

f x = case genericToJSON defaultOptions x of Object o -> o _ -> error "toObject: value isn't an Object"

и хочу же написать сигнатуру чтобы компилятор не ругался

library/CompletionReport/Report.hs:61:1: warning: [-Wmissing-exported-signatures] Top-level binding with no type signature: f :: (aeson-1.2.4.0:Data.Aeson.Types.ToJSON.GToJSON Value Zero (Rep a), Generic a) => a -> Object

добавляю сигнатуру f :: (GToJSON Value Zero (Rep a), Generic a) => a -> Object

и получаю library/CompletionReport/Report.hs:61:7: error: • Expecting one fewer arguments to ‘GToJSON Value Zero’ Expected kind ‘(* -> *) -> Constraint’, but ‘GToJSON Value Zero’ has kind ‘Constraint’ • In the type signature: f :: (GToJSON Value Zero (Rep a), Generic a) => a -> Object | 61 | f :: (GToJSON Value Zero (Rep a), Generic a) => a -> Object | ^^^^^^^^^^^^^^^^^^^^^^^^^^ library/CompletionReport/Report.hs:61:21: error: • Expected kind ‘* -> *’, but ‘Zero’ has kind ‘*’ • In the second argument of ‘GToJSON’, namely ‘Zero’ In the type signature: f :: (GToJSON Value Zero (Rep a), Generic a) => a -> Object | 61 | f :: (GToJSON Value Zero (Rep a), Generic a) => a -> Object | ^^^^

там разные GToJSON

есть GToJSON, а есть GToJSON

короче, убери Value

type GToJSON = ToJSON.GToJSON Value

спасиб

я просто оч удивлялся что у genericToJSON такая же сигнатура:)

Как называется ситуация, когда есть пачка тайпклассов и не совсем понятно как их комбить, typeclass hell?

не уверен что этой ситуации давали специальное имя

Пусть будет без имени, есть какие-нибудь гайды как с этим бороться?

лучше вопрос задай, что не понятно

это как вопрос, есть библиотеки и непонятно как их композить

ну что на это ответить?

Просто иногда хочется написать что-то вроде Foo <=> Bar и реализовав один класс, получать инстанс второго

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

если они друг из друга следуют, то это должен быть один класс

Есть отдельные сво-ва типа рефлексивности\симметричности\тразитивности и не понятно как их комбить в разнообразные отношения

Equivalence это Reflexive+Symmetric+Transitive, но когда каждое сво-во в отдельном интерфейсе нельзя просто объявить какое-нибудь отношение эквивалентностью, сначала надо написать другие инстансы

А если сгруппировать все свойства в составные интерфейсы тоже будет плохо, они бывают нужны по одиночке

сделай 3 класса для R, S, T, и четвёртый, который от них зависит

Просто иногда хочется написать что-то вроде Foo <=> Bar и реализовав один класс, получать инстанс второго

как в deriving via чтоли? для такого есть ТХ костыль который работает с 8.2 вроде

data X = A | B

Блин, не делай так

как в deriving via чтоли? для такого есть ТХ костыль который работает с 8.2 вроде

Пишу на Idris

в идрисе нет тайпклассов проблема решена

всё-таки классы включают в себя тайпклассы как подмножество, так что есть

Equivalence это Reflexive+Symmetric+Transitive, но когда каждое сво-во в отдельном интерфейсе нельзя просто объявить какое-нибудь отношение эквивалентностью, сначала надо написать другие инстансы

Эээ? class Reflexive a, Symmetric a, Transitive a => Equivalence a

всё-таки классы включают в себя тайпклассы как подмножество, так что есть

в Идрисе какие-то другие классы, не как у нас?

Да, я, конечно не самый умный человек. Необходимо: class (R, S, T) => E where Достаточно: instance (R, S, T) => E where Вот и эквивалентность.