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

[applegame]

Цитата Qraizer @ 14.07.15, 18:58

Канонично правильное – только в теории...

Это был сарказм. Ведь наши оппоненты как раз таки взяли некое определение ПП и считают его истной. Так сказать Канонично-Православный Полный Полиморфизм - КППП.

Сообщение отредактировано: applegame - 14.07.15, 19:37

[D_KEY]

Цитата Qraizer @ 14.07.15, 18:58

Увы, вопросы касательно разницы в твоих выводах о ПП и ДП в ровно одинаковых условиях ты проигнорировал.

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

Добавлено 14.07.15, 20:41

Цитата Qraizer @ 14.07.15, 18:58

applegame пытался решить и решил её, вы её зафейлили посредством изменений её условийй.

Какие условия были изменены?йй

Добавлено 14.07.15, 20:43

Цитата applegame @ 14.07.15, 18:23

Я сильно удивился, но у функции "foo a b = a + b" действительно тип "foo :: Num a => a -> a -> a"

Что тут удивительного? Как иначе ты предлагаешь типизировать? Как иначе разрешить вызов + ?

Добавлено 14.07.15, 20:55

Цитата applegame @ 14.07.15, 18:56

Может и так, придет korvin и D_KEY и аргументируют.

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

Цитата

А не каноничЪное ПП и в плюсах есть.

Есть ли? Вот я пытаюсь примерить твою точку зрения к плюсам, но выходит плохо, даже вот не знаю, является ли std::vector ПП типом? И тут дло даже не в bool, который ломает ПП явно. Что мы делаем с аллокаторами, компараторами, хеш-функциями, трейтами в параметрах стандартных контейнеров? Неужели это тоже ПП?

Добавлено 14.07.15, 20:58

Цитата Qraizer @ 14.07.15, 18:58

Об СП у тебя вообще поверхностные представления, как я погляжу

Возможно. Так укажи на ошибки и аргументируй свою позицию. Дай ссылки и цитаты.

[applegame]

Цитата D_KEY @ 14.07.15, 20:40

Как иначе ты предлагаешь типизировать? Как иначе разрешить вызов + ?

А в чем проблема? Даже мой сраный D может все типизировать в этом случае, а крутой Хаскель не может? Типизируется же функция map если ей подсунуть (+).

Добавлено 15.07.15, 03:56

Цитата D_KEY @ 14.07.15, 20:40

Есть ли? Вот я пытаюсь примерить твою точку зрения к плюсам, но выходит плохо, даже вот не знаю, является ли std::vector ПП типом? И тут дло даже не в bool, который ломает ПП явно. Что мы делаем с аллокаторами, компараторами, хеш-функциями, трейтами в параметрах стандартных контейнеров? Неужели это тоже ПП?

В твоем "хаскельном" понимании - нет. В общепринятом - да.

[D_KEY]

Цитата applegame @ 15.07.15, 03:50

А в чем проблема? Даже мой сраный D может все типизировать в этом случае

Не даже, а только он и c++ и могут. Потому, что шаблоны.

Цитата

Типизируется же функция map если ей подсунуть (+).

Ну так ты же передаёшь параметр.

Цитата

В общепринятом - да.

Что это ещё за общепринятое понимание? Я вот tapl цитировал, это общепринятое понимание?

И ты же сам говорил, что если если есть специализация, то значит нет ПП. Или я тебя не так понял?

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

[D_KEY]

Вот интересно, все ли тут согласны с

Цитата wiki

Some implementations of type polymorphism are superficially similar to parametric polymorphism while also introducing ad hoc aspects. One example is C++ template specialization.

И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре?

[Qraizer]

Цитата D_KEY @ 14.07.15, 20:40

Так укажи на ошибки и аргументируй свою позицию.

Касты являются проявлением СП, только диспетчером тут выступает сам программист. Ссылку на вики найти нетрудно.

Цитата D_KEY @ 15.07.15, 08:05

И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре?

Этот консенсус появился в теме давным давно, лень искать, но вроде бы за авторством MyNameIsIgor-я. Ты его разве не видел? Мы с applegame всю тему пытаемся показать, что реализация не имеет значения, главное получаемый эффект. И если рассматривать жизненный цикл шаблонов от определения до точки использования, ПП проявляется в полной мере. Если рассматривать цикл шире, за точку использования, то applegame всю тему пытается показать абсурдность этой позиции, т.к. на уровне исполняемого кода всё равно всегда и во всех языках будет АдХок. Я бы ещё добавил в исключения аппаратные реализации собственно языка (а также их эмуляторы в ряде случаев), но это уже технические детали. Я тоже апеллировал к ДП, который полиморфизм подтипов, ведь реализация даже в коде разбросана по разным методам (точнее, по перекрытым методам разных классов), а значит тоже АдХок (диспетчеризируемый в run-time обобщённым нетипизированным ПП-кодом, сгенерированным компилятором), и вот на этот счёт твои возражения мне вообще непонятны.
Ещё добавлю, что ПП не обязан обеспечивать работу кода для любого типа вообще, он может ограничить множество типов конечным набором, и от этого ПП быть не перестаёт. Впрочем, я об этом писал не один раз: если математически такие случаи описываются интуитивно, то язык программирования может предлагать для обеспечения подобных ограничений этого менее наглядные средства, включая метакод, специализации или run-time логику уровня ВМ.

Добавлено 15.07.15, 09:55

Цитата D_KEY @ 14.07.15, 20:40

Вот я пытаюсь примерить твою точку зрения к плюсам, но выходит плохо, даже вот не знаю, является ли std::vector ПП типом?

В общем случае нет, но таковыми являются его аргументы. В частных случаях, например, для std::stack<>, является.

Сообщение отредактировано: Qraizer - 15.07.15, 09:55

[applegame]

Цитата D_KEY @ 15.07.15, 06:21

Что это ещё за общепринятое понимание? Я вот tapl цитировал, это общепринятое понимание?

Да, в TAPL общепринятое понимание.
Но я не вижу в чем определение данное в TAPL противоречит моей точке зрения.
Ты приравниваешь два разных понятия: "функция f специализировна" и "функция f может быть специализирована".
Из TAPL ясно следует, что если функция специализирована (на уровне определения, а не на уровне бинарного кода), то она точно параметрически не полиморфна. Но я пока не нашел там упоминаний о том, что сама возможность специализировать уже декларированную параметрически полиморфную функцию - делает ее параметрически неполиморфной. Вот именно с этого момента заканчивается общепринятое понимание и начинается твое частное.

Цитата D_KEY @ 15.07.15, 08:05

И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре?

Эта цитата уже была приведена тобой, что-то не помогло

Добавлено 15.07.15, 10:03

Цитата Qraizer @ 15.07.15, 09:52

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

Чисто в хаскельном понимании у настоящей ПП-функции не должно быть ограничений типов в сигнатуре. И кстати опять повторюсь: в решении той задачи на Хаскеле нет ПП в хаскельном же понимании. Параметры фйнкции main' ограничены тайпклассом ScalarProduct. Получается, что эта задача имеет прямое отношение к полиморфной рекурсии, но не имеет никакого отношения к параметрическому полиморфизму. По крайней мере в хаскельном понимании.
Лично я склонен считать (как и Qraizer и MyNameIsIgor), что функция с сигнатурой "Num a => a -> a -> a" вполне параметрически полиморфна.

Сообщение отредактировано: applegame - 15.07.15, 10:05

[D_KEY]

Цитата Qraizer @ 15.07.15, 09:52

Цитата D_KEY @ 14.07.15, 20:40

Так укажи на ошибки и аргументируй свою позицию.

Касты являются проявлением СП, только диспетчером тут выступает сам программист. Ссылку на вики найти нетрудно.

Спасибо.

Цитата

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

Принято.

Цитата

Цитата D_KEY @ 15.07.15, 08:05

И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре?

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

Это я цитировал. Но тогда не комментировал.

Цитата

Мы с applegame всю тему пытаемся показать, что реализация не имеет значения, главное получаемый эффект.

Так эффект разный. Реализация не имеет значения для некоторых других языков, но не для C++, который обязуется делать специализации.

Цитата

И если рассматривать жизненный цикл шаблонов от определения до точки использования, ПП проявляется в полной мере.

Может стоит рассмотреть пример?

Цитата

Я тоже апеллировал к ДП, который полиморфизм подтипов, ведь реализация даже в коде разбросана по разным методам (точнее, по перекрытым методам разных классов), а значит тоже АдХок (диспетчеризируемый в run-time обобщённым нетипизированным ПП-кодом, сгенерированным компилятором), и вот на этот счёт твои возражения мне вообще непонятны.

Да, это ad-hoc. Какие возражения?
И да, в плюсах нет полиморфизма подтипов, если я правильно понимаю его.

Цитата

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

Это вопрос спорный. В Haskell, например, не так. И определение из tapl как раз ближе к такой трактовке.

[D_KEY]

Цитата applegame @ 15.07.15, 09:55

Да, в TAPL общепринятое понимание.
Но я не вижу в чем определение данное в TAPL противоречит моей точке зрения.

Вот в этом:

Цитата

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

Добавлено 15.07.15, 11:00
В стандарте C++ нет ни слова о параметрическом полиморфизме(или я ошибаюсь?). С тем, что имитация ПП есть в C++ вроде все согласны. Что вам еще нужно?

Добавлено 15.07.15, 11:11

Цитата applegame @ 15.07.15, 09:55

Ты приравниваешь два разных понятия: "функция f специализировна" и "функция f может быть специализирована".

Во-первых, в стандарте C++ говорится, что специализация будет создана компилятором, если ее не создаст программист. Цитаты в теме есть.
Во-вторых, еще раз говорю, из твоей позиции вытекает, что ты не в состоянии сказать, полиморфна ли функция, пока не перелопатишь весь код программы и не убедишься в отсутствии/наличии специализации? Ты уверен, что тут все в порядке?

Цитата

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

Сама возможность специализировать виртуальную функцию делает виртуальные функции механизмом ad-hoc полиморфизма. Тут аналогично.

Цитата

Лично я склонен считать (как и Qraizer и MyNameIsIgor), что функция с сигнатурой "Num a => a -> a -> a" вполне параметрически полиморфна.

Это вопрос спорный... Функция определена не на всех типах, а значит об однородности уже речи не идет. Но, допустим, мы будем считать ее параметрически полиморфной функцией, которая в своем коде уже вызывает ad-hoc полиморфный +.

[Qraizer]

Вот. Теперь по крайней мере нет противоречий в твоих постах.

[korvin]

Цитата applegame @ 14.07.15, 08:10

Ты полагаешь, что ее можно успешно засунуть в бинарную библиотеку оставив наружу только сигнатуру вкомпилировав в либу тело "a + b"? Как ты себе представляешь ABI, которое обеспечит вызов такой функции? Допустим ты сделаешь боксинг аргументов и передашь эти void* неизвестно с чем в либу. Полиморфная функция foo должна отправить эти void* в уже неполиморфную функцию "+", которой нужно знать как именно сложить эти аргументы. И тут получается облом - типы неизвестны.
Забавно, но Хаскель тебе не даст даже сигнатуру написать для такой функции, либо разрешит, но заставит указать принадлежность аргументов к тайпклассу, превратив таким образом функцию в параметрически неполиморфную.
ИМХО невозможно для параметрически полиморфной функции жестко отделить сигнатуру от реализации, ни в каком языке. Как компилятор на клиентской стороне будет делать тайп-чекинг если у него нет под рукой исходного кода этой функции? Мамой кланус эта функция умеет складывать целые числа, пиццу и кошек.

Не просто могу, а все функции в Хаскелле (в т.ч. и параметрически полиморфные) запиханы в библиотеки с торчащими наружу только сигнатурами. Как и в ML. Как и классы в Java и C#.

Хаскелл же не даст тебе написать такую функцию без указания тайпкласса, потому что (+) является методом тайпкласса. С тем же успехом ты мог бы жаловаться, что D/C++/whatever-static не даст тебе написать функцию

Object add(Object x, Object y) { return x + y; }

а потребует, например,

Number add(Number x, Number y) { return x + y; }

Сообщение отредактировано: korvin - 15.07.15, 13:15

[DarkEld3r]

"Кстати", в расте специализацию для дженериков хотят, наконец-то, добавить.