Concepts vs TypeClasses vs Traits vs Protocols vs Type Constraints

ненужно vs ненужно vs ненужно vs ненужно vs ненужно

Стандарт C++ уже в два книжных шкафа не умещается, а мы смеёмся и просим ещё.

Прислал комитет по стандартам C++

Забыл добавить еще void *ptr и аккуратные макросы в стиле Православной Сишечки.

D, Rust, Nim, Swift хватит всем

D, Rust, Nim, Swift хватит всем

Желаю тебе пользоваться софтом, написанным только на этих языках.

Какая-то хрень со скриншотами реддита, фотками и гей-пропагандой.

Даже не знаю, что здесь интересного.

гей-пропагандой.

Contracepts vs NotMyTypeClasses

«Шутка». Не \судите\ строго.

просим ещё

шкафы уже выехали

Для интереса не поленился, прошел по ссылке. В этих файликах не раскрыто даже сотой доли потенциала классов типов, трейтов и ограничений. Даже боюсь представить себе, какие из этого будут сделаны «выводы».

Но я так понял, что автор новости сам в теме абсолютно плавает, раз не заметил очевидного, принеся сюда какую-то ерунду.

Объясните не посвященному зачем все это нужно может быть?

Чтобы делать то, что делают на Rust, но только с адской болью

Интересный доклад нашёл: https://github.com/codereport/Talks/tree/master/2020-11-MeetingC++/ConceptsTr...

Неужели америкосы такие тупые? Я чуть не заснул, листая страницу за страницей рассказов о том, что «2 + 3 = 3 + 2», и «2 + 2 + 1 = 2 + 3», и «1 + 1 + 3 = 4 + 1». Конечно, может быть публика вообще понятия не имеет, что такой типоклассы, протоколы, концепты. Правда, тогда непонятно, что они там делают, и конфу нужно было называть «посиделки для менеджеров» — все-таки это больше похоже на рекламу подкастов, чем на выдачу какой-то полезной инфы. В цитируемые каким-то образом попал Кевин Хенни, достоверно известный мне кретин-лектор-автор книг, но я не знаю, в каком контексте он упоминался, потому пока что откажусь от выводов.

Давеча как раз размышлял про типы. А именно — как это говно натянуть на питон, чтобы данные можно было эффективно пересылать, и при этом не морочить голову кодеру. И таки я больше склонялся к подходу «тип данных, как возможность выполнить некоторые операции над значением», что больше похоже на концепты, чем на типоклассы. Элементарный пример — индекс в массиве. Никому не нужен тип «целое число, которым можно индексировать элементы массива печатных символов» — людям нужно «целое число, которым можно индексировать вот этот массив и не вывалиться в корку».

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

———————————————————————————————————————————————————

Только не понятно, какого лешего нужно было ждать 30 лет, чтобы начать об этом говорить. Да Вадлер-Блотт разрабатывали подобную систему типов типов (sic!) уже в 1988 году. Но эта хрень абсолютно бесполезна, если у вас нет достаточно умного и общительного вывода типов, потому что ваша стандартная библиотека станет нечитаема, как и ваши сообщения об ошибках. C++ и так не отличается лаконичность и быстротой компиляции, а с концептами ему вообще кирдык будет. Система компиляции Си прокатывала как раз потому, что метапрограммирования в языке почти не было. Но со сменой парадигмы нужно менять систему компиляции, а этого я не вижу в крестах.

Стандарт C++ уже в два книжных шкафа не умещается, а мы смеёмся и просим ещё

С Java/C# не перепутал?

Объясните не посвященному зачем все это нужно может быть?

Чтобы описывать взаимосвязи типов значенйи и функций с этими типами, которые обычной системой типов не описываются — а хотелось бы. Чтобы ловить ошибки при компиляции, а не при выполнении. Хотя, на самом деле типоклассы были созданы для того, чтобы писать меньше вспомогательных конструкций, и просто описывали интерфейсы для тех же самых операторов сравнения. То есть, что-то ближе к утиной типизации Go. Потому концепты C++ сдохнут.

Опять дошколята с помойки несут херню. Никакого отношения это говно к типам не имеет, оно существует не для типов, а для их затирания. Ни к каким ошибкам компиляции отношения не имеет, потому как оно затирает типовую информацию.

Нет, дошколёнок. Тайпклассы созданы обхода проблема полиморфизма в скриптухе. Система типов скриптухи не может в полиморфизм. Поэтому полиморфный код сводится к монорфному через рантайм-обобщения.

Потому концепты C++ сдохнут.

Уровень макаки с помойки поражает, как обычно.

А что там сравнивать? Или по-человечески или как в C++.

Забыл добавить еще void *ptr и аккуратные макросы в стиле Православной Сишечки.

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

(я ни разу не эксперт в системах типов, так что если что не бейте)

«целое число, которым можно индексировать вот этот массив и не вывалиться в корку»

Просто для подумать, существуют dependent types, в которых тайпкласс как раз позволит описать «натуральное число, которым можно индексировать вот этот конкретный список»:

data Vect : (len : Nat) -> (elem: Type) -> Type where
  Nil  : Vect Z elem
  Cons : (x : elem) -> (xs : Vect len elem) -> Vect (S len) elem

Ну или массив: https://github.com/idris-hackers/idris-array/blob/master/Data/Array.idr

Только нужно len сделать Nat и поднять на уровень IOArray

Просто для подумать, существуют dependent types, в которых тайпкласс как раз позволит описать «натуральное число, которым можно индексировать вот этот конкретный список»

Я почти не разбираюсь в идрисе, но что-то мне говорит, что записать на этом команду «взять из массива элемент по индексу со смещением» будет полнейшим угаром.

«взять из массива элемент по индексу со смещением» будет полнейшим угаром.

Нет, это как раз угаром не будет. Основной угар там будет с тем, чтобы всегда доказывать типы функций (т.е. если ты говоришь, что у тебя ф-ция doubleVect : Vect n Int -> Vect (n*2) Int, то тебе это нужно доказать). После этого имея Vect n Int и Fin n получить Int уже очень просто: Data.Vect.index

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

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

Я почти не разбираюсь в идрисе, но что-то мне говорит, что записать на этом команду «взять из массива элемент по индексу со смещением» будет полнейшим угаром.

Для начала нам понадобится тип «натуральное число не больше n», так называемый Fin:

data Fin : (n : Nat) -> Type where
    FZ : Fin (S k)
    FS : Fin k -> Fin (S k)

Имея его под рукой написать функцию index для вектора, которая гарантированно завершается, очень просто:

index : Fin len -> Vect len elem -> elem
index FZ     (x::_)  = x
index (FS k) (_::xs) = index k xs

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

Как в Ada?

Как в Ada?

Ада пошла по пути, подобному PL/I и Rust (за исключением вывода типов), а потом умерла. Пробираться сквозь лес вспомогательных конструкций — это ни разу не весело.

А какие вспомогательные конструкции, кроме end’ов там мешают?

   with ada.text_io; use ada.text_io;
   with ada.integer_text_io;
   procedure hello3 is
      i, j: Integer;
      f, g: Float;
   begin
      i := 3;

      ada.Integer_text_io.put(i);
      ada.text_io.put(i'img);
      -- 'img and 'Image  are similar to toString
   end hello3;

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

https://www.adahome.com/articles/1997-06/am_cando_a2.html — Appendix 2: Variable-length argument lists, code examples
https://learn.adacore.com/courses/intro-to-ada/chapters/records.html - Records

Примерно как в расте с его бесконечными ёлочками, с той лишь разницей, что создатели Ada жили на 40 лет раньше, а потому прошли едва ли треть того пути, который прошел раст с его трейтами, макросами, выводом типов, более продвинутым (чем у ады) контролем видимости ссылок на переменные, и косвенное следствие последнего — замыкания. Я сам выступаю за то, чтобы строить язык вокруг типов данных, а не вокруг классов, но даже в 1980 году можно было сделать лучше, и тот же ML с выводом типов Hindley-Milner уже был в 1973 году.

Но все это новомодные для того времени идеи были выше уровня создателей Ада (или создатели посчитали себя выше этого), потому они слепили эдакий паскале-алголо-PL/I. Напоминаю, что паскаль ранее назывался Algol W, также был Algol 68, а PL/I — это дальний родственник Algol 60.

Отдельно заслуживает внимания куцый механизм многозадачного взаимодействия. Уже в 1978 году Дейстра описывал алгоритм параллельного сборщика мусора, а всё, что смогли придумать создатели Ады — это примитивный канал производитель-потребитель. По крайней мере в раннем Аде, а не том, что него со временем наросло. Этот механизм начисто скопирован с Concurrent Pascal 1974 года.

То есть, не было никакой фантазии у комитета «зеленого языка» (как тогда именовался проект Ада). Они попытались из довольно узкого набора готовых кубиков скомпоновать низкоуровневый язык со строгой безопасностью памяти, а в итоге получилось форменное издевательство над программистом, который этим будет пользоваться. А ведь был лисп, Scheme, был ML со статическими типами, Smalltalk — нет, нам нужен только алгол.

и тот же ML с выводом типов Hindley-Milner уже был в 1973 году.

И чо? Есть мысли, почему не взлетел?

Уже в 1978 году Дейстра описывал алгоритм параллельного сборщика мусора, а всё, что смогли придумать создатели Ады — это примитивный канал производитель-потребитель.

Так в аде нет сборщика мусора (когда-то давно был, теперь ни в одной живой реализации его нет).

Ну это я так. Сам я не программист, просто для души насилую себя адой иногда. Не так уж и плохо, покрайней мере начиная со стандарта 2012.

Так в аде нет сборщика мусора (когда-то давно был, теперь ни в одной живой реализации его нет)

Высвобождение ресурсов — это одна из ключевых проблем многопоточного взаимодействия. Я лишь писал о том, что тот же Дейкстра обогнал язык Ада лет на десять в момент разработки этого языка.

И чо? Есть мысли, почему не взлетел?

Как это не взлетел? Вывод типов в ограниченной форме есть в Rust. ReasonML относительно живой. Для Scala уже более современные локальные методы вывода типов применяют. А непопулярно потому, что в основном этих нишах тусят JS, Python, PHP — никто не хочется учиться.

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

когда стандарта 2012 года с контрактами (предусловия, постусловия, инварианты) не было – всё это там было.

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

в LogTalk прикольно сделано: если в смоллтоке всё это объект (и классы и метаклассы как затычка системы типов к объектам и метаобъектам, то есть, прототипам) – то в LogTalk всё это first class object одного из трёх типов: объект, прототип, категория.

то есть, объект – это то, что отвечает на сообщения. прототип (интерфейс) и метаобъектный протокол (объектная категория, подсистема) это – подмножество таких сообщений.

то есть, системная корректность классов – выводима для метаобъектного протокола который функтор над интерфейсами который (прототип) функтор над метаобъектами (которые «объекты описывающие объект», то есть, прототип, интерфейс, метакласс). а объектом может быть представлен инстанс чего-то: объекта, класса, метакласса. ну или инстанс чего-то без класса, который можно только клонировать (прототип).

типа как в объектной системе смоллтока есть объекты, которые можно создавать (метакласс умеет new) и которые нельзя (behaviour, metaclass общий тот же) напрямую, только через метаобъекты.

про метаобъекты ещё хорошо в «DSLs in Action» расписано картинкою, да и в этих DSLях миксины всю дорогу.

Видео выложили: https://youtu.be/Qh7QdG5RK9E