@haskellru - страница 1647 - Telegram web archive

сейчас посмотрел, да: > The monad comprehensions extension generalises SQL-like list comprehensions to monads. Specifically, it generalises the aforementioned types of transformations to Monad m ⇒ m α → m α and Monad m ⇒ m α → m ( m α ) , respectively.

A64m

https://db.inf.uni-tuebingen.de/staticfiles/publications/haskell2011.pdf но MC - это фича которую DSH-ники делали, так что ничего удивительного

Vladislav

пока что в списке ненависти навскидку могу назвать ImplicitParams, всякие попытки row-polymorphism с Symbol для лейблов, и {-# INCOHERENT #-}

A64m

СОВСЕМ НЕ УДИВЛЕН

A64m

разве что про инкогерент, которое действительно вредное

Алексей

А Symbol и метки чем не угодили?

Vladislav

разве что про инкогерент, которое действительно вредное

ImplicitParams из той же кучи, оно вводит некогерентный констрейнт. Это попытались сдержать, запретив их в instance contexts, но не получилось, через GADT-ы протекает

Vladislav

А Symbol и метки чем не угодили?

Потому что метки это не строчки

Vladislav

Если у меня две сущности одинаково называются, это не говорит о том, что это одна сущность

Vladislav

А полиморфизм должен быть по концепциям, а не по именам

Алексей

Разрешаются по типу

Vladislav

Вот типы пусть и служат метками

Алексей

Концепций в языке нету, только имена, к сожалению

Vladislav

Неправда

A64m

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

Алексей

Вот типы пусть и служат метками

Синтаксис неудобный

Leonid 🦇

Я тоже люблю больше бойлерплейта

Vladislav

Концепций в языке нету, только имена, к сожалению

если я объявлю data Bool = False | True, то есть имя "Bool", а есть сам тип данных. в другом скоупе имя Bool может ссылаться на что-то другое

Vladislav

Чтобы сущность идентифицировать, нужно знать пакет, модуль, и в нём имя. Ну и особенность системы гарантирует тут уникальность

Vladislav

А если взять именем строчку, и абстрагироваться по строчкам, вот тут-то оно и течёт

Vladislav

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

так сделали бы эту фичу не на тайпклассовых контекстах, другой был бы разговор

Vladislav

Но тут еще большой вопрос, должно ли это делаться не на тайпклассовых контекстах, потому что с человеческим reflection вроде можно и сделать

Vladislav

И с нормальным скоупингом вместо Symbol для имён опять

A64m

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

Vladislav

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

A64m

да я понял вашу позицию по строчкам. но без перегрузки "по строчкам" нормальных рекордов не сделать

Vladislav

сделать, перегрузкой по типам

A64m

как и вообще дататайп-дженериков

A64m

это не рекорды

A64m

весь смысл рекордов в перегрузке "по строчкам"

Vladislav

чем data Rec = MyRec { a :: Int, b :: Int } хуже, чем newtype A = A Int newtype B = B Int type Rec = { A, B }

Vladislav

или label A label B type Rec = { A :: Int, B :: Int }

A64m

тем что требует деклараций

A64m

нормальный рекорд вообще не должен никаких деклараций требовать

Vladislav

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

Vladislav

альфа-эквивалентность и всё такое

A64m

да понятно в чем смысл, для рекордов это неудобно

Vladislav

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

Vladislav

я не знаю как можно с серьезным лицом это толкать

Vladislav

формализовывать

Vladislav

и т.д.

Vladislav

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

Алексей

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

Алексей

data V3 a = V3 { x :: a, y :: a, z :: a } ?

Vladislav

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

Алексей

Три ньютайпа разводить?

Vladislav

конечно

Алексей

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

Ну понятно, что если программы не писать, то важна не нотация, а теоретическая чистота

Vladislav

я имею в виду, что пусть нотация будет с любыми уродствами

Vladislav

и путаньем сущности и имени

Vladislav

всё ради компактности

Vladislav

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

Vladislav

то есть строчки, которые для меня всегда жили в мете, в нотации, начинают переползать в семантику — угххх

A64m

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

напоминаю, что вы говорите бойлерплейт "как будто это что-то плохое" человеку, который продвигал data Foo where type Bar :: Foo type Baz :: Foo type Quux :: Foo