GHC 8.0.1

Читать не умеешь?

Есть подозрение, что ты не умеешь.

Ну ладно, давай я приведу первое определение:

класс - расширяемый шаблон кода для создания объекта, обеспечивающий начальные значения для состояния и реализацию поведения.

А ты теперь второе.

Не хватает ссылки на «определение»

Я понадеялся, что местная популяция цацкеледетей осилит гугл. Что, зря?

Выше уже кинули.

Сам _конкретную_ ссылку приведи.

https://en.wikipedia.org/wiki/Class_(computer_programming)

В каком пункте haskell слажал?

1. Не обеспечивает начального состояния. 2. Не обеспечивает реализации. 3. Не умеет в наследование реализации.

Это так, навскидку.

«Новое расширение DuplicateRecordFields, позволяющее использовать в различных типах поля с одинаковыми именами.»

Не прошло и три десятка лет, как оно появилось в Haskell.

Ты тоже решил сумничать, как некоторые детишки тут сверху?

Выше уже заметили, что поля и раньше могли иметь в Haskell одинаковые имена, но в пределах разных модулей. Разные модули это как разные пакеты и классы в Java - каждый создает свое пространство имен. Поэтому скорее код будет в разных модулях, чем в одном. Писать все в одном модуле - это тот еще изврат.

Или ты можешь в Java определить два поля с одинаковым именем в пределах одного класса?

Сейчас же разрешили в Haskell позволить мешать имена записей в кучу в пределах одного модуля, что не совсем есть хорошо с точки зрения стиля, но пусть лучше будет такая фича.

Изврат - это создавать модули под ограничения языка, вместо того, чтобы создавать модули по логике их функциональности. Например, я хочу запихнуть все связанное с сетью в net.hs, а не разбивать небольшой сетевой код по разным модулям всего лишь из-за одинакового названия полей в структурах.

Если бы захотел, то взял бы и написал a_field, b_field, вместо просто field.

Gamma et al. 1995, p. 14. Bruce 2002, 2.1 Objects, classes, and object types, //books.google.com/books?id=9NGWq3K1RwUC&pg=PA18.

vs

How to make ad-hoc polymorphism less ad hoc Philip Wadler and Stephen Blott. 16'th Symposium on Principles of Programming Languages, ACM Press, Austin, Texas, January 1989.

вопрос о том можно ли называть классы типов - классами предлагаю передать гуманитариям.

How to make ad-hoc polymorphism less ad hoc

Я и не говорил, что в Хаскеле нет полиморфизма.

вопрос о том можно ли называть классы типов - классами предлагаю передать гуманитариям.

Айтишная терминология - внутреннее дело айтишников. Да и делать это на моей памяти пытались только местные цацкеледети.

Я и не говорил, что в Хаскеле нет полиморфизма

ты говорил, что в haskell нету классов, я привёл пример статьи где ad-hoc полиморфизм введен через «классы»

Айтишная терминология - внутреннее дело айтишников.

общаться с ООП-шниками это как на зону попасть? свой жаргон, свои привычки

я привёл пример статьи где ad-hoc полиморфизм введен через «классы»

Чо, правда?

This paper presents type classes, a new approach to ad-hoc polymorphism.

свой жаргон, свои привычки

Своя терминология, в терминах которой

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

Чо, правда?

OOP классы в Хаскеле можно сделать по-разному. Можно так: https://habrahabr.ru/post/263575/ , можно так: https://wiki.haskell.org/OOP_vs_type_classes#Haskell_emulation_of_OOP_inherit...

In object-oriented programming, a class is ... — так что не в IT, а в OOP.

Айтишная терминология - внутреннее дело айтишников. Да и делать это на моей памяти пытались только местные цацкеледети.

OOP-шники переопределили понятие «интерфейс» из «интерфейс модуля» в «интерфейс класса». Java-шники его ещё раз переопределили в «интерфейс = абстрактный класс».

2. Не обеспечивает реализации. 3. Не умеет в наследование реализации.

Классы в CLOS (defclass) по-твоему тоже не правильные классы?

в Хаскеле классов нет

можно сделать

Не вижу противоречия.

так что не в IT, а в OOP

Class (computer programming). Да и альтернативного толкования этого термина в области программирования никто из вас не дал.

Да и альтернативного толкования этого термина в области программирования никто из вас не дал.

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

Да и альтернативного толкования этого термина в области программирования

Тебе уже писали, что кроме «класса объектов» бывает «класс типов». В соответствующем контексте оба сокращаются до «класс».

Я привёл определение из теории множеств

«я что-то там кукарекнул за теорию множеств» /= «я привёл определение из теории множеств»

которое внезапно отлично подходит к программированию

«отлично подходит к программированию» /= «термин в области программирования»

OOP-шники переопределили понятие «интерфейс» из «интерфейс модуля» в «интерфейс класса».

Это не переопределение.

Java-шники его ещё раз переопределили в «интерфейс = абстрактный класс».

Мы не про интерфейсы говорим.

В соответствующем контексте оба сокращаются до «класс».

В каком контексте?

Прости, чувак, ты всё ещё баклажан. Я надеялся на более интересный срач в этом треде чем то что ты развёл.

Да и делать это на моей памяти пытались только местные цацкеледети.

В этом же смысле классы есть в Coq и Isabelle:

http://www.labri.fr/perso/casteran/CoqArt/TypeClassesTut/typeclassestut.pdf :

Classes are presented as an interface comprised of functions specific to a type, and in the case of Isabelle and Coq , proofs about those functions as well. One can write programs that are polymorphic over any type which has an instance of the class, and later on, instantiate those to a specific type and implementation (called instance) of the class.

Слив засчитан.

В этом же смысле классы есть в Coq и Isabelle

Там этот термин в своём математическом смысле. И под математическое определение класса классы типов попадают, бесспорно.

Он слил тебя в яму с говном? Не булькай и привет глистам!

О, цацкеледитё вернулось. Твой цацкелепапка, за которого ты спрятался, ещё ничего не доказал. Ныряй обратно.

Ниасилил, но одобряю.

Сколько по времени компилит?

Ну и где бы был твой IT без ООП?

Например, я хочу запихнуть все связанное с сетью в net.hs, а не разбивать небольшой сетевой код по разным модулям всего лишь из-за одинакового названия полей в структурах.

Опять же непонятна проблема.

В таких случаях делают реэкспорт модулей в одном модуле, который ничего кроме import из других модулей и не содержит. Тогда вся нужная функциональность во внешнем коде подключается через один импорт к этому мега-модулю, в твоем случае Net.hs (с большой буквы, кстати).

Ну, а теперь можно и конфликтные имена реэкспортировать одновременно. Раньше приходилось экспортировать отдельно.

Там этот термин в своём математическом смысле.

Class Monoid {A:Type}(dot : A -> A -> A)(one : A) : Prop := {
  dot_assoc : forall x y z:A,
  dot x (dot y z) = dot (dot x y) z;
  unit_left : forall x, dot unit x = x;
  unit_right : forall x, dot x unit = x }.

это разве в математическом?

И если уж противопоставлять IT и математику, то сложение и умножение тоже в IT надо считать с переполнением (как в С/C++/Java/...)? А разработчиков лиспа и хаскеля и тут упрекать в том, что сложение и умножение в них не в том смысле, как принято в IT?

А разработчиков лиспа и хаскеля и тут упрекать в том, что сложение и умножение в них не в том смысле, как принято в IT?

Prelude> maxBound :: Int
9223372036854775807
Prelude> maxBound + 1 :: Int
-9223372036854775808
Prelude> maxBound :: Word
18446744073709551615
Prelude> maxBound + 1 :: Word
0

:)

где бы был твой IT без ООП

До сих пор балдел бы в Раю. Опирался бы на алгоритмы, а не на структуры данных. При этом чуть сложней проектирование, но гораздо проще тестирование (состояние в явном виде), гораздо проще таксономия объектов (нет проблемы эллипс-круг), быстрее происходит разработка (так как принцип YAGNI).

:)

На Хаскелевские классы в смысле OOP я ссылку уже давал. А «целое» пишется Integer, а не Int. Так что «термин Integer в области программирования» и в Haskell можно считать не совпадающими.

В Lisp тоже кроме integer есть и fixnum.

Это не переопределение.

Почему же?

В каком контексте?

В Haskell и Coq в языке нет класса объектов, значит класс = «класс типов». В Lisp и C в языке нет класса типов, значит класс = «класс объектов».

На Хаскелевские классы в смысле OOP я ссылку уже давал. А «целое» пишется Integer, а не Int.

Сорри, ты писал просто про переполнение, я лишь упомянул что оно в Haskell тоже присутствует.

Так что «термин Integer в области программирования» и в Haskell можно считать не совпадающими.

Мне кажется, спор с Esper немножко повредил твой моск.

Мне кажется, спор с Esper немножко повредил твой моск.

Я пытаюсь его точку зрения логично и единообразно приложить к остальным терминам IT. Так сказать, доказательство от противного.

Вот ссылка из википедии, аналогичная той, что про класс: https://en.wikipedia.org/wiki/Integer_(computer_science)

In computer science, an integer is a datum of integral data type, a data type which represents some finite subset of the mathematical integers.

Я пытаюсь его точку зрения логично и единообразно приложить к остальным терминам IT.

У него нет точки зрения.

это разве в математическом?

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

А вообще, в той статье первоначально употреблялся термин «type class», потом его заменили на то, что он собой представляет - «class(в математическом смысле) of types». А уже со следующего предложения оно редуцировалось до «class».

Но в целом, ты уже почти доказал, что в IT можно используют мат. определение класса. Только вот coq и isabelle - это инструменты скорее для математиков, чем для программистов, поэтому авторы и позволяют себе соответствующую терминологию. Вот если ты найдёшь такое же в литературе по Хаскелю/Скале/МЛ, будет уже сильный аргумент.

сложение и умножение тоже в IT надо считать с переполнением

Полностью зависит от типа, никакого стандарта сложения в IT нет. И в математике ведь не только циферки складывать можно. Главное, что сложение свойствам сложения удовлетворяет.

Почему же?

Потому что термин «интерфейс» в обоих словосочетаниях значит одно и то же.

В Lisp и C в языке нет класса типов, значит класс = «класс объектов»

Класс в этом значении - вообще совокупность множеств. Совокупность каких множеств представляет собой «класс объектов»?

Вот ссылка из википедии, аналогичная той, что про класс
In computer science, an integer is a datum of integral data type, a data type which represents some finite subset of the mathematical integers.

Бигнамы под него попадают. Или в твоей вселенной придумали оперативу, вмещающую произвольно большой бигнам?

Grady Booch, Object-oriented design: With Applications:

A class is a set of objects that share a common structure and a common behavior.

Если бы захотел, то взял бы и написал a_field, b_field, вместо просто field.

Именно так и делал. И параллельно думал как от этой хрени избавится. Начал читать про всякие линзы (lenses) и полу-работающие расширения к GHC и в итоге меня задолбала вся эта искусственная сложность ради элементарного удобства и я решил отложить этот язык до момента его взросления. Может быть еще лет через 30 осилят «power of the dot». Похоже это у них уже есть в планах - https://ghc.haskell.org/trac/ghc/wiki/Records/DeclaredOverloadedRecordFields/...

Ура! SPJ (Simon Peyton Jones - один из основных разработчиков GHC) не отрицает критичность базового удобства, как некоторые здешние неофиты:

The reasoning for using dot is exactly as SPJ adumbrates in TDNR ("it is critical to support dot notation") — essentially, it's standard practice (both for selecting fields from records in data manipulation languages such as SQL, and selecting methods from objects on OO languages). Postfix application supports an object -> action pattern of thinking: focus on the object, then apply some action; or the UNIX pipes concept of the data 'flowing' left to right.

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

И такими в том числе. Мне лично плевать насколько у него навороченная система типов, если базовые вещи делать неудобно.

Представьте себе, например, описание 1000 NPC в игре, каждый из которых может иметь разное колличество полей. Мы тут либо делаем id_NPC_NAME1, id_NPC_NAME2, id_NPC_NAME3 до посинения (тоже самое со здоровьем и т.д.), либо запихиваем поля одинаковые для всех NPC в отдельную структуру и создаем NPC как вложенную структуру данных. И все бы ничего, только обращение к вложенным структурам данным в хаскеле сделано через жопу.

В ООП это npc.field.field2.field3 = something. Или же вообще просто npc.field3, если мы наследовали классы.

В Хаскеле же придется это дело каждый раз распаковывать проходя всю цепочку. Вот как выглядит это убожество:

addManStk team = team {
    manager = (manager team) {
        diet = (diet (manager team)) {
             steaks = steaks (diet (manager team)) + 1
             }
        }
    }

Вместо team.manager.steaks += 1. Не нравится? Ну тогда изучайте линзы и прочие сделанные на коленке вещи.

Вот такое было мое знакомство с Haskell. Рад, что они выбираются из этой ситуации, хоть и очень медленно.

Вот если ты найдёшь такое же в литературе по Хаскелю/Скале/МЛ, будет уже сильный аргумент.

https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-630004.1

В ML не могу найти классы типов. В Scala они есть, но называются implicit, а всё остальное построено на классах ООП, поэтому классы типов до «классы» не сокращаются.

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

То, которое в IT — не удовлетворяет. (a+b)+c и a+(b+c) могут не совпадать в C++.

Класс в этом значении - вообще совокупность множеств.

В Lisp и C++? И совокупность каких множеств, например, std::string? Впрочем, цитату из Буча уже привели.

Бигнамы под него попадают.

Ты ссылки хоть просматривай... там самый общий случай — n-битное целое. И чему равен n для бигнама?

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

Проблема с рекордами (особенно с изменением вложенных рекордов) гораздо лучше решена в Idris. Я всё надеюсь что подобный синтаксис будет запилен в Haskell.

Представьте себе, например, описание 1000 NPC в игре, каждый из которых может иметь разное колличество полей.

Честно говоря, это какой-то крайне тупой пример. Но если бы мне нужно было работать с 1000 разных но похожих по структуре типов (нахрена, кстати? Я слабо представляю где такое вообще может понадобиться), я бы забил болт и генерил всё это через TH.

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

Вместо team.manager.steaks += 1. Не нравится? Ну тогда изучайте линзы и прочие сделанные на коленке вещи.

То, что ты написал, на Haskell больше соответствует совсем другому коду:

modifyIORef' (steaks $ diet $ manager team) (+ 1)

Сразу чтобы два раза не писать. У многих новичков есть боязнь монады IO, но это проходит потом)