Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[13.59.100.42] |
|
Страницы: (33) « Первая ... 31 32 [33] ( Перейти к последнему сообщению ) |
Сообщ.
#481
,
|
|
|
Это был сарказм. Ведь наши оппоненты как раз таки взяли некое определение ПП и считают его истной. Так сказать Канонично-Православный Полный Полиморфизм - КППП.
|
Сообщ.
#482
,
|
|
|
Цитата Qraizer @ Увы, вопросы касательно разницы в твоих выводах о ПП и ДП в ровно одинаковых условиях ты проигнорировал. Я тебе на все ответил. Условия разные, на мой взгляд. И я указал почему. Добавлено Цитата Qraizer @ applegame пытался решить и решил её, вы её зафейлили посредством изменений её условийй. Какие условия были изменены?йй Добавлено Цитата applegame @ Я сильно удивился, но у функции "foo a b = a + b" действительно тип "foo :: Num a => a -> a -> a" Что тут удивительного? Как иначе ты предлагаешь типизировать? Как иначе разрешить вызов + ? Добавлено Мы сейчас конкретно за хаскель говорили. Возможно, определение и неверно. Но оно не противоречит ранее сказанному, скорее ужесточает. Цитата А не каноничЪное ПП и в плюсах есть. Есть ли? Вот я пытаюсь примерить твою точку зрения к плюсам, но выходит плохо, даже вот не знаю, является ли std::vector ПП типом? И тут дло даже не в bool, который ломает ПП явно. Что мы делаем с аллокаторами, компараторами, хеш-функциями, трейтами в параметрах стандартных контейнеров? Неужели это тоже ПП? Добавлено Возможно. Так укажи на ошибки и аргументируй свою позицию. Дай ссылки и цитаты. |
Сообщ.
#483
,
|
|
|
Цитата D_KEY @ А в чем проблема? Даже мой сраный D может все типизировать в этом случае, а крутой Хаскель не может? Типизируется же функция map если ей подсунуть (+). Как иначе ты предлагаешь типизировать? Как иначе разрешить вызов + ? Добавлено Цитата D_KEY @ В твоем "хаскельном" понимании - нет. В общепринятом - да. Есть ли? Вот я пытаюсь примерить твою точку зрения к плюсам, но выходит плохо, даже вот не знаю, является ли std::vector ПП типом? И тут дло даже не в bool, который ломает ПП явно. Что мы делаем с аллокаторами, компараторами, хеш-функциями, трейтами в параметрах стандартных контейнеров? Неужели это тоже ПП? |
Сообщ.
#484
,
|
|
|
Цитата applegame @ А в чем проблема? Даже мой сраный D может все типизировать в этом случае Не даже, а только он и c++ и могут. Потому, что шаблоны. Цитата Типизируется же функция map если ей подсунуть (+). Ну так ты же передаёшь параметр. Цитата В общепринятом - да. Что это ещё за общепринятое понимание? Я вот tapl цитировал, это общепринятое понимание? И ты же сам говорил, что если если есть специализация, то значит нет ПП. Или я тебя не так понял? |
Сообщ.
#485
,
|
|
|
Вот интересно, все ли тут согласны с
Цитата wiki Some implementations of type polymorphism are superficially similar to parametric polymorphism while also introducing ad hoc aspects. One example is C++ template specialization. И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре? |
Сообщ.
#486
,
|
|
|
Цитата D_KEY @ Касты являются проявлением СП, только диспетчером тут выступает сам программист. Ссылку на вики найти нетрудно.Так укажи на ошибки и аргументируй свою позицию. Цитата D_KEY @ И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре? Этот консенсус появился в теме давным давно, лень искать, но вроде бы за авторством MyNameIsIgor-я. Ты его разве не видел? Мы с applegame всю тему пытаемся показать, что реализация не имеет значения, главное получаемый эффект. И если рассматривать жизненный цикл шаблонов от определения до точки использования, ПП проявляется в полной мере. Если рассматривать цикл шире, за точку использования, то applegame всю тему пытается показать абсурдность этой позиции, т.к. на уровне исполняемого кода всё равно всегда и во всех языках будет АдХок. Я бы ещё добавил в исключения аппаратные реализации собственно языка (а также их эмуляторы в ряде случаев), но это уже технические детали. Я тоже апеллировал к ДП, который полиморфизм подтипов, ведь реализация даже в коде разбросана по разным методам (точнее, по перекрытым методам разных классов), а значит тоже АдХок (диспетчеризируемый в run-time обобщённым нетипизированным ПП-кодом, сгенерированным компилятором), и вот на этот счёт твои возражения мне вообще непонятны. Ещё добавлю, что ПП не обязан обеспечивать работу кода для любого типа вообще, он может ограничить множество типов конечным набором, и от этого ПП быть не перестаёт. Впрочем, я об этом писал не один раз: если математически такие случаи описываются интуитивно, то язык программирования может предлагать для обеспечения подобных ограничений этого менее наглядные средства, включая метакод, специализации или run-time логику уровня ВМ. Добавлено Цитата D_KEY @ В общем случае нет, но таковыми являются его аргументы. В частных случаях, например, для std::stack<>, является. Вот я пытаюсь примерить твою точку зрения к плюсам, но выходит плохо, даже вот не знаю, является ли std::vector ПП типом? |
Сообщ.
#487
,
|
|
|
Цитата D_KEY @ Да, в TAPL общепринятое понимание.Что это ещё за общепринятое понимание? Я вот tapl цитировал, это общепринятое понимание? Но я не вижу в чем определение данное в TAPL противоречит моей точке зрения. Ты приравниваешь два разных понятия: "функция f специализировна" и "функция f может быть специализирована". Из TAPL ясно следует, что если функция специализирована (на уровне определения, а не на уровне бинарного кода), то она точно параметрически не полиморфна. Но я пока не нашел там упоминаний о том, что сама возможность специализировать уже декларированную параметрически полиморфную функцию - делает ее параметрически неполиморфной. Вот именно с этого момента заканчивается общепринятое понимание и начинается твое частное. Цитата D_KEY @ И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре? Эта цитата уже была приведена тобой, что-то не помогло Добавлено Цитата Qraizer @ Чисто в хаскельном понимании у настоящей ПП-функции не должно быть ограничений типов в сигнатуре. И кстати опять повторюсь: в решении той задачи на Хаскеле нет ПП в хаскельном же понимании. Параметры фйнкции main' ограничены тайпклассом ScalarProduct. Получается, что эта задача имеет прямое отношение к полиморфной рекурсии, но не имеет никакого отношения к параметрическому полиморфизму. По крайней мере в хаскельном понимании.Ещё добавлю, что ПП не обязан обеспечивать работу кода для любого типа вообще, он может ограничить множество типов конечным набором, и от этого ПП быть не перестаёт. Лично я склонен считать (как и Qraizer и MyNameIsIgor), что функция с сигнатурой "Num a => a -> a -> a" вполне параметрически полиморфна. |
Сообщ.
#488
,
|
|
|
Цитата Qraizer @ Цитата D_KEY @ Касты являются проявлением СП, только диспетчером тут выступает сам программист. Ссылку на вики найти нетрудно.Так укажи на ошибки и аргументируй свою позицию. Спасибо. Цитата Приведение типов представляет собой семантический механизм, осуществляемый для преобразования фактического типа аргумента к ожидаемому функцией, при отсутствии которого произошла бы ошибка типизации. То есть при вызове функции с приведением типа происходит исполнение различного кода для различных типов (предваряющего вызов самой функции). Принято. Цитата Цитата D_KEY @ И не является ли это консенсусом или хотя бы компромиссом в нашем холиваре? Этот консенсус появился в теме давным давно, лень искать, но вроде бы за авторством MyNameIsIgor-я. Это я цитировал. Но тогда не комментировал. Цитата Мы с applegame всю тему пытаемся показать, что реализация не имеет значения, главное получаемый эффект. Так эффект разный. Реализация не имеет значения для некоторых других языков, но не для C++, который обязуется делать специализации. Цитата И если рассматривать жизненный цикл шаблонов от определения до точки использования, ПП проявляется в полной мере. Может стоит рассмотреть пример? Цитата Я тоже апеллировал к ДП, который полиморфизм подтипов, ведь реализация даже в коде разбросана по разным методам (точнее, по перекрытым методам разных классов), а значит тоже АдХок (диспетчеризируемый в run-time обобщённым нетипизированным ПП-кодом, сгенерированным компилятором), и вот на этот счёт твои возражения мне вообще непонятны. Да, это ad-hoc. Какие возражения? И да, в плюсах нет полиморфизма подтипов, если я правильно понимаю его. Цитата Ещё добавлю, что ПП не обязан обеспечивать работу кода для любого типа вообще, он может ограничить множество типов конечным набором, и от этого ПП быть не перестаёт. Это вопрос спорный. В Haskell, например, не так. И определение из tapl как раз ближе к такой трактовке. |
Сообщ.
#489
,
|
|
|
Цитата applegame @ Да, в TAPL общепринятое понимание. Но я не вижу в чем определение данное в TAPL противоречит моей точке зрения. Вот в этом: Цитата Параметрические определения однородны: все экземпляры данного фрагмента кода ведут себя одинаково. Добавлено В стандарте C++ нет ни слова о параметрическом полиморфизме(или я ошибаюсь?). С тем, что имитация ПП есть в C++ вроде все согласны. Что вам еще нужно? Добавлено Цитата applegame @ Ты приравниваешь два разных понятия: "функция f специализировна" и "функция f может быть специализирована". Во-первых, в стандарте C++ говорится, что специализация будет создана компилятором, если ее не создаст программист. Цитаты в теме есть. Во-вторых, еще раз говорю, из твоей позиции вытекает, что ты не в состоянии сказать, полиморфна ли функция, пока не перелопатишь весь код программы и не убедишься в отсутствии/наличии специализации? Ты уверен, что тут все в порядке? Цитата Но я пока не нашел там упоминаний о том, что сама возможность специализировать уже декларированную параметрически полиморфную функцию - делает ее параметрически неполиморфной. Сама возможность специализировать виртуальную функцию делает виртуальные функции механизмом ad-hoc полиморфизма. Тут аналогично. Цитата Лично я склонен считать (как и Qraizer и MyNameIsIgor), что функция с сигнатурой "Num a => a -> a -> a" вполне параметрически полиморфна. Это вопрос спорный... Функция определена не на всех типах, а значит об однородности уже речи не идет. Но, допустим, мы будем считать ее параметрически полиморфной функцией, которая в своем коде уже вызывает ad-hoc полиморфный +. |
Сообщ.
#490
,
|
|
|
Вот. Теперь по крайней мере нет противоречий в твоих постах.
|
Сообщ.
#491
,
|
|
|
Цитата applegame @ Ты полагаешь, что ее можно успешно засунуть в бинарную библиотеку оставив наружу только сигнатуру вкомпилировав в либу тело "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; } |
Сообщ.
#492
,
|
|
|
"Кстати", в расте специализацию для дженериков хотят, наконец-то, добавить.
|