Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.119.107.161] |
|
Страницы: (33) « Первая ... 30 31 [32] 33 ( Перейти к последнему сообщению ) |
Сообщ.
#466
,
|
|
|
Я тебе так же рекомендую освежить/приобрести теоретические знания. И не только о плюсах. За всю тему ты, к сожалению, не сказал ничего полезного.
Добавлено Где аргументация? Где ссылка на литературу(конкретная), где цитаты? Цитата Шаблоны; не являются; средством; какого-то там полиморфизма Они являются механизмом генерации кода с поддержкой ad-hoc полиморфизма относительно параметров. Возможностей шаблонов достаточно для того, чтобы имитировать параметрический полиморфизм при определённых условиях(нарушаемых даже стандартной библиотекой с ее vector<bool>). |
Сообщ.
#467
,
|
|
|
Принято, D_KEY. Я удовлетворён. applegame, думаю, тоже.
P.S. Использование временных ограничений возможностей оппонента; сознательный игнор предложений почитать литературу; непризнание авторитетами людей с мировым именем; в конце концов нежелание поискать в Стандарте банальное "if implicit" и "if explicit" – поздравляю с принятием в ряды хейтерованных. |
Сообщ.
#468
,
|
|
|
Цитата Qraizer @ сознательный игнор предложений почитать литературу; непризнание авторитетами людей с мировым именем; в конце концов нежелание поискать в Стандарте банальное "if implicit" и "if explicit" Хорошо себя описал. Ещё стоит добавить завышееное ЧСВ и будет ок. |
Сообщ.
#469
,
|
|
|
Цитата Qraizer @ Чисто из любопытства: что должно было найтись? А то поискал в драфте 14 стандарта и ничего. "if implicit" и "if explicit" |
Сообщ.
#470
,
|
|
|
Цитата Qraizer @ Принято, D_KEY. Я удовлетворён. applegame, думаю, тоже. applegame свою позицию старается аргументировать. Он пытался решить задачу и показывал код. Мы вместе разбирали код примеров и пр. А от тебя что было в этой теме? Добавлено Цитата Qraizer @ Использование временных ограничений возможностей оппонента Каким образом я это использовал? Я тебе ясно написал, что никто тебя не торопит и ты можшь ответить когда угодно, хоть через месяц написать. |
Сообщ.
#471
,
|
|
|
Не понимаю тебя. Функция сложения параметрически неполиморфна, но она вполне ad-hoc полиморфна. Например в Haskell функция сложения является членом тайпкласса Num, для которого созданы инстансы для различных типов. Вот компилятор и выберет нужную версию или динамически диспетчеризует ее.
Цитата D_KEY @ То есть ты полагаешь, что функция "foo a b = a + b" параметрически не полиморфна, потому что в ней вызывается параметрически неполиморфная функция сложения?Я оспариваю корректность вызова функции сложения в параметрически полиморфной функции. Доказать не могу, возможно ошибаюсь. Но жду от тебя пример простенькой параметрически полиморфной функции, которая бы в итоге не вызывала параметрически неполиморфную функцию. Цитата D_KEY @ Не понимаю вопроса.applegame, любая генерация кода по некоторым параметрам является параметрическим полиморфизмом? Цитата Qraizer @ Ну это по-сути и есть тело шаблона, просто упакованное в дерево. Если это дерево сериализовать и запихать в бинарную библиотеку, то наверное да, можно будет экспортировать только сигнатуру шаблона. Но это какой-то изврат однако Может. Тела шаблона для этого не требуется, достаточно сгенерённого грамматического дерева, каковое полностью строится в точке определения, а не инстанцирования. |
Сообщ.
#472
,
|
|
|
Цитата applegame @ Функция сложения параметрически неполиморфна, но она вполне ad-hoc полиморфна Ясно, просто ты написал "неполиморфна" и я тебя неверно понял. Цитата Цитата D_KEY @ То есть ты полагаешь, что функция "foo a b = a + b" параметрически не полиморфна, потому что в ней вызывается параметрически неполиморфная функция сложения?Я оспариваю корректность вызова функции сложения в параметрически полиморфной функции. В ней просто так нельзя вызвать функцию сложения. Для этого тебе нужно указать ограничение/тайпкласс/интерфейс. Но смотрим https://wiki.haskell.org/Polymorphism#Param...ic_polymorphism Цитата Parametric polymorphism refers to when the type of a value contains one or more (unconstrained) type variables, so that the value may adopt any type that results from substituting those variables with concrete types. И Цитата In Haskell, this means any type in which a type variable, denoted by a name in a type beginning with a lowercase letter, appears without constraints (i.e. does not appear to the left of a =>). In Java and some similar languages, generics (roughly speaking) fill this role. Цитата Доказать не могу, возможно ошибаюсь. Но жду от тебя пример простенькой параметрически полиморфной функции, которая бы в итоге не вызывала параметрически неполиморфную функцию. id, map, etc. Много их. |
Сообщ.
#473
,
|
|
|
Полиморфную функцию сложения в хаскле можно написать так.
add :: a -> a -> (a -> a -> a) -> a add l r plus = plus l r И мне не очень понятно, почему, если я сделаю так add :: Num a => a -> a -> a add l r = l + r то параметрический полиморфизм вдруг исчезает? Почему если я передаю функцию, это полиморфизм, если за меня делает компилятор, то не полиморфизм |
Сообщ.
#474
,
|
|
|
Цитата D_KEY @ Как это нельзя? Очень даже можноЭто уже обсуждалосьВ ней просто так нельзя вызвать функцию сложения. Для этого тебе нужно указать ограничение/тайпкласс/интерфейс. Цитата D_KEY @ id пожалуй да, ничего не делает, просто возвращает то что получила на вход. Как и множество функций возвращающие одно и тоже значение вне зависимости от аргумента. Но возьмем map, эта функция уже работает с элементами списка, и если например она к ним прибавляет 1, то вот тебе и ad-hoc полиморфизм: http://ideone.com/rno7V2 id, map, etc. Много их. Добавлено Цитата MyNameIsIgor @ Это не функция сложения. Полиморфную функцию сложения в хаскле можно написать так. |
Сообщ.
#475
,
|
|
|
Цитата applegame @ Цитата D_KEY @ Как это нельзя? Очень даже можноВ ней просто так нельзя вызвать функцию сложения. Для этого тебе нужно указать ограничение/тайпкласс/интерфейс. Выпиши тип функции и прочти определение, что я цитировал. Цитата id пожалуй да, ничего не делает, просто возвращает то что получила на вход. Как и множество функций возвращающие одно и тоже значение вне зависимости от аргумента. Но возьмем map, эта функция уже работает с элементами списка, и если например она к ним прибавляет 1, то вот тебе и ad-hoc полиморфизм: http://ideone.com/rno7V2 Нет тут ad-hoc полиморфизма. Ты вызвал параметрически полиморфную функцию map над списком чисел и передал ей функцию, работающую с типами, соответствующими Num. ad-hoc тут уже в самой функции, а не в map. |
Сообщ.
#476
,
|
|
|
Цитата applegame @ Цитата MyNameIsIgor @ Это не функция сложения.Полиморфную функцию сложения в хаскле можно написать так. Это в том числе и функция сложения. И таки я не понял: а каким образом эта фраза отвечает на мой вопрос? |
Сообщ.
#477
,
|
|
|
Цитата MyNameIsIgor @ Эта фраза не отвечает на вопрос, потому что эта фраза отвечала на твою фразу, в которой не было никакого вопроса.И таки я не понял: а каким образом эта фраза отвечает на мой вопрос? Цитата D_KEY @ Ты мои посты вообще читаешь? Это определение я прочитал раньше тебя.Выпиши тип функции и прочти определение, что я цитировал. По по поводу типов ты оказался прав. Я сильно удивился, но у функции "foo a b = a + b" действительно тип "foo :: Num a => a -> a -> a", то бишь она параметрически неполиморфна. Но это ладно. Потом я попытался создать полиморфную функцию сложения аналогично предложенному MyNameIsIgor добавив каррирование функции +. Результат меня еще больше удивил: Prelude> let { foo :: (a -> a -> a) -> a -> a -> a; foo f a b = f a b } Prelude> :t foo foo :: (a -> a -> a) -> a -> a -> a Prelude> foo (+) 0.5 0.4 0.9 Prelude> let bar = foo (+) Prelude> :t bar bar :: Integer -> Integer -> Integer <<<<<<<<<<<<<<<<<<<<<<<<< WTF?! Prelude> bar 0.5 0.4 <interactive>:53:5: No instance for (Fractional Integer) arising from the literal `0.5' Possible fix: add an instance declaration for (Fractional Integer) In the first argument of `bar', namely `0.5' In the expression: bar 0.5 0.4 In an equation for `it': it = bar 0.5 0.4 |
Сообщ.
#478
,
|
|
|
Цитата applegame @ Я сильно удивился, но у функции "foo a b = a + b" действительно тип "foo :: Num a => a -> a -> a", то бишь она параметрически неполиморфна. Что-то все эту фразу из какой-то странной вики по хаскелю приняли на веру, но пока нет никаких пруфов - это тупой вброс. Цитата applegame @ Потом я попытался создать полиморфную функцию сложения аналогично предложенному MyNameIsIgor добавив каррирование функции + На самом деле вы частично применили функцию foo, передав ей функцию + Цитата applegame @ Результат меня еще больше удивил Почему-то был взят первый тип, удовлетворяющий Num. Если явно задать bar :: Num a => a -> a -> a, то всё нормально. |
Сообщ.
#479
,
|
|
|
Цитата MyNameIsIgor @ Может и так, придет korvin и D_KEY и аргументируют. Это же каноничъно-православное определение ПП. А не каноничЪное ПП и в плюсах есть.Что-то все эту фразу из какой-то странной вики по хаскелю приняли на веру, но пока нет никаких пруфов - это тупой вброс. Цитата MyNameIsIgor @ Вроде это и называется каррирование. Нет?На самом деле вы частично применили функцию foo, передав ей функцию + Цитата applegame @ добавив каррирование функции + Цитата MyNameIsIgor @ Это и странно.Почему-то был взят первый тип, удовлетворяющий Num. Вот так тоже весело |
Сообщ.
#480
,
|
|
|
Цитата D_KEY @ Я тоже старался. Увы, вопросы касательно разницы в твоих выводах о ПП и ДП в ровно одинаковых условиях ты проигнорировал. Об СП у тебя вообще поверхностные представления, как я погляжу. Вообще, не надо мешать в один клубок два разных вопроса: быть или не быть ПП в Плюсах, и как решить вон ту задачу. applegame пытался решить и решил её, вы её зафейлили посредством изменений её условий.applegame свою позицию старается аргументировать. Он пытался решить задачу и показывал код. Мы вместе разбирали код примеров и пр. А от тебя что было в этой теме? От меня в этой теме было достаточно. D_KEY, если считаешь, что в теме, напиши условие задачи на математическом языке, и внимательно на него посмотри. Потом перечитай тему. Желательно целиком. Добавлено Цитата applegame @ Канонично правильное – только в теории. На практике обязательно должны будут присутствовать те или иные ограничения, неважно, как конкретно и где конкретно реализованные. Хоть в метакоде программера, хоть в компиляторе, хоть в языке. Знаешь ли, double тоже плохо подходит для реализации арифметического Хаффмана, хотя в теории всё выглядит очень красиво. Это же каноничъно-православное определение ПП. А не каноничЪное ПП и в плюсах есть. |