trait + impl vs class , навеяно Rust'ом

Цитата korvin @ 06.07.15, 18:23

не любым произвольным текстом, как в Сишных макросах.

В Сишных макросах тоже не любой произвольный текст можно использовать. Есть ограничения.

Цитата amk @ 06.07.15, 18:53

В Сишных макросах тоже не любой произвольный текст можно использовать. Есть ограничения.

Оу, не знал. Но там всё же "посвободней", чем в шаблонах?

Достаточно, чтобы строка через лексический анализатор проходила без ошибок.

Цитата D_KEY @ 06.07.15, 16:24

Параметрический полиморфизм на уровне типов вводит эти самые полиморфные типы.

Это ты сам придумал такое определение? Я вот в педивикии не вижу такого обязательного требования:

Цитата

Параметрический полиморфизм позволяет определять функцию или тип данных обобщённо, так что значения обрабатываются идентично вне зависимости от их типа. Параметрически полиморфная функция использует аргументы на основе поведения, а не значения, апеллируя лишь к необходимым ей свойствам аргументов, что делает её применимой в любом контексте, где тип объекта удовлетворяет заданным требованиям поведения. Таким образом, реализуется концепция параметричности

Я не вижу причин несоответсвия плюсовых шаблонов этому определению. Может есть какое-то иное определение? Дай ссылку.

Цитата D_KEY @ 06.07.15, 16:24

Не будет. Их будет много(возможно) в сгенеренном коде. Но в системе типов будет ровно один тип. И ровно одна функция. Тайпчекер работает с парметрами полиморфного типа практически как с типовыми переменными. В общем, объяснять долго, а толку будет мало

Зачем объяснять? Я в целом понимаю, чем отличается система типов Хаскеля и плюсов. Я не понимаю, почему ты считаещь это различие достаточным для того чтобы утверждать, что шаблонные функции C++ не полиморфны параметрически.
У нас разногласия фактически на уровне терминологии. Я считаю, что такую вот "имитацию" можно считать параметрическим полиморфизмом.

Цитата korvin @ 06.07.15, 16:33

Тем, что это почти просто текстовая подстановка, почти как макросы (что Сишные, что Лисповые) или HTML-шаблоны, не более того.

Нэть, шаблоны обрабатываются компилятором, а не препроцессором, со всеми вытекающими. Разница огромна.

Цитата korvin @ 06.07.15, 16:33

С тем же успехом можно PHP называть "полиморфным HTML" или как-то так.

Ну вообще-то, в похапе любая функция полиморфна по всем параметрам.

Добавлено 06.07.15, 19:56

Цитата korvin @ 06.07.15, 18:23

Кстати, не знаю, упоминалось ли тут (в разделе вообще), но в D термин mixin имеет два значения: один обще принятый, а второй --- как раз что-то вроде текстовых подстановок (чуть более продвинутых, чем Сишный препроцессор, но менее продвинутых, чем лисповые макросы).

Я упоминал в соответствующем холиворе. Но народ не оценил. Дескать в Nemerle макросы круче. Не спорю, там (в Nemerle) красота, но в целом возможность любую текстовую строку компильнуть как D-шный код, в купе с произвольным CTFE - весьма приятная штука.

Цитата applegame @ 06.07.15, 19:53

Нэть, шаблоны обрабатываются компилятором, а не препроцессором, со всеми вытекающими. Разница огромна.

Ну вообще-то, в похапе любая функция полиморфна по всем параметрам.

Лисповые макросы тоже обрабатываются компилятором. Так в чём огромность разницы?

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

Цитата D_KEY @ 06.07.15, 13:40

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

Я не против сравнения дженериков и шаблонов, D_KEY, я против того, что те и другие были поставлены в равные условия, коли речь в постановке задачи касается терминов "compile-time" и "run-time". Из-за неопытности (?) автора получилось нечто подобное сравнению полнофункционального std::vector<> и динамического C-массива с нереализованным контролем стораджа. Естественно std::vector<> проиграет, и либо вместо него взять следовало std::array<>, либо дореализовать фичу перераспределения стораджа для C-массива.

Цитата D_KEY @ 06.07.15, 13:40

При чем тут какая-то докомпиляция?

Объясняю на пальцах. Дженерики инстанцируются в run-time, при этом получается новый байт-код. Если есть jit-компиляция, то она будет произведена, а значит термин "run-time" уже неполно характеризует происходящие в нём процессы, т.к. подразумевает "compile-time" уже во время "run-time"; если же jit-а нет, то термин "compile-time" вообще неприменим в данном случае, ибо новый байт-код будет интерпретироваться.
С тем же успехом можно на Плюсах реализовать – правда, придётся это делать руками, но никто не мешает на будущее запилить сие себе в библиотеку – досоздание исполняемого объектного кода, и C# тут отнюдь не окажется в выигрыше. Или попробовать сравнить C# и банальным GW-Basic, где последний заткнёт его за пояс однозначно.

Цитата D_KEY @ 06.07.15, 13:40

Шаблонный код не полиморфен уже на уровне системы типов. Вот в чем проблема(для данного примера).

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

Сообщение отредактировано: Qraizer - 06.07.15, 20:04

Цитата korvin @ 06.07.15, 19:58

Лисповые макросы тоже обрабатываются компилятором. Так в чём огромность разницы?

С Лиспом не знаю. Я про сишные макросы.

Цитата korvin @ 06.07.15, 19:58

а не параметрически, т.к. последний имеет смысл только при статической типизации.

Ты уверен? Пруф можно? Что-то я не встречал такого странного условия для параметрического полиморфизма - статическая типизация.

Добавлено 06.07.15, 20:08
Предлягаю вынести спор о плюсовом полиморфизме в отдельный холивор

Сообщение отредактировано: applegame - 06.07.15, 20:12

Цитата applegame @ 06.07.15, 20:07

Ты уверен? Пруф можно? Что-то я не встречал такого странного условия для параметрического полиморфизма - статическая типизация.

Я уверен на 100%. Параметрический полиморфизм(ПП) параметризуется типами, что совершенно бессмысленно при динамической типизации, т.к. там в любом случае типы приходится выяснять в рантайме и то только если нужно. Фактически ПП нужен для "обхода" ограничений примитивной статической типизации и написания обощённого кода. Попробуй написать функцию len, вычисляющую длину списка в Лиспе(да вообще в любом ЯП с дин. типизацией) и в D (вообще в любом ЯП со статической типизацией) и в (оригинальном)Паскале, например.

Сообщение отредактировано: korvin - 06.07.15, 21:44

Цитата korvin @ 06.07.15, 21:44

Попробуй написать функцию len, вычисляющую длину списка в Лиспе(да вообще в любом ЯП с дин. типизацией) и в D (вообще в любом ЯП со статической типизацией) и в (оригинальном)Паскале, например.

Да чего уж так сложно то? Банальный жабоскрипт

function f(a, b) { return a+b; }

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

Цитата korvin @ 06.07.15, 14:48

В C++ же нельзя запихнуть шаблонную функцию в файл реализации, выставив в хэдер только сигнатуру?

Можно. Это называется экспортом шаблона. Существует с C++98. Тот факт, что реализован он только в одном-единственном компиляторе, лично я считаю сознательным саботажем со стороны поставщиков реализации. С C++11 по этой причине экспорт шаблонов не является обязательным.
Однако положа руку на сердце, я признаю, что работать с шаблоном, не имея его сырцов, в условиях отсутствия концептов при отладке своего можно получить геморр ещё тот.

Цитата applegame @ 06.07.15, 19:53

Цитата D_KEY @ 06.07.15, 16:24

Параметрический полиморфизм на уровне типов вводит эти самые полиморфные типы.

Это ты сам придумал такое определение?

Это не определение. Я пытался объяснить разницу между параметрическим полиморфизмом уровня системы типов и параметрическим полиморфизмом на уровне кода(что мы наблюдаем в C++ и D).
Параметрический полиморфизм есть в C++(признаю таки), но там нет полиморфных типов. Уже не знаю, как еще сказать. И не думаю, что мы способны извлечь что-либо болезное из продолжения данного спора

Сообщение отредактировано: D_KEY - 06.07.15, 22:27

Цитата korvin @ 06.07.15, 16:33

Тем, что это почти просто текстовая подстановка, почти как макросы (что Сишные, что Лисповые) или HTML-шаблоны, не более того.

Давай не будем сызнова реинкарнировать ещё одну давным-давно избитую до смерти тему. У макросов с шаблонами примерно столько же общего, как у телефонистки и сотового: результат похож, но это и всё.

Цитата Qraizer @ 06.07.15, 20:02

я против того, что те и другие были поставлены в равные условия, коли речь в постановке задачи касается терминов "compile-time" и "run-time".

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

Цитата

Дженерики инстанцируются в run-time, при этом получается новый байт-код.

Не обязательно. Они вообще могут не инстанцироваться и не генерировать байт-код во время исполнения. Если мы о дженериках.
Не знаю, как там в последних версиях, но JVM очень долго(а может и сейчас) ничего о дженериках не знала и компилятор там генерировал код для Object и обеспечивал boxing/unboxing для встроенных типов.

Цитата

С тем же успехом можно на Плюсах реализовать – правда, придётся это делать руками, но никто не мешает на будущее запилить сие себе в библиотеку – досоздание исполняемого объектного кода

Есть libjit, например. Если я правильно тебя понял. Но суть-то не в том, что там и когда мы генерируем. Вопрос в том, кто и как проверяет. Система типов C++ не знает про шаблоны, шаблоны сначала инстанцируются и сначала мы получаем тип, а потом уже осуществляется с ним работа. Потому тайпчекер не приступит к работе, пока мы не инстанцируем тип. В случае же полиморных типов инстанцировать тип нет необходимости(кроме случаев оптимизации).

Добавлено 06.07.15, 22:39

Цитата MyNameIsIgor @ 06.07.15, 22:12

Цитата korvin @ 06.07.15, 21:44

Попробуй написать функцию len, вычисляющую длину списка в Лиспе(да вообще в любом ЯП с дин. типизацией) и в D (вообще в любом ЯП со статической типизацией) и в (оригинальном)Паскале, например.

Да чего уж так сложно то? Банальный жабоскрипт

function f(a, b) { return a+b; }

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

Пример со списком более "чист" из-за отсутствия требований к типам. Списку все равно, что хранить.

Сообщение отредактировано: D_KEY - 06.07.15, 22:42

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

1. Обсуждайте ради бога. Я не буду спорить касательно термина "полиморный тип", однако скажу своё мнение в 3-ем пункте. Я вошёл в спор с целью показать неверность вывода того хаскелиста (что кем он там являлся-то). Он взял некую сущность из одного языка и сравнил с похожей сущностью другого языка, проигнорировав тот факт, что эти сущности не просто разные, но и сферы их применения разные, и назначения тоже разные. Немудрено, что пришёл к неверному выводу.
2. Так шаблоны тоже могут не инстанцироваться. И даже не полностью инстанцироаться при конкретизации. (А вот дженерики последнее могут?)
   Формально Object с боксингизмом, не особо передёргивая при этом, можно назвать аналогом интерпретации. Мне это напоминает старую добрую Class Library от Borland, которая вполне с успехом применялась в Borland C++ дошаблонных версий и предназначалась для того же, для чего сейчас используется STL. Да, приходилось любой тип сначала делать полиморфным, оборачивая в наследника TObject. Т.о. всё отличие в том, что теперь это делал шарповый компилятор, а не программер руками.
3. Честно говоря, не знаю, правильно ли. Я "просто" предложил как вариант уравнивания шаблонов и дженериков донаделить C++ возможностью, которой шаблоны не обладают, но обладают дженерики: достраивать исполняемый код в run-time. Вот тогда действительно суть будет не в том, что и когда достраивается.
   Что касается полиморфных типов, то я вообще не вполне понимаю, что под этим вы подразумеваете. Лично я не знаю таких за пределами классов с виртуальными методами, каковые называются полиморфными просто для краткости. Тип с моей точки зрения является просто-напросто неким атрибутом сущности. И этот атрибут однозначно определяет свойства этой сущности, т.е. является просто удобным кратким описанием её характеристик. К термину "полиморфный тип" я отношусь примерно так же, как к "целочисленный" или там "32-битный". Т.е. он мне не более чем говорит о некой конкретной особенности этого типа.
   Если теперь вспомнить, для чего прилагательное "полиморфный" в контексте динамического полиморфизма добавляется к описанию классов с виртуальными методами, то с этой точки зрения любой тип в статическом полиморфизме является полиморфным. О чём тогда спор, я не знаю.

Сообщение отредактировано: Qraizer - 06.07.15, 23:15

Цитата Qraizer @ 06.07.15, 23:11

Я вошёл в спор с целью показать неверность вывода того хаскелиста (что кем он там являлся-то). Он взял некую сущность из одного языка и сравнил с похожей сущностью другого языка, проигнорировав тот факт, что эти сущности не просто разные, но и сферы их применения разные, и назначения тоже разные. Немудрено, что пришёл к неверному выводу.

Но вывод там в том, что на C++ такую проверку сделать нельзя. И ведь действительно нельзя.