Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В этом разговоре речь шла не об определении самих типов, структура которых, в данном случае, определяется на этапе написания программы, а об определении совместимости типов во время вызова функции. При этом совместимость, очевидно, проверяется по структуре типа, а не по его имени, которого у него нет.

Это называется слабой типизацией. И это уже тема другого разговора.

VladD2:

> ПК> В этом разговоре речь шла не об определении самих типов, структура которых, в данном случае, определяется на этапе написания программы, а об определении совместимости типов во время вызова функции. При этом совместимость, очевидно, проверяется по структуре типа, а не по его имени, которого у него нет.

> Это называется слабой типизацией. И это уже тема другого разговора.

Это называется ad-hoc полиморфизм для выбора функции (в данном случае использование pattern matching) + параметрический полиморфизм типов (полиморфная система типов функционального языка) + динамическая проверка типов. К слабой типизации это отношения не имеет.

VladD2:

> ПК> Главное, что об этом не было бы известно в точке использования определенных таким образом функций. В случае pattern matching в параметрах это так, в случае if это не так. Наличие явных определений всех функций просто означает, что это форма ближе к ad-hoc полиморфизму, наравне с перегрузкой, а не к параметрическому полиморфизму, как это имеет место, когда одна и та же функция может работать с данными разных типов.

> Эдакий полиморфизм можно сделать зи ифа написав один макрос.

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

> Пока что я придерживаюсь мнения о том, что полиморфизм — это работа с объектами разных типов одинаковыми метадами. А паттерн-матчикнг — это работа со с разными значениями одного типа одинаковыми метадами.

Хорошо. В таком случае вопрос: структура из двух элементов, и список из двух элементов — это два разных типа, или два разных значения одного типа?

Quintanar:

> ПК>Давай лучше рассмотрим несколько более близкий пример. Вот как, например, в языке Ада можно определять подтипы целого:
> ПК>

> ПК>subtype NonNegativeInt is INTEGER range 0 .. INTEGER'LAST;
> ПК>subtype NegativeInt is INTEGER range INTEGER'FIRST .. -1;
> ПК>

>
> Фишка в том, что в ФЯ нельзя определять подтипы, поэтому такое рассуждение для них не подходит.

Дык, тут не дело в определении подтипов (*), а в определении типов (не важно, являются ли они подтипами некоторого другого), выбор из которых происходит в соответствии с их структурой/значением, а не с именем, которого у них может и не быть.

> Полиморфные там только функции, паттерн-матчинг — это лишь способ декомпозиции сложных типов. Если взять и делать вид, что он выделяет некий подтип, то в рантайме мы нарвемся на ошибку non exhaustive pattern, а некоторые языки даже нервничают, если pattern неполный и пишут warnings. То, что тут писали выше (pattern matching при определении функций) это вовсе не перегрузка или что-либо еще, это syntactic sugar. Такое обявление
>

> func pat1 = ..
> func pat2 = ..
> ...
>

> эквивалентно
>

> func x = case x of
>  pat1 -> ..
>  pat2 -> ..
> ..
>

> Так что в ФЯ ПМ никак не является формой полиморфизма.

Конечно, сам по себе pattern matching формой полиморфизма не является. Полиморфизмом (ad-hoc, если быть точным) является предоставление набора функций с критериями выбора одной из них по "типу" аргумента/аргументов (в данном случае динамическому).

Интересно, что в C++ есть в некотором роде похожая техника. Сводится она к тому, что можно предоставить набор перегруженных шаблонов функций, выбор среди которых будет производиться на основании некоторого предиката от типа аргумента шаблона:

template <class T>
void foo(T t, typename enable_if< is_arithmetic<T> >::type* = 0);

template <class T>
void foo(T t, typename enable_if< is_floating<T> >::type* = 0);

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

По своим возможностям, конечно, техника очень далека от pattern matching ввиду того, что является побочным эффектом определения языка, но, тем не менее, имхо, сходство очевидно.

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

И точно так же, как pattern matching, сама по себе используемая функциональность (SFINAE — Substitution Failure Is Not An Error), к полиморфизму отношение имеет весьма опосредованное. Однако в сочетании с перегрузкой функций позволяет проделывать аналогичные вещи, с той разницей, что выбор функции производится во время компиляции, а не во время выполнения.

---

(*) Хотя работы по добавлению в функциональные языки подтипов уже давно были написаны: http://portal.acm.org/citation.cfm?id=62702 http://www.cs.chalmers.se/~hallgren/lic-abstract.html и, по-моему, по крайней мере, экспериментальные реализации тоже были сделаны.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Nick_, Вы писали:

N_>>Например, что такое список? Можно рассматривать список как тип, а можно как результат функции Cons (конструктор списка).

VD>Экземляры списков — это значения. Список позволяющий хранить элементы некоторого типа — это тип. Списко позволяющий хранить списки любого типа можно рассматривать как список хнанящий ссылки на некий базовый тип. Стало быть он тоже является одним типом, какие бы элементы в нем не находились.

При чем тут базовый тип? Что такое вообще базовый тип? Ты про наследование? При чем тут вообще наследование? Полиморфизм от наследования никак не зависит.

N_>>Тогда и полиморфизм можно свести к паттерн матчингу

N_>>length Cons a b = 1 + length b
N_>>length x = 1

VD>И все же это явный перебор. Перегрузка и патерн-матчинг четко разделяются и зачем их смешивать совершенно не ясно. Я собственно не спорю с тем, что патерн-матчинг — это интересное решение и красивая идея. Но с полиморфизмом ее путать не надо. Иначе так можно перемешать все понятия.

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК> понятие полиморфизма "родилось" именно в одном из функциональных языков, в ML, в 1976 г.
Ели быть совсем уж точным, понятие полиморфизма "родилось" чуть раньше, в CPL.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Павел Кузнецов, Вы писали:

VD>Кстати, расматрение значений как типов определяемых на время вызова процедуры — это прямейшее нарушение принципов инкапсуляции. Хотя это понятие из области ООП, и слабо применимо к ФЯ, но печальные последствия при таком взгляде на жизнь не заставят себя долго ждать. Рано или поздно будут сделаны неверные предположения о "динамическом типе". На то и были придуманы приципы ООП, чтобы материализовывать все свои окраничения и предположения в рамках понтия объекта и его типа.

Такс, не мог бы ты привести примерчик нарушения инкапсуляции в ФЯ? Интересно, однако...
Как это ф. программисты вот уже полстолетия слона не замечают.
(твой пример про диапазоны "не катит", т.к. не знаю я таких ФЯ, где бы они были, типы определяются, имхо, до "целое", "с плав. запятой", "строка" и т.п.)

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Sinclair, Вы писали:

S>>С абстрактно-философской точки зрения, тем не менее, я считаю трактовку паттерн-матчинга как средства достижения полиморфизма вполне корректной. Да, ты абсолютно прав: мы можем а) предоставить функцию для работы с аргументами независимо от их типа и б) автоматически выбирать реализацию функции в зависимости от ее аргументов.

VD>Тогда банальный if — это тоже полиморфизм.
Конечно, если if применяется для определения типа. Это так называемый "исскуственный полиморфизм". Термин взят не из википедий, а из работ господина Калиниченко, где излагается законченная теория типа (google. Это было в 99 году, так что ссылок не помню). И вот эта функция funct( void * ) тоже может быть полиморфной, если внутри делаются разные действия в зависимости от фактического значения (типа) аргумента. Впрочем, если ты внимательно прочтешь свое определение из википедии (а не будешь продолжать оперировать своим интуитивным представлением о полиморфизме), то вопрос должен уйти сам собой, так там нет никаких противоречий с явной проверкой типа.

Это было во первых. А во вторых, совершенно не понятно, причем здесь if. Паттерн-матчинг в моих примерах про дерево применяется только для того, чтобы различать разные типы, и является частью сигнатур функций, что является прямым аналогом "виртуальных функций". Вот тебе тот же пример со строгой типизацией (Хиндли-Милнер):

data Tree = Node Integer Tree Tree | Leaf Integer

sum Node value left right = value + sum left + sum right
sum Leaf value = value

Вот взять, например, замечательный язык Nemerle под платформу .NET. В нем для типа Tree будет создан базовый класс, в то время как для Node и Leaf будут созданны подклассы. Я и пример подобрал специально, чтобы было прямое соответствие. Не знаю, что надо сделать, чтобы объяснить лучше.

Здравствуйте, VladD2, Вы писали:

ПК>>Главное, что об этом не было бы известно в точке использования определенных таким образом функций. В случае pattern matching в параметрах это так, в случае if это не так. Наличие явных определений всех функций просто означает, что это форма ближе к ad-hoc полиморфизму, наравне с перегрузкой, а не к параметрическому полиморфизму, как это имеет место, когда одна и та же функция может работать с данными разных типов.
VD>Извини, но это чушь. Эдакий полиморфизм можно сделать зи ифа написав один макрос.
Это все языком. ((с) Ты)

>>> И вообще, ОО-теории хреново воспринимаются функциональщиками.
ПК>>Полиморфизм не требует ООП. Более того, понятие полиморфизма "родилось" именно в одном из функциональных языков, в ML, в 1976 г. Так что ОО в данном случае — переход на другую тему.
VD>А я и не утрверждал, что с полиморфизмом в ФЯ есть какие-то проблемы. Пробелмы имеются с инкапсуляцией и вообще с восприятием ООП как идиомы.
Извини, но это чушь. ((с) Тоже из тебя. Причем очень к месту, так как чушь редкостная, такую не каждый день услышишь)

VD>Нет никаких типов по значению. Есть типы и есть экземляры этих типов. Значения могут быть только в экземплярах. Иначе это уже вакханалия. Тип затем и был придуман, чтобы работать с ним как с доменом, а не как с набором значений. Большинство языки о которых идет речь реализуют совершенно обыкновенную систему типов. Тот же Окамл даже классы поддерживает. В них есть понятие перегрузки. И оно четко отделяется от понятия паттерн-матчинга.
Да ладно, Влад, хватит ломать комедию. Ну не знаешь ты что такое паттерн-матчинг ("аналог операции ветвления" — гы! ), и ни одного ФЯ (какой окамл, ты даже элементарный tuple в моих примерах распознать не смог), и ни "совершенно обыкновенной системы типов" Хиндли-Милнера. И теории типа тоже. Сейчас уже можешь ничего не говорить, поздно — ты в постах своих уже все сказал и во всем расписался. Уже весь форум в курсе, а ты тут продолжаешь изображать знатока .

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

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

> ПК> понятие полиморфизма "родилось" именно в одном из функциональных языков, в ML, в 1976 г.

> Ели быть совсем уж точным, понятие полиморфизма "родилось" чуть раньше, в CPL.

Да, действительно, сам полиморфизм родился ранее. Поправка принята. Правда, термин, насколько я понимаю, родился позже, но это не суть важно.

Здравствуйте, Gaperton, Вы писали:

VD>>Тогда банальный if — это тоже полиморфизм.
G>Конечно,

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

G> если if применяется для определения типа.

Тогда паттерн-мтчинг и полиморфизм есть во всех языках так как if может применяться для чего угодно.

Надо все же разделять классификацию возможностей и цели их применения. Нет ни одного языка программирования на котором можно было написать то, что нельзя реализовать на С. Но это не делает С ни ФЯ, ни ООЯ.

G>Это было во первых. А во вторых, совершенно не понятно, причем здесь if. Паттерн-матчинг в моих примерах про дерево применяется только для того, чтобы различать разные типы,

Это не патерн-матчинг. Это перегрузка функций. Или, если трактовать все расширительно, то паттерн-матчинг есть в любом ООЯ.

G> и является частью сигнатур функций, что является прямым аналогом "виртуальных функций". Вот тебе тот же пример со строгой типизацией (Хиндли-Милнер):

G>

G>data Tree = Node Integer Tree Tree | Leaf Integer

G>sum Node value left right = value + sum left + sum right
G>sum Leaf value = value
G>

Это перегрузка функций по типу. Просто в ООЯ она записывается несколько по другому.

Здравствуйте, Nick_, Вы писали:


N_>При чем тут базовый тип? Что такое вообще базовый тип? Ты про наследование? При чем тут вообще наследование? Полиморфизм от наследования никак не зависит.

Отсуствие наследования где-то еще не отменяет принципа родовой принадлежности.

N_>Приведу пример на С++. Есть перегрузка, а есть параметры по умолчанию. С помощью перегрузки можно сделать параметры по умолчанию. Если перегрузку и параметры по умолчанию не "путать", то в язык можно засунуть и то и другое. Вот так и получаются неоднозначности в языке.

И перегрузка, и параметры по умолчанию — это решение одной и той же проблемы. Это все по сути перегрузка. Собственно плохо или хорошо совмещать их в одном зыке вопрос спорный. В Шарпе и Яве решили, что плохо. Я первое время мучился, но потом привык и особых проблем не возникает. Правда у меня их и в С++ не возникало. Так что скорее вопрос привычки и к данной теме он вряд ли относится.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Ок, продемонстрируй. При этом множество типов должно быть расширяемым без модификации этого макроса, путем определения функций, среди которых производится выбор.

А типы то с какого должны расширяться. Или мы снова про коника?

>> Пока что я придерживаюсь мнения о том, что полиморфизм — это работа с объектами разных типов одинаковыми метадами. А паттерн-матчикнг — это работа со с разными значениями одного типа одинаковыми метадами.

ПК>Хорошо. В таком случае вопрос: структура из двух элементов, и список из двух элементов — это два разных типа, или два разных значения одного типа?

Два разных. Более того две структуры тоже два разных типа. И два списка с разными типами элементов тоже разные типы (если конечно тип списка определен заранее, и она не полиморфная).

Здравствуйте, Gaperton, Вы писали:

G>Скромнее надо быть, Влад.

Будь.

G>Смешно и грустно твои посты читать. Неудобно прям за тебя становится.

Не читай. Чем твоих постов мньше, тем меньше флэйма.

G>Лучше разговоров с тобой избегать, как и чтения твоих постов. Для верности. Чем я и собираюсь заняться с этого момента. Все мои просьбы ты проигнорировал, так что мое время для тебя кончилось.

Ловлю тебя на слове. Буду надеяться, что это не очередные громкие слова.

Здравствуйте, Курилка, Вы писали:

К>Такс, не мог бы ты привести примерчик нарушения инкапсуляции в ФЯ? Интересно, однако...

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

Ты лучше покажи мне хтя бы одно средство инкапсуляции в ФЯ, кроме разве что вариантрых типов. Есть конечно языки впитавшие в себя ОО-принципы, но в этом вряд ли заслуга именно ФЯ.

К>Как это ф. программисты вот уже полстолетия слона не замечают.

Да шишники вот уже 35 лет слона не замечают. Хотя не все. Многие просто чисто интиуитивно переползают на более совершенные с точки зрения инкапсуляции языки вроде С++, Явы, Шарпа...

К>(твой пример про диапазоны "не катит", т.к. не знаю я таких ФЯ, где бы они были, типы определяются, имхо, до "целое", "с плав. запятой", "строка" и т.п.)

Дык потому их и нет. На любом ООЯ можно создать подобный тип просто штатными средствами. Я просто пытался написать максимально простой псевда-код. В реальной жизни диапазон прийтеся инкапсулировать в класс, а управлять им методами и операторами.

В большинстве же ФЯ мне прийдется объявить переменную подходящего типа, а ее значение контролировать средствами вроде паттерн-матчинга, ифов, кейсов и т.п. В любой момент я могу ошибиться и компилятор мне ничем не поможет, так как без инкапсуляции он просто не в силах предугадать что же я собственно хотел.

Здравствуйте, Павел Кузнецов, Вы писали:

>> Так что в ФЯ ПМ никак не является формой полиморфизма.

ПК>Конечно, сам по себе pattern matching формой полиморфизма не является.

Читал... долго думал... То ли это такой способ признать свою неправоту, то еще что. Но забавно.

VladD2:

>>> Так что в ФЯ ПМ никак не является формой полиморфизма.

> ПК>Конечно, сам по себе pattern matching формой полиморфизма не является.

> Читал... долго думал... То ли это такой способ признать свою неправоту, то еще что. Но забавно.

А где я утверждал, что pattern matching является формой полиморфизма?

Речь шла об использовании pattern matching для получения полиморного поведения. Результат такого использования — да, является вариантом полиморфизма. Точно так же механизм SFINAE полиморфизмом не является, но может быть использован для реализации полиморфизма в сочетании с перегрузкой шаблонов функций.

Кстати, Gaperton тебе о том же уже давно говорит (http://rsdn.ru/forum/?mid=880919):

Автор: Gaperton
Дата: 02.11.04

А паттерн-матчинг я за полиморфизм не принимаю, это разные вещи. Применение паттерн-матчинга при задании аргументов функции — вот это является одним из самых мощных способов достижения полиморфизма в ФЯ.

VladD2:

> ПК> Ок, продемонстрируй. При этом множество типов должно быть расширяемым без модификации этого макроса, путем определения функций, среди которых производится выбор.

> А типы то с какого должны расширяться.

Потому что в противном случае ты будешь решать другую задачу.

>>> полиморфизм — это работа с объектами разных типов одинаковыми метадами. А паттерн-матчикнг — это работа со с разными значениями одного типа одинаковыми метадами.

> ПК> структура из двух элементов, и список из двух элементов — это два разных типа, или два разных значения одного типа?

> Два разных.

Тогда почему вот это по твоему утверждению не полиморфизм?

poly_function( { A, B } ) -> ...;
poly_function( [ A, B ] ) -> ...;

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>А где я утверждал, что pattern matching является формой полиморфизма?

Практически во всех сообщениях этой темы.
Например: Re[17]: Какой полиморфизм используется в ФЯ?

Автор: Павел Кузнецов
Дата: 04.11.04

Таким образом, я вполне согласен с Gaperton'ом, когда он относит использование pattern matching при описании параметров функции к разновидности полиморфизма, т.к. в итоге будет выбрана соответствующая функция на основании типа аргумента (в общем смысле).

ПК>Речь шла об использовании pattern matching для получения полиморного поведения.

Неправда. Речь, шал о неверной использовании термина полиморфизм. Речь вообще о полиморфизме в ФЯ (см. тему).

ПК> Результат такого использования — да, является вариантом полиморфизма.

Угу. Как и if. Не надо все доводить до состояния коника в вакууме.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Тогда почему вот это по твоему утверждению не полиморфизм?
ПК>

ПК>poly_function( { A, B } ) -> ...;
ПК>poly_function( [ A, B ] ) -> ...;
ПК>

А что ты под этим понимашь? Если { A, B } — это картэж, а [ A, B ] — это список, то это несомненно полиморфная функция, а операция называется перегрузкой. В вот если будте, как-то так:

poly_function( [] )       -> ...;
poly_function( [ _, _ ] ) -> ...;
poly_function( [ A, B ] ) -> ...;

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