Re[17]: ФП и абстракция списка - Декларативное программирование

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

Не вдаваясь в суть спора по STL хочется поднять одну тему, на мой взгляд пересекающуюся с этой.

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

В С++ это STL-ные итераторы. В C# — это IEnumerable<T>. И так далее, и тому подобное.

Теперь взглянем на мир ФЯ. Что же мы наблюдаем? А наблюдаем мы весьма странную картину. Мы наблюдаем отсуствие астракции в обработке списков. Любой ФЯ (начиная с Лиспа и заканчивая Хасклем) поддерживает однонаправленные связанные, неизменяемые списки. На их базе и строится вся обработка списков.

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

Языки поддерживающие ФП и ООП обычно позволяют ввести ОО-абстракцию (интерфейс) и на ее базе реализовать фукнциональные, но полностью абстрактные фунции обработки списков. ОК. Но это ООЯ. И этим все сказано.

Внимание! Вопрос!

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

Очень хочется услышать именно мысли, а не защиту "любимой игруки".

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Можем, почему нет? Списки разделяют самые разные интерфейсы с самыми разными типами.
Тебя, скорее всего, заинтересует Data.Foldable

Обрати внимание на типы функций:

sum :: (Foldable t, Num a) => t a -> a

Т.е. любой "сворачиваемый" контейнер может быть обработан этой функцией для подсчёта суммы его элементов.
Погляди на дефолтные инстансы — там есть и список и массив.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Можем, почему нет? Списки разделяют самые разные интерфейсы с самыми разными типами.
L>Тебя, скорее всего, заинтересует Data.Foldable

L>Обрати внимание на типы функций:

L>

L>sum :: (Foldable t, Num a) => t a -> a
L>

L>Т.е. любой "сворачиваемый" контейнер может быть обработан этой функцией для подсчёта суммы его элементов.
L>Погляди на дефолтные инстансы — там есть и список и массив.

Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

Выходит используется фактически ОО-подход.

Не так ли?

А в других языках (где нет классов типов или ОО-интерфейсов) как?

... << RSDN@Home 1.2.0 alpha rev. 637>>

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

VD>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

VD>Выходит используется фактически ОО-подход.

VD>Не так ли?

Это опять очень холиварная тема по поводу определения ОО. Если ОО — это объекты с состоянием, обменивающиеся сообщениями, то скорее нет. Если православие, самодержавие, народность, то есть тьфу, инкапсуляция, наследование, полиморфизм — то скорее да.

VladD2,

VD>Теперь взглянем на мир ФЯ. Что же мы наблюдаем? А наблюдаем мы весьма странную картину. Мы наблюдаем отсуствие астракции в обработке списков. Любой ФЯ (начиная с Лиспа и заканчивая Хасклем) поддерживает однонаправленные связанные, неизменяемые списки. На их базе и строится вся обработка списков.

Контрпримерs: Sisal и J — функциональные языки, где основная структура — массив. То есть индексация O(1) и т.п. Правда с ними не всё гладко.

Массивы (то есть структура данных с произвольным доступом) не слишком красиво ложатся в ФП, так как изменение требует O(n) — весь массив должен быть скопирован (по крайней мере в наивной реализации).

Чтобы успешно использовать массивы, нужно решить 2 проблемы (это в принципе известный факт, но я озвучу для полноты изложения):

1. Проблема инициализации массива. В стандартных императивных алгоритмах часто проезжают по всем элементам массива устанавливая значеня одно за другим. Другими словами, чтобы инициализировать массив размера n, должно быть произведено n-1 деструктивных операций, если каждое действие требует создание копии, то мы приплыли к O(n^2).

2. Проблема изменения существующего массива (который может иметь вообще говоря несколько имён).

С первой проблемой можно успешно бороться оптимизаторами и навороченной системой типов, с помощью которой можно выделить код с деструктивными эффектами.

Со второй проблемой можно бороться с помощью языковой поддержки и богатых средств доступа к массиву. Например, в том же J интерфейс доступа к массиву — это не банальный набор "получить элемент по индексу, обновить элемент по индексу", а целая куча операций : всякие сортировки, перебор окнами, оператор неподвижной точки, степени, разбиения и т.д. Не факт, что данный набор полный (а кстати, интересно, можно выделить полный базис для доступа к массиву?), но для практических нужд хватает с лихвой.

Как вариант — использовать разряжённые массивы (то есть хэш-таблицы int->object), деструктивные операции также достаточно быстры, а чтение по-прежнему O(1).

Есть ещё v-arrays — версионное дерево, полностью функциональная структура данных, в которой доступ к самой новой копии O(1), а к более старым — "O-большое" от количества произведённых деструктивных операций.

Ок, хватит про массивы

(Подробный анализ массивов в ФП можно найти у Криса Окасаки).

Со списками же, как ты понимаешь, проблем гораздо меньше. Фактически, список — это и есть общий низкоуровневый интерфейс для некоторой последовательности. Всё что нужно, у него есть: конструктор списка cons, и деструктор с помощью паттерн-матчинга. Если сказать кратко: список — это и есть "итератор" в ФП.

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

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

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

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

VD>Внимание! Вопрос!

VD>Так есть ли что-то в ФП для создания действительно абстракных функций обработки всего что может быть абстрактно отнесено к спискам. Или все же ФП это стиоль завязанный исключительно на односвязанные списки?

VD>Очень хочется услышать именно мысли, а не защиту "любимой игруки".

Очень правильный вопрос. Строго говоря, описанное тобой свойство — это слабое место многих ФЯ, которое большинство обходит стороной. Однако, эта проблема решена в Scala и отстствует в Haskell.

1) В скале проблема решается тем, что ты можешь выполнять паттерн-матчинг на итераторах. В результате, вместо списка можно подпихнуть что угодно в функцию, которая рекурсивно через паттерн-матчинг пробегается по чему-то, что ей подпихнули. Для решения этой проблемы нужна возможность выполнять сопоставления с образцом на пользовательских абстрактных типах данных — это должен подделживать язык, и в Скале это есть. Или...

2) язык должен быть ленивым. В Хаскеле проблемы нет, благодаря тому, что язык ленивый. Поэтому, достаточно для каждого контейнера определить функцию, перегоняющую его в список. В результате, функция обработки определенная на списке эффективно заработает на любом контейнере — благодаря ленивости и оптимизации deforestation промежуточный список компилятор вообще вырежет, и сгенерирует вместо него код однонаправленного итератора.

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

G>Очень правильный вопрос. Строго говоря, описанное тобой свойство — это слабое место многих ФЯ, которое большинство обходит стороной. Однако, эта проблема решена в Scala и отстствует в Haskell.

В рефале тоже нет этой проблемы, и решена первым способом.

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

D>Это опять очень холиварная тема по поводу определения ОО. Если ОО — это объекты с состоянием, обменивающиеся сообщениями, то скорее нет. Если православие, самодержавие, народность, то есть тьфу, инкапсуляция, наследование, полиморфизм — то скорее да.

Инкапсуляция подразумевает спрятанное в объекте состояние, к которому нет прямого доступа. Без этого объектная декомпозиция невозможна, а без нее об ОО говорить глупо. Под "наследованием" подразумевается такая штука, как "наследование реализации" (т.е. объект наследует поведение, а не интерфейс) — тоже не наш случай.

То что есть в Хаскельном примере — это только полиморфизм. Зато какой!

ОО отдыхает.

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

L>>Обрати внимание на типы функций:

L>>

L>>sum :: (Foldable t, Num a) => t a -> a
L>>

L>>Т.е. любой "сворачиваемый" контейнер может быть обработан этой функцией для подсчёта суммы его элементов.
L>>Погляди на дефолтные инстансы — там есть и список и массив.

VD>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

VD>Выходит используется фактически ОО-подход.

VD>Не так ли?

VD>А в других языках (где нет классов типов или ОО-интерфейсов) как?

ИМХО, тут нельзя говорить о ОО и ФЯ как о полюсах. ОО возникло как средство абстрагимрования на базе ИЯ. Но ведь аоздавать систему с определённым дизайном нужно и в ФЯ. Потому придумывают разные подходы, либо притягивая за уши ОО, чтобы он подошёл к ФЯ (как в OCaml), либо делают смешанный ФЯ/ИЯ, который нормально уживается с ОО (Nemerle, Scala), либо, как в Хаскеле, придумывают свой особенный механизм абстрагирования. Причём в чём-то он похож на ОО и на интерфейсы из джавы, но это всё-таки нечто другое.

... << RSDN@Home 1.2.0 alpha rev. 672>>

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

VD>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

Ага, за исключением того малюсенького обстоятельства, что классы типов в Хаскелле обеспечивают сколь угодно изощренное метапрограммирование. И это не какие-то приколы, а повсеместно работает в real world коде.

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

A>Ага, за исключением того малюсенького обстоятельства, что классы типов в Хаскелле обеспечивают сколь угодно изощренное метапрограммирование. И это не какие-то приколы, а повсеместно работает в real world коде.

Ммм, покажи на них, к примеру, генерацию кода в компайл-тайме, плиз

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

К>Ммм, покажи на них, к примеру, генерацию кода в компайл-тайме, плиз

Какого кода? Сформулируй точнее.

ты правильно сделал что написал сюда поскольку мне лень логиниться

первое. нужно противопоставить ООП и полиморфизм. при ООП каждый объект включает VMT, из которой берутся реализации операций. при полиморфном программировании реализации операций передаются отдельным (невидимым) аргументом. полиморфизм совместим с type inference. STL в C++ как я понимаю, это полиморфизм в чистом виде — никаких VMT, вывод типов, реализации алгоритмов не включены в состав объектов, хотя и не передаются отдельным аргументом — они просто подставляются во время компиляции. поравьте меня, если я плохо знаю STL, но там нет и не иожет быть никакого наследования алгоритмов, поскольку они сделаны на templates, a templates — это и есть compile-time polymorphism, не имеющий никакого отношения к ООП. в STL достаточно использовать стандартную схему наименования для новых коллекций, никакого ООП наследования не требуется, верно?

type classes отличаются от C++ templates тем, что реализация операций класса для конкретного обрабатываемого типа передаётся невидимым аргументом в функцию и это означает, что можно генерить один код, работающий с любым типом, а также что во время выполнения можно производить различные манипуляции над этими словарями

рекомендую http://haskell.org/haskellwiki/OOP_vs_type_classes и http://homepages.inf.ed.ac.uk/wadler/papers/class/class.ps.gz

>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

сейчас я бы так не сказал. скорее интерфейсы темплейтов с run-time передачей

VD>Так есть ли что-то в ФП для создания действительно абстракных функций обработки всего что может быть абстрактно отнесено к спискам. Или все же ФП это стиль завязанный исключительно на односвязанные списки?

есть две библиотеки — collections и edison, которые жтим и занимаются, классы folfable, applicative и прочие тоже частично это делают. фактически это находлится в загоне, поскольку мало кому нужно. вместо этого реализовывают различные типы данных с Data.List-подобным интерфейсом и удовлетворяются тем, что одим тип коллекций можно заменить на другой простой сменой импорта. Data.Map. Data.ByteString сделаны подобным образом. учитывая сложности с созданием полиморфных коллекций, потребность именно в том, чтобы это было классом, действительно мало у кого возникает

кроме того, есть такая штука, как generic programming (это не generics из ООП языков). грубо говоря, она позволяет писать универсальные функции, работающие с любым типом. в ООП языках его можно сэмулировать с помощью RTTI или макросов. вот пример применения одной из таких библиотек: представь себе, что у тебя есть AST некоторой программы. тип, описывающий AST. может содержать десятки вариантов, сама AST может содержать тысячи узлов различной вложенности. и тем не менее напечатать все идентификаторы, начинающиеся на 'A', можно простой строчкой:

print (gfilter (\(ID ('a':_)) -> True) ast)

при этом gfilter включает в себя универсальный код для обхода произвольных структур данных

G>благодаря ленивости и оптимизации deforestation промежуточный список компилятор вообще вырежет, и сгенерирует вместо него код однонаправленного итератора.

вряд ли. насколько я разбираюсь, спислк так и будет лениво генерироваться в процессе потребления. deforestatuion делают специально в отдельных библиотеках на RULES. реально оно сейчас есть в bytestring и parallel arrays — afaik. точнее, его называют stream fusion

(если я что-то неправильно понимаю — исправляйте)

Хотя я не большой специалист в его (GHC) внутреннем устройстве.

D>Вроде как в GHC foldr/build rule позволяет элиминировать списки во многих ситуациях (см. здесь).

при обработке самих списков — да. а вот если у тебя есть операция, генерящая списки... то наверно тоже да. a stream fusion — это как я понял каокй-то другой способ достижения той же цели, который уже применён в bytestring и как я понял, им собираются заменить foldr/build систему. в общем, я тоже только краем уха слышал

Здравствуйте, Аноним, Вы писали:

А>первое. нужно противопоставить ООП и полиморфизм. при ООП каждый объект включает VMT, из которой берутся реализации операций. при полиморфном программировании реализации операций передаются отдельным (невидимым) аргументом. полиморфизм совместим с type inference. STL в C++ как я понимаю, это полиморфизм в чистом виде — никаких VMT, вывод типов, реализации алгоритмов не включены в состав объектов, хотя и не передаются отдельным аргументом — они просто подставляются во время компиляции. поравьте меня, если я плохо знаю STL, но там нет и не иожет быть никакого наследования алгоритмов, поскольку они сделаны на templates, a templates — это и есть compile-time polymorphism, не имеющий никакого отношения к ООП. в STL достаточно использовать стандартную схему наименования для новых коллекций, никакого ООП наследования не требуется, верно?

Что такое "схема наименования"? В STL контейнеры должны выставлять интерфейс итераторов, которые реализуют разные "концепции", всё более и более сильные: от итератора ввода (в одну сторону и только на чтение) до итератора произвольного доступа (по функциональности — обычный сишный указатель). А алгоритмы работают с итераторами, реализующими "концепции" нужной для алгоритма силы (это сделано в том числе и для эффективности реализации). А наследования контейнеров действительно не нужно.

А>кроме того, есть такая штука, как generic programming (это не generics из ООП языков). грубо говоря, она позволяет писать универсальные функции, работающие с любым типом. в ООП языках его можно сэмулировать с помощью RTTI или макросов. вот пример применения одной из таких библиотек: представь себе, что у тебя есть AST некоторой программы. тип, описывающий AST. может содержать десятки вариантов, сама AST может содержать тысячи узлов различной вложенности. и тем не менее напечатать все идентификаторы, начинающиеся на 'A', можно простой строчкой:

А>print (gfilter (\(ID ('a':_)) -> True) ast)

А>при этом gfilter включает в себя универсальный код для обхода произвольных структур данных

Что имеется ввиду под словами функции, работающие с любым типом?

gfilter :: forall a. (... -> Bool) -> a

?
Или всё же AST делается Gfilterable через какой-то instance declaration?

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

L>Например, какие? На Лиспе, как известно, можно сделать всё,

Дык, покажи.

L>в окамле есть классы...

Аналогично. В прочем, классы опят будет ООП и стало быть гибридное решение. Получается, что как раз ФП-шного решения этой проблемы не существует?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>То что есть в Хаскельном примере — это только полиморфизм. Зато какой!

ОО отдыхает.

Полиморфизм и инкапсуляция присутсвтуют в полном объеме.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Не надо так оверквотить. ОК?

K>ИМХО, тут нельзя говорить о ОО и ФЯ как о полюсах.

Дык я то как раз только "за". Но вот я не раз встречал ФП-джидаев которые ООП на дух не переносят. Вот и интересно послушать про то, что же в этой области может предложить ФП. С Хаскелем все ясно, но это ООП вид сбоку. Про Немерле, Скалу и ОКамл опять же говорить не приходится, так как это чистые гибриды.

Выходит, что борьба с ООП просто глупа. И без него в общем-то никуда.

K> ОО возникло как средство абстрагимрования на базе ИЯ. Но ведь аоздавать систему с определённым дизайном нужно и в ФЯ. Потому придумывают разные подходы, либо притягивая за уши ОО, чтобы он подошёл к ФЯ (как в OCaml), либо делают смешанный ФЯ/ИЯ, который нормально уживается с ОО (Nemerle, Scala), либо, как в Хаскеле, придумывают свой особенный механизм абстрагирования. Причём в чём-то он похож на ОО и на интерфейсы из джавы, но это всё-таки нечто другое.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Ага, за исключением того малюсенького обстоятельства, что классы типов в Хаскелле обеспечивают сколь угодно изощренное метапрограммирование. И это не какие-то приколы, а повсеместно работает в real world коде.

Обоснуй это урверждение. Я метапрограммирования в них в упро не вижу. Оди в один идея явного воплощения абстрактных типов как в АДА.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

К>>Ммм, покажи на них, к примеру, генерацию кода в компайл-тайме, плиз

A>Какого кода? Сформулируй точнее.

Не. Тогда лучше ты сформулирй, что ты понимашь под термином "метапрограммирование"?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>Массивы (то есть структура данных с произвольным доступом) не слишком красиво ложатся в ФП, так как изменение требует O(n) — весь массив должен быть скопирован (по крайней мере в наивной реализации).

Ага. И это проблемы ФП, а не массивов. В прочем, на мой взгляд, это вопрос наличия сахара и привязанности ортодоксальным идеям.

LCR>Чтобы успешно использовать массивы, нужно решить 2 проблемы (это в принципе известный факт, но я озвучу для полноты изложения):

LCR>1. Проблема инициализации массива. В стандартных императивных алгоритмах часто проезжают по всем элементам массива устанавливая значеня одно за другим. Другими словами, чтобы инициализировать массив размера n, должно быть произведено n-1 деструктивных операций, если каждое действие требует создание копии, то мы приплыли к O(n^2).

LCR>2. Проблема изменения существующего массива (который может иметь вообще говоря несколько имён).

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

Пока что я вижу только один полноценный механизм абстрагирования в ФЯ — это классы типов Хаскеля. Причем их идея фактически заимствована из ООП. Это те же интерфейсы — вид сбоку.

Другие языки или являются гибридами и предоставляют ОО-полиморфизм, или просто не предоставляют полноценных средств абстрации (ну, или я их в упор не могу увидить).

LCR>Ок, хватит про массивы

(Подробный анализ массивов в ФП можно найти у Криса Окасаки).

Меня этот вопрос не интересует. См. выше.

LCR>Со списками же, как ты понимаешь, проблем гораздо меньше. Фактически, список — это и есть общий низкоуровневый интерфейс для некоторой последовательности.

Нифига списки не интерфейс. Списки это голимая реализация. Просто они неплохо ложаться на идеи фунционального вычисления. Но скажем интрфейс IEnumerable<T> ложится на них не сильно хуже.

В общем, еще раз повторю вопрос.

Где в ФП те средства абстракции и полиморфизма которыми мы так привыкли пользоваться в ООЯ? И если их нет, то к чему противопоставлять ООП и ФП? Не лучше ли думать о их сблжении? А то и вообще рассматривать ФП как отдельную технику программирования, а не как полноценную парадигму.

LCR> Всё что нужно, у него есть: конструктор списка cons, и деструктор с помощью паттерн-матчинга. Если сказать кратко: список — это и есть "итератор" в ФП.

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

Вот классы типов Хаскеля — это отличная демонстрация такого интерфейсов. ОО-интерфейсы тоже.

Выходит, что ФП банально не предоставляет таких базовых вещей достижения полиморфизма. А значит он не совсем полноценный и требует введения этих концепций.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Q>Вообще-то, в книгах по СТЛ рекомендуют не пытаться писать коллекционно-независимый код, каждая коллекция индивидуальна и имеет свои особенности, которые сильно влияют на производительность.

Странные ты книжки читаешь. СТЛ и есть набор независимых от контейнеров алгоритмов. А итераторы средство абстргирования (интерфейс).

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Очень правильный вопрос. Строго говоря, описанное тобой свойство — это слабое место многих ФЯ,

Вот и мне так показалось. Только похоже проблема это не ФЯ, а ФП как такового. Я так и не увидил именно идеологических ФП-шных средств полиморфизма (не параметрического).

G> которое большинство обходит стороной. Однако, эта проблема решена в Scala и отстствует в Haskell.

Согласен с парой оговорок. В Скале (как в Немерле, ОКамле и т.п.) банально используется ООП. А Хаскель расширяет идеии ФП вводя механизм абстрагирования аналогичный ОО-интерфейсам и даже более гибкий чем в ООЯ механизм их реализации.

В общем, решение Хаскеля замечательно, но оно не основано на идеях ФП. Оно скорее их дополняет отсуствующим в них компонентом.

Вот и интересно почему все же в ФП нет таких идей изначально? И почему не смотря на такой пробел все же большинство ФЯ не расширятся такими средствами?

Так же интересно почему многие опологеты ФП просто таки борются с ООП вместо того, чтобы осознать, что его принцыпы отлично дополняют ФП?

G>1) В скале проблема решается тем, что ты можешь выполнять паттерн-матчинг на итераторах. В результате, вместо списка можно подпихнуть что угодно в функцию, которая рекурсивно через паттерн-матчинг пробегается по чему-то, что ей подпихнули. Для решения этой проблемы нужна возможность выполнять сопоставления с образцом на пользовательских абстрактных типах данных — это должен подделживать язык, и в Скале это есть. Или...

На самом деле паттерн-матчинг не обязателен. Пробежаться по коллекции можно и тупо вызвая метод Next(). Важно чтобы была бастракция вроде интерфейса. В Скале эту роль выполняют трэйтсы. По своим свойствам они полностью аналогичны интерфейсам.

G>2) язык должен быть ленивым. В Хаскеле проблемы нет, благодаря тому, что язык ленивый. Поэтому, достаточно для каждого контейнера определить функцию, перегоняющую его в список. В результате, функция обработки определенная на списке эффективно заработает на любом контейнере — благодаря ленивости и оптимизации deforestation промежуточный список компилятор вообще вырежет, и сгенерирует вместо него код однонаправленного итератора.

Недостаточно. Опять же нужен механим абстрагирования. Такой механизм в Хасклее — это классы типов. И по-моему, они мало чем отличаются от ООП-ных интефейсов. Более того при этом явно просматривается состояние. Другое дело, что в Хаскеле оно пропускается через стек и не выглядит как чистый ООП. Но приципы те же.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, <Аноним>, Вы писали:

А>первое. нужно противопоставить ООП и полиморфизм. при ООП каждый объект включает VMT, из которой берутся реализации операций. при полиморфном программировании реализации операций передаются отдельным (невидимым) аргументом. полиморфизм совместим с type inference. STL в C++ как я понимаю, это полиморфизм в чистом виде — никаких VMT, вывод типов, реализации алгоритмов не включены в состав объектов, хотя и не передаются отдельным аргументом — они просто подставляются во время компиляции. поравьте меня, если я плохо знаю STL, но там нет и не иожет быть никакого наследования алгоритмов, поскольку они сделаны на templates, a templates — это и есть compile-time polymorphism, не имеющий никакого отношения к ООП. в STL достаточно использовать стандартную схему наименования для новых коллекций, никакого ООП наследования не требуется, верно?

ООП никогда не упирался в VMT и другие проблемы реализации. В ООП есть главное, чего нет в ФП. В ООП есть понятие интерфейса. Чего-то абстрактного что определяет набор методов которые должен реализовать некий объект. Это позволяет применять к разнм (совсем, разные, не связанные ничем) объектам одни и те же функции/методы. Причем совершенно по фигу когда производится разрешение типов, в компайл-тайме (как в С++-шаблонах), или в рантайме (как в интерфейсах Явы/C# или трэйстах Скалы). Важно, что есть механизм полного абстрагирования от конкретного типа. Такой механизм есть и в Хаскеле. Это классы типов. Суть их полностью аналогична ОО-интерфейсам.

А>type classes отличаются от C++ templates тем, что реализация операций класса для конкретного обрабатываемого типа передаётся невидимым аргументом в функцию и это означает, что можно генерить один код, работающий с любым типом, а также что во время выполнения можно производить различные манипуляции над этими словарями

Какие еще невидимые аргументы? Если речь о Хаскле, то там все передается явно. Просто опят же присутствует интерфейс и порождаемый им полиморфизм.

А>рекомендую http://haskell.org/haskellwiki/OOP_vs_type_classes и http://homepages.inf.ed.ac.uk/wadler/papers/class/class.ps.gz

Спасибо. Но мне смешно смотреть на противопоставления ООП ООП-у.

>>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

А>сейчас я бы так не сказал. скорее интерфейсы темплейтов с run-time передачей

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

VD>>Так есть ли что-то в ФП для создания действительно абстракных функций обработки всего что может быть абстрактно отнесено к спискам. Или все же ФП это стиль завязанный исключительно на односвязанные списки?

А>есть две библиотеки — collections и edison, которые жтим и занимаются, классы folfable, applicative и прочие тоже частично это делают.

Стоп. Это есть в Хаскеле. А где анлоги в других ФЯ?

А>кроме того, есть такая штука, как generic programming (это не generics из ООП языков). грубо говоря, она позволяет писать универсальные функции, работающие с любым типом. в ООП языках его можно сэмулировать с помощью RTTI или макросов. вот пример применения одной из таких библиотек: представь себе, что у тебя есть AST некоторой программы. тип, описывающий AST. может содержать десятки вариантов, сама AST может содержать тысячи узлов различной вложенности. и тем не менее напечатать все идентификаторы, начинающиеся на 'A', можно простой строчкой:

А>print (gfilter (\(ID ('a':_)) -> True) ast)

Это не то. Вот если бы ты мог применить свой gfilter к массиву, дереву и списку одновременно, тогда бы это было то.

В общем, меня не интересуют примеры из жизни. Мен интересно услышать объяснение механизмов ФП обеспечивающих полиморфизм на уровне ООП (классы типов Хаскеля опускаем как частный случай). Или признание того, что таких механизом в ФП нет и это упущение парадигмы.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>>в окамле есть классы...

VD>Аналогично. В прочем, классы опят будет ООП и стало быть гибридное решение. Получается, что как раз ФП-шного решения этой проблемы не существует?

Вопрос был

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

Задача — создать набор функций, задаваемый над некоторым подмножеством допустимых типов данных, расширяемым впоследствии. Для этого необходимы языковые механизмы поддерживающие выделение такого специфического подмножества, и связывающие его с этим набором функций. В самой постановке задачи зашито объединение "какие-то типы данных"+"какая-то функциональность". Любой механизм такой склейки будет выглядеть как ООП.

В Хаскелле функциональность описывается в классах типов, а реализуется либо в instance declaration'ах для типов данных, если есть специфика реализации для конкретного полиморфного типа (List, Array), либо для всего класса типов по дефолту (с возможностью перегрузки).

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

D>Вопрос был
D>

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

Ага.

D>Задача — создать набор функций, задаваемый над некоторым подмножеством допустимых типов данных, расширяемым впоследствии. Для этого необходимы языковые механизмы поддерживающие выделение такого специфического подмножества, и связывающие его с этим набором функций. В самой постановке задачи зашито объединение "какие-то типы данных"+"какая-то функциональность". Любой механизм такой склейки будет выглядеть как ООП.

Ага. Я даже скажу больше. Он будет требовать наличия и передачи состояния. Так как нам нужно не просто набор фунций, а некий объект позволющий с помощью этих фунций перебирать коллекции. Нам мало функции Next(). Нам еще нужно нечто, что инкапсулирует конкретную коллекцию и превратит ее в некую абстрацию. И это действительно в моем понимании очень похоже на ООП.

D>В Хаскелле функциональность описывается в классах типов, а реализуется либо в instance declaration'ах для типов данных, если есть специфика реализации для конкретного полиморфного типа (List, Array), либо для всего класса типов по дефолту (с возможностью перегрузки).

С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Обоснуй это урверждение. Я метапрограммирования в них в упро не вижу. Оди в один идея явного воплощения абстрактных типов как в АДА.

Я всем одновременно рекомендую посмотреть, например, сюда. Олег (Киселев) написал также короткий, но в высшей степени полезный текст, где объясняет особенности работы Haskell typechecker.

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

VD>В ООП есть понятие интерфейса. Чего-то абстрактного что определяет набор методов которые должен реализовать некий объект. Это позволяет применять к разнм (совсем, разные, не связанные ничем) объектам одни и те же функции/методы.

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

Хаскель ты отмёл...

На списках можно сделать почти всё (см. SICP). Выглядеть это может несколько "необычно", но "вам шашечки или ехать"?

"Чистую парадигму" ФП на чём излагать?

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

L>>Например, какие? На Лиспе, как известно, можно сделать всё,

VD>Дык, покажи.

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

L>>в окамле есть классы...

VD>Аналогично. В прочем, классы опят будет ООП и стало быть гибридное решение. Получается, что как раз ФП-шного решения этой проблемы не существует?

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

Но это уже философия. Я что сказать хочу — исходя из задачи и решение будет. Ведь вопрос был именно о перегрузке? Есть ли перегрузка в ФП? Есть. Из-за того, что она есть также и в ОО это не делает ее ОО решением.

По моему мы скатываемся в философию.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

VD>Выходит, что борьба с ООП просто глупа. И без него в общем-то никуда.

Мне кажется, это вопрос взгляда. Смотришь на мир с точки зрения ООП — сравниваешь другие решения с ООП, но это всего лишь аналогия, а не ООП.

VD>О том и речь. Вот и интересно мнение наиболее ортодоксальных фунциональщиков. Ведь когда все крутится вокруг одних однораправленных связанных списков, то чувствуется какая-то ущербность.

Конечно

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, <Аноним>, Вы писали:

А>при обработке самих списков — да. а вот если у тебя есть операция, генерящая списки... то наверно тоже да. a stream fusion — это как я понял каокй-то другой способ достижения той же цели, который уже применён в bytestring и как я понял, им собираются заменить foldr/build систему. в общем, я тоже только краем уха слышал

foldr/build как раз при операциях генерящих и сворачивающих списки, элиминация заключается в создании "прямой" функции. Два недостатка — не работает над несколькими списками (zip), и над левым fold. Ещё есть destroy/unfoldr. Тоже какие то недостатки есть.

Насколько я понял, там основная проблема — рекурсия. Компилятор плохо (по моему совсем не) оптимизирует рекурсивные функции. Имеется в виду разумеется элиминация промежуточных данных. Поэтому в stream fusion списки преобразовывают в потоки, функцию получаются не рекурсивными. А то, что, кажется, что мы меняем шило на мыло — это не так. Остальную работу по элиминации потоков выполняет компилятор, т.к. в нерекурсивных функциях он может это делать. Там есть интересные тонкости, в конце я приведу список литературы

Duncan Coutts и Don Stewart расширили эту технику на вложенные списки и зипы (работа с несколькими списками). Мало того, эта техника оказалась пригодной для работы не только над списками, но и над массивами. Т.е. функциональный код превращается в близкий к сишному.

Gill. Cheap Deforestation for Non-strict Functional Languages Про build/foldr. Можно читать по диагонали, относительно легко.

From Lists to Streams to Nothing at All Про улучшенный stream fusion. Очень легко с примерами, с интересными тонкостями.

Rewriting Haskell Strings Про stream fusion над ByteString. Реализация, тесты производительности.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

А>>print (gfilter (\(ID ('a':_)) -> True) ast)

VD>Это не то. Вот если бы ты мог применить свой gfilter к массиву, дереву и списку одновременно, тогда бы это было то.

Он и применяет. ast — это некий (в принципе, любой) тип данных, который внутри (сколь угодно глубоко) содержит идентификатор(ы).

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Первое, что пришло в голову, определить два макроса define-overload и define-overload-instance.
L>Первый создает словарь, в котором по предикатам (или по каким другим ключам, например, сразу по типам) можно найти нужную реализацию и функцию, которая лазает по словарю в поисках нужной реализации, второй макрос пихает в словарь предикат и конкретную реализацию. Определяться, какая реализация будет вызвана, будет в рантайме или во время компиляции в зависимости от того, как напишем.

Хм. Закат солнца вручную?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>Мне кажется, это вопрос взгляда. Смотришь на мир с точки зрения ООП — сравниваешь другие решения с ООП, но это всего лишь аналогия, а не ООП.

Какая разница как и куда я смотрю. Если в ФП нет концептуальных решений для данной проблемы, то их нет независимо от того как и куда я смотрю.

Хаскель отровенно расширен похожен на ООП технологией. ОКамл просто ООЯ. Я не сомневаюсь, что его создатели исходили из разных предпосылок, но пришли они к очень похожим решениям.

L>Конечно

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

В том то и дело, что список не абстракция, а конкретика. Подходить, то он конечно подходит. Но конкретика есть кокретика. Он не всегда хорошо подхдит для всех задач. А о производительности вообще говорить не приходится.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Обоснуй это урверждение. Я метапрограммирования в них в упро не вижу. Оди в один идея явного воплощения абстрактных типов как в АДА.

A>Я всем одновременно рекомендую посмотреть, например, сюда. Олег (Киселев) написал также короткий, но в высшей степени полезный текст, где объясняет особенности работы Haskell typechecker.

Я верно понял, что премого ответа не будет?

ЗЫ

Кстати, по ссылкам слово metaprogramming не встречается ни разу.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, <Аноним>, Вы писали:

А>Ну а в лиспе есть дженерики — позволяют "вызывать" методы, определённые вообще для чего угодно...

Ну, вызови для массива car/cdr, если так.

И вообще, динамика не есть достижение ФП, а я просил ФП средства.

ЗЫ

В общем, судя по ответам ФП ничего не предоставляет для решения подобных проблем.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, <Аноним>, Вы писали:

А>Не совсем понятно, что именно тебе "надо"

Если очень сило себе это внушать, то возможно. Похже, что остальные поняли все отлично.

А>Хаскель ты отмёл...

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

А>На списках можно сделать почти всё (см. SICP).

"Почти" это уже само по себе смешно. Да и вопрос не в этом. Скажем действительно все можно выразить буквально 5-ю ассемблерными инструкциями где даже call в общем-то не нужен. Но речь то и дет об абстрации.

А>"Чистую парадигму" ФП на чём излагать?

Меня больше занимает другой вопрос. Имеет ли смысл вообще рассматривать ФП как отдельную прарадигму. Похоже, что в чистом виде она ущербна, и имеет смысл только в купе с некой иделогией типов которая в чистом виде имеется только в ООП.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Здравствуйте, <Аноним>, Вы писали:

А>>первое. нужно противопоставить ООП и полиморфизм. при ООП каждый объект включает VMT, из которой берутся реализации операций. при полиморфном программировании реализации операций передаются отдельным (невидимым) аргументом. полиморфизм совместим с type inference. STL в C++ как я понимаю, это полиморфизм в чистом виде — никаких VMT, вывод типов, реализации алгоритмов не включены в состав объектов, хотя и не передаются отдельным аргументом — они просто подставляются во время компиляции. поравьте меня, если я плохо знаю STL, но там нет и не иожет быть никакого наследования алгоритмов, поскольку они сделаны на templates, a templates — это и есть compile-time polymorphism, не имеющий никакого отношения к ООП. в STL достаточно использовать стандартную схему наименования для новых коллекций, никакого ООП наследования не требуется, верно?

VD>ООП никогда не упирался в VMT и другие проблемы реализации. В ООП есть главное, чего нет в ФП. В ООП есть понятие интерфейса. Чего-то абстрактного что определяет набор методов которые должен реализовать некий объект.

это есть уже в концепции АТД. ооп от неё отличается механизмами наследования, которые невозможно реализовать без VMT. если ты с этим несогласен — попробуй описать другую реализацию классов C++

>Это позволяет применять к разнм (совсем, разные, не связанные ничем) объектам одни и те же функции/методы. Причем совершенно по фигу когда производится разрешение типов, в компайл-тайме (как в С++-шаблонах), или в рантайме (как в интерфейсах Явы/C# или трэйстах Скалы). Важно, что есть механизм полного абстрагирования от конкретного типа. Такой механизм есть и в Хаскеле. Это классы типов. Суть их полностью аналогична ОО-интерфейсам.

нет, это для тебя они все на одно лицо по незнанию сущности предмета. если производить резовлинг в compile-time, то достаточно совпадения имён. у одного типа есть метод show и у другого типа есть метод с таким же именем — значит его можно вызывать не задумываясь о конкретном типе. когда же дело доходит до выбора соотвествующей типу реализации этого show во время работы, то здесь уже одного совпадения имён недостаточно. нужно как-то в процессе работы превратить этот обобщённый вызов show в конкретный адрес процедуры. ООП подход делает таблицу методов частью самого объекта. type classes передаёт таблицу методов в качестве отдельного скрытого параметра. из этого различия в реализации вытекают различия в возможностях того и другого подхода

А>>type classes отличаются от C++ templates тем, что реализация операций класса для конкретного обрабатываемого типа передаётся невидимым аргументом в функцию и это означает, что можно генерить один код, работающий с любым типом, а также что во время выполнения можно производить различные манипуляции над этими словарями

VD>Какие еще невидимые аргументы? Если речь о Хаскле, то там все передается явно. Просто опят же присутствует интерфейс и порождаемый им полиморфизм.

а ты знаком с реализацией type classes?

обрати внимание, Влад, для тебя это типично — с жаром нести чушь о том, в чём ты не совершенно разбираешься. прочти для начала статью Вадлера. затем поработай с type classes в приложениях, оцени разницу в их возможностях по сравнению с ооп. после этого ты поймёшь, что сравнение их с ООП интерфейсами — весьма поверхностно

А>>рекомендую http://haskell.org/haskellwiki/OOP_vs_type_classes и http://homepages.inf.ed.ac.uk/wadler/papers/class/class.ps.gz

VD>Спасибо. Но мне смешно смотреть на противопоставления ООП ООП-у.

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

>>>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.

А>>сейчас я бы так не сказал. скорее интерфейсы темплейтов с run-time передачей

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

вопрос на 3: и чем это отличается от АТД?

VD>>>Так есть ли что-то в ФП для создания действительно абстракных функций обработки всего что может быть абстрактно отнесено к спискам. Или все же ФП это стиль завязанный исключительно на односвязанные списки?

А>>есть две библиотеки — collections и edison, которые жтим и занимаются, классы folfable, applicative и прочие тоже частично это делают.

VD>Стоп. Это есть в Хаскеле. А где анлоги в других ФЯ?

А>>кроме того, есть такая штука, как generic programming (это не generics из ООП языков). грубо говоря, она позволяет писать универсальные функции, работающие с любым типом. в ООП языках его можно сэмулировать с помощью RTTI или макросов. вот пример применения одной из таких библиотек: представь себе, что у тебя есть AST некоторой программы. тип, описывающий AST. может содержать десятки вариантов, сама AST может содержать тысячи узлов различной вложенности. и тем не менее напечатать все идентификаторы, начинающиеся на 'A', можно простой строчкой:

А>>print (gfilter (\(ID ('a':_)) -> True) ast)

VD>Это не то. Вот если бы ты мог применить свой gfilter к массиву, дереву и списку одновременно, тогда бы это было то.

ты читать хотя бы умеешь? эти функции применимы к любому типу данных

VD>В общем, меня не интересуют примеры из жизни. Мен интересно услышать объяснение механизмов ФП обеспечивающих полиморфизм на уровне ООП (классы типов Хаскеля опускаем как частный случай). Или признание того, что таких механизом в ФП нет и это упущение парадигмы.

может, проще сразу сказать, что ты пытаешься высосать из паольца обоснование крутины немерле?

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

VD>>О том и речь. Вот и интересно мнение наиболее ортодоксальных фунциональщиков. Ведь когда все крутится вокруг одних однораправленных связанных списков, то чувствуется какая-то ущербность.

L>Конечно

Тут видимо от Лиспа, да и вообще от лямбда исчисления пошло — список наиболее простая абстракция для создания сколь угодно сложных абстракций представления данных. Особенно лисповый, где у элементов могут быть элементы любого типа. С ним много примеров, на нем показываются различные приемы, новичку может показаться, что ФП — это сплошные списки, но на самом деле это не так. Как и в языках, не являющихся ФП, в ФП в нужном месте используются нужные контейнеры.

по моему опыту, когда не требуется скорость, то списки и списки ассоциаций — очень удобная и хорошо отработанная можель данных. под неё миллиарды функций, известных design patterns и т.п. то есть рушаться на это — всё равно что рушаться на сищников что они всё реализовывают через классы, хотя могли бы допустим указатели на функции использовать. но ведь рука-то уже набита и мысдль течёт в привычном направлении

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

, либо объёмы невелики

у меня был такой пропозал — отдать весь нынешний синтаксис списков специальному классу. тогда автоматчисеки весь код, написанный в расчёте на списки, будет работать с любыми реализациями этого класса. технически это всё понятно как сделать, но большого энтузиазма мой пропозал не вызвал (мягко выражаясь

)

Здравствуйте, <Аноним>, Вы писали:

А>нет, это для тебя они все на одно лицо по незнанию сущности предмета.

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

А> если производить резовлинг в compile-time, то достаточно совпадения имён.

Это имеет отношение к ФП?

А> у одного типа есть метод show и у другого типа есть метод с таким же именем

Если есть методы, то мы уже имеем дело с ООП. А вот ФП у нас таких концепций нет. А какая-нить одна функция не сможет работать с разными по структуре данными. Скажем fold написанный для списка будет падать на массивх.

В общем, вопрос можно закрывать. Лично мне все стало полностью ясно. С этого времени я буду отровенно ражать над пропагандистами "чистого" ФП. Я и раньше предпологал, что чистый ФП — это вакуумный сфероконяра, а тепель я в этом просто уверен.

... << RSDN@Home 1.2.0 alpha rev. 637>>

D>Задача — создать набор функций, задаваемый над некоторым подмножеством допустимых типов данных, расширяемым впоследствии. Для этого необходимы языковые механизмы поддерживающие выделение такого специфического подмножества, и связывающие его с этим набором функций. В самой постановке задачи зашито объединение "какие-то типы данных"+"какая-то функциональность". Любой механизм такой склейки будет выглядеть как ООП.

с каких это пор данные+функции=ООП?

ооп — это передача функций в vmt каждого объекта. type classes — это передача функций отдельно от данных. темплейты и любой другой статический полиморфизм — это выбор функций в compile-time, так что их никуда передавать вообще не нужно

А>>нет, это для тебя они все на одно лицо по незнанию сущности предмета.

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

ТЫ НЕ ПОНИМАЕШЬ, ЧЕМ TYPE CLASSES ОТЛИТАЕТСЯ ОТ ООП. и пока ты не ознакомишься с реализацией type classes, ты не сможешь аргшументированно рассуждать о его сходстве и отличиях с ооп. неужели такая простая мысль тебе недоступна?

А>> если производить резовлинг в compile-time, то достаточно совпадения имён.

VD>Это имеет отношение к ФП?

видишь ли, полиморфизм не реализуется неким волшебным образом. есть различные механизмы его реализации, которые отражаются в выразительных средствах языка. например, в C++ нет оверлоадинга по возвращаемому типу — это невомзожно в ООП. в хаскеле (и templates, afaik) такое поддерживается

А>> у одного типа есть метод show и у другого типа есть метод с таким же именем

VD>Если есть методы, то мы уже имеем дело с ООП.

ошибаешься. это идея абстрактных типов данных — экспозируем только методы, но не реализацию типа. опять-таки сказывается твоя необразованность, помноженная на безграничный апломб. ты живёшь по приницпу "если я чего-то не знаю, то этого нет и быть не может"

>А вот ФП у нас таких концепций нет. А какая-нить одна функция не сможет работать с разными по структуре данными. Скажем fold написанный для списка будет падать на массивх.

у тебя, Влад, будет падать и не это

VD>В общем, вопрос можно закрывать. Лично мне все стало полностью ясно. С этого времени я буду отровенно ражать над пропагандистами "чистого" ФП. Я и раньше предпологал, что чистый ФП — это вакуумный сфероконяра, а тепель я в этом просто уверен.

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

VD>>Аналогично. В прочем, классы опят будет ООП и стало быть гибридное решение. Получается, что как раз ФП-шного решения этой проблемы не существует?

L>Если представить перегруженную функцию как одну, но с реализацией, разбросанной по разным участкам кода — в зависимости от того по чему идёт диспач, то ОО — это одно решение, а классы типов — другое этой задачи. Они схожи только тем, что решают одну задачу — одна функция разбросана по разным местам в зависимости от диспача. Поэтому, если смотреть на проблему с этой точки зрения, говорить о том, что классы типов (или какая другая система диспача) — это ОО решение некорректно.

вот как раз диспатч в ооп и type classes совпадает

это ты с AlgTD перепутал

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

VD>Я верно понял, что премого ответа не будет?

Что такое "прямой" ответ? Боюсь, у меня на него нет времени.

VD>Кстати, по ссылкам слово metaprogramming не встречается ни разу.

Это скорее metaprogramming в духе C++. Как в C++ язык шаблонов оказался функциональным языком времени компиляции, так в Наскелле язык классов типов оказался логическим языком времени компиляции. По первой ссылке туча примеров вычислений времени компиляции, обеспечения разного рода статических гарантий и т.д., по второй — тонкости как оно работает.

Ну а любителям "обычного" метапрограммирования GHC (уже давно, 4 года как, с версии 6.0) дает все что нужно — quotations, splices, доступ к AST и т.д.

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

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

Q>>Вообще-то, в книгах по СТЛ рекомендуют не пытаться писать коллекционно-независимый код, каждая коллекция индивидуальна и имеет свои особенности, которые сильно влияют на производительность.

VD>Странные ты книжки читаешь. СТЛ и есть набор независимых от контейнеров алгоритмов. А итераторы средство абстргирования (интерфейс).

Ну так то сама STL. А Quintanar говорил более про, собственно, прикладной код. Например, код, часто вставляющий/удаляющий элементы в середину коллекции гораздо выгоднее построить на двусвязном списке, и не закладываться на то, что в будущем коллекция может поменяться на, скажем, вектор. А если закладываться, то у нас будут буквально связаны руки ничтожно малым набором операций, общим для всех контейнеров. Фактически, у нас останется только итератор с его operator++.

А вообще, С++ я давно не брал в руки и, наверное, сейчас сказал большую глупость.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, <Аноним>, Вы писали:

А>>>нет, это для тебя они все на одно лицо по незнанию сущности предмета.

А>>> если производить резовлинг в compile-time, то достаточно совпадения имён.

VD>>Это имеет отношение к ФП?

А>видишь ли, полиморфизм не реализуется неким волшебным образом. есть различные механизмы его реализации, которые отражаются в выразительных средствах языка. например, в C++ нет оверлоадинга по возвращаемому типу — это невомзожно в ООП. в хаскеле (и templates, afaik) такое поддерживается

Это потому что тип возвращаемого значения в С++ не входит в сигнатуру, и mangled names для функций отличающихся только им будут одинаковы. В дотнете такое возможно. И в Nemerle (это ведь ООЯ, в том числе?) можно внести такую фичу изменением нескольких строк. А не ввели её для совместимости с другими языками.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

А>>видишь ли, полиморфизм не реализуется неким волшебным образом. есть различные механизмы его реализации, которые отражаются в выразительных средствах языка. например, в C++ нет оверлоадинга по возвращаемому типу — это невомзожно в ООП. в хаскеле (и templates, afaik) такое поддерживается

СТ>Это потому что тип возвращаемого значения в С++ не входит в сигнатуру, и mangled names для функций отличающихся только им будут одинаковы.

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

>В дотнете такое возможно.

и как оно там реализовано?

>И в Nemerle (это ведь ООЯ, в том числе?) можно внести такую фичу изменением нескольких строк. А не ввели её для совместимости с другими языками.

не соблаговолишь ли ты привести эти несколько строк?

ps: впрочем, похоже, это я неправильно употребил термин. я имел в виду не перегрузку, когда несколько разных функций просто имеют одно имя и нужная из них выбирается во время компиляции, а ООП-перегрузку, когда метод наследуется из родительского класса и ему даётся другая реализация, и выбор реализации проивзодится во время работы программы на основе информации из VMT

Здравствуйте, Аноним, Вы писали:

D>>Задача — создать набор функций, задаваемый над некоторым подмножеством допустимых типов данных, расширяемым впоследствии. Для этого необходимы языковые механизмы поддерживающие выделение такого специфического подмножества, и связывающие его с этим набором функций. В самой постановке задачи зашито объединение "какие-то типы данных"+"какая-то функциональность". Любой механизм такой склейки будет выглядеть как ООП.

А>с каких это пор данные+функции=ООП?

D>Я и написал — "будет выглядеть как". Тот, кто очень хочет увидеть в этом ООП — увидит.

"да вы, доктор, просто какой-то сексуальный маньяк!"

Здравствуйте, <Аноним>, Вы писали:

>>В дотнете такое возможно.

А>и как оно там реализовано?

Гм. Обычно. В сигнатуру входят все типы: и аргументов и возвращаемого занчения. И все они принимают участие в выборе конкретного тела метода.

>>И в Nemerle (это ведь ООЯ, в том числе?) можно внести такую фичу изменением нескольких строк. А не ввели её для совместимости с другими языками.

А>не соблаговолишь ли ты привести эти несколько строк?

Ты думаешь, что я пошутил? Или не знаю, о чем говорю?

Всё оказалось даже проще. Надо было закомментировать две строки.

ncc/hierarchy/typebuilder.n

          def return_type_overload = sig_matches && m.DeclaringType.Equals (this) &&
            match ((sub_current, meth.GetMemType ())) {
              | (MType.Fun (t1, r1), MType.Fun (t2, r2))
                when t1.Fix ().Equals (t2.Fix ()) && ! r1.Fix ().Equals (r2.Fix ()) =>
                  // allow return type overloading for implicit and explicit operators
//                  unless (is_cast_op(m) && is_cast_op(meth))
//                    Message.Error(meth.Location, $"attempted return type overload on $meth and $m");
                  true
              | _ => false };

А>ps: впрочем, похоже, это я неправильно употребил термин. я имел в виду не перегрузку, когда несколько разных функций просто имеют одно имя и нужная из них выбирается во время компиляции, а ООП-перегрузку, когда метод наследуется из родительского класса и ему даётся другая реализация, и выбор реализации проивзодится во время работы программы на основе информации из VMT

Это называется не перегрузка, а... эмммм... перекрытие, кажется. Overriding, в общем. Не путать с overloading.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD2> Получается, что как раз ФП-шного решения этой проблемы не существует?

Ну, может быть в ФП самой этой проблемы не существует? Потому и решения нет?

В том же Хаскелле доступ к произвольному элементу списка можно получить по его индексу, очень похоже на массивы в обычных языках. То есть обычные алгоритмы для одномерных массивов можно применять к хаскеллевским спискам.
А вот массивы (в том числе многомерные) реализованы в виде, похожем на хеш-таблицы...

VD2> Пока что я вижу только один полноценный механизм абстрагирования в ФЯ — это классы типов Хаскеля. Причем их идея фактически заимствована из ООП. Это те же интерфейсы — вид сбоку.

Вообще-то, в интерфейсах той же Явы нет реализации методов, а в хаскеллевских классах типов — есть, и их можно при этом переопределять при необходимости.
Классы типов тогда уж больше похожи на классы С++, чем на интерфейсы Явы.

VD2> А то и вообще рассматривать ФП как отдельную технику программирования, а не как полноценную парадигму.

Если так рассуждать, то и ООП тоже всего лишь ещё одна техника программирования, а вовсе и не парадигма...

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

VD2> В общем, вопрос можно закрывать. Лично мне все стало полностью ясно. С этого времени я буду отровенно ражать над пропагандистами "чистого" ФП. Я и раньше предпологал, что чистый ФП — это вакуумный сфероконяра, а тепель я в этом просто уверен.

Мдя... смешно, честно говоря...

VD2> В общем, меня не интересуют примеры из жизни. Мен интересно услышать объяснение механизмов ФП обеспечивающих полиморфизм на уровне ООП (классы типов Хаскеля опускаем как частный случай). Или признание того, что таких механизом в ФП нет и это упущение парадигмы.

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

Криса Окасаки, Вадлера тебе советовали, но для тебя это не интересно...
Не обижайся, Влад, но твои сообщения здесь выглядят как попытка просто опустить ФП. Зачем? Непонятно...

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

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

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

D>>В Хаскелле функциональность описывается в классах типов, а реализуется либо в instance declaration'ах для типов данных, если есть специфика реализации для конкретного полиморфного типа (List, Array), либо для всего класса типов по дефолту (с возможностью перегрузки).

VD>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?

Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style.

Никаких объектов с состояниями (то есть ООП) в классах типов нет. Интерфейсы сами по себе ещё не ОО — в конце концов это же просто именованные группы функций.

D>Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style.

правильно! а c++ не является ооп языком поскольку транслируется в машинный код!

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

D>>Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style.

BZ>правильно! а c++ не является ооп языком поскольку транслируется в машинный код!

Правильно! А Булат является тем самым Анонимом, и все давно об этом догадались. :Ь

D>Правильно! А Булат является тем самым Анонимом, и все давно об этом догадались. :Ь

типа на свет выманили? :D я просто решил выяснить запоминания скольких вещей я счатливо избёг, создавая многопотчные программы на хаскеле, а не немерле-подобных языках

Здравствуйте, <Аноним>, Вы писали:

А>ТЫ НЕ ПОНИМАЕШЬ, ЧЕМ TYPE CLASSES ОТЛИТАЕТСЯ ОТ ООП.

Тебе показалось. В любом случае с людьми подобными тебе я общаться не намерен.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Знаешь, если на данном форуме нет ФП-профессионалов, авторитет которых ты признаёшь, и никто другой не может дать тебе удовлетворительного для тебя ответа, то это свидетельство не слабости парадигмы ФП, а всего лишь свидетельство слабости здесь присутствующих в области ФП...

Ага, проще уговорить себя в том, что вокруг одни недоумки, чем признать очевидное.

Ну, да мне все равно. Найдутся гении которые умудрятся дать качественную иформацию — пересмотрю свое мнение. А пока для этого нет оснований. Не принимать же за оные переходы на личности?

G>Криса Окасаки, Вадлера тебе советовали, но для тебя это не интересно...

Мне не надо советовать. Мне нужен ответ. Простой и ясный. Оного нет. И лично мне совершенно понятно почему.

G>Не обижайся, Влад, но твои сообщения здесь выглядят как попытка просто опустить ФП. Зачем? Непонятно...

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

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

ФП? Замечательно. Что в нем есть если отбросить фанатство и кастовость? Паттерн матчинг и алгебраические типы? Замечательно! Они позволяют более естественно решать некоторые задачи. Значит будем их применять. В прочем, к ФП как таковому они отностяс только потому, что были изобретены в рамках ФЯ. Рекусия? Помилуйте, я ее в С 15 лет назад использовал. Оптимизация концевой рекурсии? Замечательно! Берем!

Хотя это всего лишь оптимизация компилятора, ну да ладно. Неизменяемые переменные? Хорашая идея. Тоже берем, при условии, что это не единственный способ работы.
Ну, а зацикливание на приемах/фичах исключительно ФП мне лично не нравится. Темболее, что ФП явно ограничен. Лично мне нужен быстрый код. Жить на списках и повсеместной ленивости мне не интересно.

В общем, по жизни я вижу много интересного в ФЯ и чрезмерно религиозное отношение к ФП. Вывод простой надо взять из ФП все лучшее не потеряв при этом то лучшее, что мы уже имели в ООП, КОП и т.п.

ФП замечательно абстрагирвет на микро-уровне. ООП на макро. Их соеденение дает отличные результаты. А в купе с метапрограммированием, КОП и обобщенным программированием вообще получается отлично. А вот по отдельности у каждого подхода есть масса проблем.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Ну, может быть в ФП самой этой проблемы не существует?

Проблема существует и она очевидна.

G>В том же Хаскелле доступ к произвольному элементу списка можно получить по его индексу, очень похоже на массивы в обычных языках.

Что-то у всех преверженцов ФП большие проблем с абстракцией. Мне по фигу можно получить индексированный доступ к связанному списку или нет. Речь не о том.
Меня интересуют абстрации которые не реализуются средствами параметрического полиморфизма. В Хаскеле проблема решается путем расширения концепций ФП концепцией классов типов. Которая, по-моему, чистый перенос ОО-полиморфизма (полиморфизма в стиле ООП) в мир ФП. Как уже было сказано в этой теме альтернатива только прямая поддержка ООП в языке (гибриды) и "закат солнца вручную" с динамическим распознованием и диспатчем (что, на мой взгляд не, приемлемо).

VD2>> Пока что я вижу только один полноценный механизм абстрагирования в ФЯ — это классы типов Хаскеля. Причем их идея фактически заимствована из ООП. Это те же интерфейсы — вид сбоку.

G>Вообще-то, в интерфейсах той же Явы нет реализации методов, а в хаскеллевских классах типов — есть, и их можно при этом переопределять при необходимости.

Это мелочи. В той же Скале трэйтсы позволяют создавать абстрактные реализации как и в хаскеле. И даже применять трэйты к уже готовым типам.

G>Классы типов тогда уж больше похожи на классы С++, чем на интерфейсы Явы.

Вот на что они точно не похожи, так это на классы, так как не несут состояния. Это именно интерфейсы. Аналог в С++ — это бастракный класс. И то с натяжкой. Ну, а самый прямой аналог это трэйтсы Скалы. Вот тут вообще разница исключительно в том как "это" применяется к конкретным типам. В Скале применен традиционный ОО-подход с небольшим расширением. В Хаскеле подход АДЫ с явным воплощением. Собственно подход Хаскеля хорош, но насколько я могу понять вызывает проблемы с эффективностью при реализации или приводит к созданию системы тпов плохо совместимой с принципами КОП. В прочем, это больше с чужих слов нежели стопроцентная уверенность.

G>Если так рассуждать, то и ООП тоже всего лишь ещё одна техника программирования, а вовсе и не парадигма...

ООП все же полностью автономен. Возможно его подходы не всегда элегантны. Но за-то нет никаких проблем с абстракцией. Потому собственно он уже почти 20 лет победно шествует по планете.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Что такое "прямой" ответ?

Издеваешся?

A> Боюсь, у меня на него нет времени.

Тогде вообще не следовало пытаться отвечать.

VD>>Кстати, по ссылкам слово metaprogramming не встречается ни разу.

A>Это скорее metaprogramming в духе C++. Как в C++ язык шаблонов оказался функциональным языком времени компиляции, так в Наскелле язык классов типов оказался логическим языком времени компиляции.

То есть авторы не планировали, но можно нелегально эмулировать? В С++ это привело к очень печальным результатам. Стоило только допустить рекурсивное определение и возможность остановить рекурсию ручной специализацией и получился супер-монстр на котором с одной стороны можно многое, а с другой ничего толкового.

A> По первой ссылке туча примеров вычислений времени компиляции, обеспечения разного рода статических гарантий и т.д., по второй — тонкости как оно работает.

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

A>Ну а любителям "обычного" метапрограммирования GHC (уже давно, 4 года как, с версии 6.0) дает все что нужно — quotations, splices, доступ к AST и т.д.

Я в курсе. Только это не стандартное расширение.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

D>Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style.

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

Вот в данном случае классы типов вписываются в ФЯ, но не основаны на ФП, а расширяют его.

D>Никаких объектов с состояниями (то есть ООП) в классах типов нет.

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

Важно, что мы можем объеявить интерфейс Foldable (не важно будет ли это интерфейс Явы, трэйтс Скалы или класс типов Хаскеля), и реализовать его в/для разных (подчеркиваю, совсем разный) типов (таких как массивы, списки, деревья и т.п.).

D> Интерфейсы сами по себе ещё не ОО — в конце концов это же просто именованные группы функций.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>немерле-подобных языках

О. Новая терминалогия. Оказывается Немерле является родоначальником целой плеяды языков.

... << RSDN@Home 1.2.0 alpha rev. 637>>

VD>Нет. Конечно. Ни один применяемый в ООЯ элемент сам по себе не является ООП-ом. Но мы же понимаем, что именно в ООП родилась и развилась идея абстрактных интерфейсов?

сколько раз тебе повторять — эта идея появилась в языках с АТД. уж хотя бы про аду ты должен был слышать. это тоже ооп язык? до ады в 70-х появилась куча атд-языков. в 80-х эти идеи были привнесены в классичекий ООП (подразумевавший только наследование) и появились языки, совмещающие и то, и другое. понятное дело, что с точки зрения современных недорослей, не знающих мезу и клу, АТД являются фичей впервые появившейся в c++

Здравствуйте, <Аноним>, Вы писали:

А>вот как раз диспатч в ооп и type classes совпадает

это ты с AlgTD перепутал

Ничего я не перепутал. Может это ты меня неверно понял?
А что такое AlgTD?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Хм. Закат солнца вручную?

Я на вопрос ответил?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

D> Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style.

Ну, не обязательно. В той же Истории Хаскелла упоминается, что в JHC (John Meacham) с целью оптимизации классы типов компилируются без промежуточного представления в виде dictionary-passing: (стр. 31)

jhc is a new compiler, developed by John Meacham. It is fo-
cused on aggressive optimisation using whole-program anal-
ysis. This whole-program approach allows a completely dif-
ferent approach to implementing type classes, without using
dictionary-passing. Based on early work by Johnsson and Bo-
quist (Boquist, 1999), uses flow analysis to support a de-
functionalised representation of thunks, which can be extremely
efficient.

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

BZ>сколько раз тебе повторять — эта идея появилась в языках с АТД.

Если только в режиме эмуляции в результате чего и родился ООП.

BZ> уж хотя бы про аду ты должен был слышать. это тоже ооп язык?

Начиная с АДА 95 несомненно она стала ООЯ.

BZ> до ады в 70-х появилась куча атд-языков. в 80-х эти идеи были привнесены в классичекий ООП (подразумевавший только наследование) и появились языки, совмещающие и то, и другое. понятное дело, что с точки зрения современных недорослей, не знающих мезу и клу, АТД являются фичей впервые появившейся в c++

ОК. Надеюсь под АТД понимаетс Абстрактный Тип Данны или групбо говоря структура в С. Покажи мне, что ты имешь в виду когда говоришь, что абстрактный интерфейс == АТД.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>В том то и дело, что список не абстракция, а конкретика. Подходить, то он конечно подходит. Но конкретика есть кокретика. Он не всегда хорошо подхдит для всех задач.

Разумеется, но его и не используют для всех задач.

VD>А о производительности вообще говорить не приходится.

Когда как. Реального списка может и не быть в бинарнике, код которого весь в этих списках.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>То есть авторы не планировали,

Думаю, планировали, но не в таком объеме. Потому что формально multiparameter typeclasses пока (для Haskell 98) являются расширением (хотя они есть и в Clean), а, например, с functional dependencies до сих пор есть теоретические проблемы. Для любого другого языка это за счастье, поскольку никаких теорий вообще нет, а для Хаскелла стандартом является глубокая теоретическая фундированность, поэтому, например, была проведена "пересадка сердца и легких" — переход на System Fc.

VD>но можно нелегально эмулировать?

Почему нелегально? Удачные решения потому и являются таковыми, что уходят далеко за рамки первоначального замысла.

VD>В С++ это привело к очень печальным результатам. Стоило только допустить рекурсивное определение и возможность остановить рекурсию ручной специализацией и получился супер-монстр на котором с одной стороны можно многое, а с другой ничего толкового.

Ничего печального для C++ я не вижу, кроме синтаксического барьера. Так вот, в случае классов типов в Хаскелле этот барьер отсутствует полностью. Это делает указанное метапрограммирование абсолютно прозрачным. Например, вызов функции от любого количества аргументов любого типа и выглядит как вызов совершенно обычной функции. Разумеется, со 100% статической проверкой типов.

VD>Я в курсе. Только это не стандартное расширение.

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

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

VD>>Хм. Закат солнца вручную?

L>Я на вопрос ответил?

----------------------------------------
Приходская школ... Священник экзаминует ученика...
— Отрок! Скожи мне. Может ли душа отделиться от тела и жить отдельно?
— Может, отче!
— Обоснуй!
— Давича иду я мимо вашей кельи и слышу: "А теперь душа моя одевайся и у..ывай!". Обосновал, отче?
— Обосновал, отрок. Но припохааабнооо

Вот тут такая же фигня.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

BZ>>сколько раз тебе повторять — эта идея появилась в языках с АТД.

VD>Если только в режиме эмуляции в результате чего и родился ООП.

в режиме эмуляции — это как?

программисты прятали от товарищей исходники чтобы те не узнали имена полей? :D

BZ>> уж хотя бы про аду ты должен был слышать. это тоже ооп язык?

VD>Начиная с АДА 95 несомненно она стала ООЯ.

ясно, что аду ты тоже не знаешь

BZ>> до ады в 70-х появилась куча атд-языков. в 80-х эти идеи были привнесены в классичекий ООП (подразумевавший только наследование) и появились языки, совмещающие и то, и другое. понятное дело, что с точки зрения современных недорослей, не знающих мезу и клу, АТД являются фичей впервые появившейся в c++

VD>ОК. Надеюсь под АТД понимаетс Абстрактный Тип Данны или групбо говоря структура в С. Покажи мне, что ты имешь в виду когда говоришь, что абстрактный интерфейс == АТД.

Абстрактный Тип Данных — это не обязательно структура. это любой тип, строение которого не открытвается, а доступны только функции манипулирующие им, та самая идея сокрытия реализации, которую ты считаешь тзобретением ооп. к твоему сведению, в первых ооп языках её не было. она появилась в других языках 70-х. в 80-х c++, эйфель объединили эти две идеи. поэтому тем, для кого ооп начался со знакомства с с++, и кажется что АТД — это изобретение ооп

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

L>Здравствуйте, <Аноним>, Вы писали:

А>>вот как раз диспатч в ооп и type classes совпадает

это ты с AlgTD перепутал

L>Ничего я не перепутал. Может это ты меня неверно понял?
L>А что такое AlgTD?

алгеьраические типы данных. именно для них присходит "транспозиция" кода в то время как type classes ничем не отличаются в диспатче от ооп — instance и внутри него отдельные методы

Здравствуйте, Сергей Туленцев, Вы писали:

СТ>Это потому что тип возвращаемого значения в С++ не входит в сигнатуру, и mangled names для функций отличающихся только им будут одинаковы. В дотнете такое возможно. И в Nemerle (это ведь ООЯ, в том числе?) можно внести такую фичу изменением нескольких строк. А не ввели её для совместимости с другими языками.

Разница в том, что в дотнете это будут разные типы (не учитывая тип возвращаемого значения) из-за неявного присутствия типа объекта. В классах типов объекта нет, поэтому возможны функции, принимающие, скажем, целое, а возвращающие тот тип, который нам нужен (toEnum). В ООП такое, насколько я понимаю, невозможно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Разумеется, но его и не используют для всех задач.

Да по факту суют всюду. Даже в языки на мертво вмонтируют.

VD>>А о производительности вообще говорить не приходится.

L>Когда как.

Ага. Но так как по жизни используют его почти везде...

L>Реального списка может и не быть в бинарнике, код которого весь в этих списках.

Это очень теоритически. В прочем, это уже другая тема.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Почему нелегально? Удачные решения потому и являются таковыми, что уходят далеко за рамки первоначального замысла.

Я считаю такие решения неудачными. Мне нравится когда что я задумываю, то и полчается. И я всегда расстраиваюсь, когда выходит что-то другое (пусть даже более интересное).

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

VD>>В С++ это привело к очень печальным результатам. Стоило только допустить рекурсивное определение и возможность остановить рекурсию ручной специализацией и получился супер-монстр на котором с одной стороны можно многое, а с другой ничего толкового.

A>Ничего печального для C++ я не вижу,

А я вижу. И вижу к чему это приводит.

A>кроме синтаксического барьера.

Да фиг с ним с барьером. А вот ограниченность чем оправдывать? Ведь ни файла из "макросов" не загрузить, ни сообщения об ошибке человеческого не выдать.

A> Так вот, в случае классов типов в Хаскелле этот барьер отсутствует полностью.

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

.

A>Это делает указанное метапрограммирование абсолютно прозрачным.

Ну, да. Для тех кто считает абсолютно прозрачными 20 страниц мат.формул.

A> Например, вызов функции от любого количества аргументов любого типа и выглядит как вызов совершенно обычной функции. Разумеется, со 100% статической проверкой типов.

Для вызова функий не нужно метапрограммирования. Оно нужно для анализа и модификации/трансформации кода.

Кстати, остается вопрос одинаково ли мы понимаем термин "метапрограммирование"?

VD>>Я в курсе. Только это не стандартное расширение.

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

Это — да. Но исключения есть:
1. Лисп.
2. Руби.
3. Питон.
4. Немерле.
...
Я уже не говорю о разных эксперементах вроде ТемлеэйтХаскеля, МетаМЛ-я и т.п.

Все живые языки с не плохими реализациями.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD2> Ага, проще уговорить себя в том, что вокруг одни недоумки, чем признать очевидное.

А вот этого я не утверждал.
Однако, ну сколько людей из отметившихся в этой теме являются глубокими теоретиками в области ФП и ООП?

VD2> В общем, по жизни я вижу много интересного в ФЯ и чрезмерно религиозное отношение к ФП. Вывод простой надо взять из ФП все лучшее не потеряв при этом то лучшее, что мы уже имели в ООП, КОП и т.п.

Чистое ФП несовместимо с ООП: то, что для ООП хорошо (глобальное мутабельное состояние) — для чистого ФП — смерть...

Вообще, наверное, ты в чём-то прав...
Мне в последнее время тоже начало казаться, что в практических языках чистоты нет. Ну вот какие действительно чистые ФЯ или ООЯ используются на практике? Да нет таких...
Тот же Хаскелл — не так уж он и чист, как об этом твердят. Вот и ерлангеры тоже признают грязноватость своего языка...
В ООП — так же...
Чистые (процедрные) языки — это, наверное, только старые версии Фортрана да Бейсика... В новых и то уже ООП имеется, даже в ассемблерах...

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

L>>Ничего я не перепутал. Может это ты меня неверно понял?
L>>А что такое AlgTD?

BZ>алгеьраические типы данных. именно для них присходит "транспозиция" кода в то время как type classes ничем не отличаются в диспатче от ооп — instance и внутри него отдельные методы

Ну, в общем, я неверно выразился.
Это неважно, я говорил о другом.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Вот тут такая же фигня.

Это Лисп

Примитивов мало, но на них можно много

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

BZ> эта идея появилась в языках с АТД.

Вообще-то сами АТД (Абстрактные Типы Данных) появились именно в первом ООП языке — Симуле, ещё в 60-х годах. Самый известный и популярный язык с АТД (Паскаль) появился позже, и Вирт как раз таки перенял идею записей из Симулы, но при этом отбросил методы классов и наследование...

BZ> уж хотя бы про аду ты должен был слышать. это тоже ооп язык?

Clu, Ada-83, Modula-2 считались "объектными" языками, Ada-95 стала просто ООЯ (ООП в стиле Оберонов)...

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

L>Разница в том, что в дотнете это будут разные типы (не учитывая тип возвращаемого значения) из-за неявного присутствия типа объекта. В классах типов объекта нет, поэтому возможны функции, принимающие, скажем, целое, а возвращающие тот тип, который нам нужен (toEnum). В ООП такое, насколько я понимаю, невозможно.

В дотнете таких ограничений нет. Это ограничения конретных языков. Проистекает оно из идеологии разрешения перегрузки. К ООП вообще отношения не имеет.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>в режиме эмуляции — это как?

Тебе рассказать как на С пишут в ОО-стиле?

BZ> программисты прятали от товарищей исходники чтобы те не узнали имена полей? :D

И это тоже. Найди, к примеру, описание полей HFONT.

BZ>ясно, что аду ты тоже не знаешь

Развивайся

:
http://en.wikipedia.org/wiki/Ada_language

Ada was originally targeted at embedded and real-time systems. The Ada 95 revision, designed by S. Tucker Taft of Intermetrics between 1992 and 1995, improved support for systems, numerical, financial, and object-oriented programming (OOP).

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

Что за языки имеются в виду? В Симуле концепция АТД вроде поодериживалась.

BZ> она появилась в других языках 70-х. в 80-х c++, эйфель объединили эти две идеи. поэтому тем, для кого ооп начался со знакомства с с++, и кажется что АТД — это изобретение ооп

ОК. Допустим так. Ну, и что по-твоему, АТД не были промежуточным этапом на пути к ООП? Или ООП не включила эту концепцию в себя?

А вот где эта концепция в ФП я лично не вижу.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>... instance и внутри него отдельные методы

Гы. Вот мы уже дошли до экземляров.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

BZ>> эта идея появилась в языках с АТД.

G>Вообще-то сами АТД (Абстрактные Типы Данных) появились именно в первом ООП языке — Симуле, ещё в 60-х годах. Самый известный и популярный язык с АТД (Паскаль) появился позже, и Вирт как раз таки перенял идею записей из Симулы, но при этом отбросил методы классов и наследование...

записи — это не АТД, и паскаль — не атд-язык. если ты знаешь клу, аду или модулу-2, то должен быть в курсе, что в них есть средства сокрытия представления типа — это и есть АТД

BZ>> уж хотя бы про аду ты должен был слышать. это тоже ооп язык?

G>Clu, Ada-83, Modula-2 считались "объектными" языками

честно говоря, такую характеристику впервые слышу. подозреваю, что это то же самое, что АТД-язык?

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

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

L>>Разница в том, что в дотнете это будут разные типы (не учитывая тип возвращаемого значения) из-за неявного присутствия типа объекта. В классах типов объекта нет, поэтому возможны функции, принимающие, скажем, целое, а возвращающие тот тип, который нам нужен (toEnum). В ООП такое, насколько я понимаю, невозможно.

VD>В дотнете таких ограничений нет. Это ограничения конретных языков. Проистекает оно из идеологии разрешения перегрузки. К ООП вообще отношения не имеет.

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

вы так и будете продолжать говорить о разных вещах?

мы же с Сергеем давно разобрались — я говорил про method override, при котором невозможен диспатчинг по типу возвращемого объекта ввиду особенностей ООП

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

a> Думаю, планировали, но не в таком объеме. Потому что формально multiparameter typeclasses пока (для Haskell 98) являются расширением...

multiparameter typeclasses появились ещё в 91 году в Gofer (ещё до того, как тот превратился в HUGS), однако при стандартизации Хаскелла от них отказались, так как это усложнило бы и сам язык, и его понимание начинающими хаскеллерами, и разработку трансляторов...

Кстати, я где-то встречал упоминание, что Олег Киселёв реализовал вычисление факториала на классах типов, однако так и не нашёл этого кода.
Никто не подскажет ссылку? Это было бы хорошим примером метапрограммирования на Хаскелле. Недаром разработчики Хаскелла стали использовать термин "миллиолег" для указания своего собственного уровня понимания системы типов Хаскелла. :о))

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

VD>Ага. Но так как по жизни используют его почти везде...

"Не знаю, не мерил"

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

L>>Реального списка может и не быть в бинарнике, код которого весь в этих списках.

VD>Это очень теоритически. В прочем, это уже другая тема.

Нет, foldr/build работает давно.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

BZ>> программисты прятали от товарищей исходники чтобы те не узнали имена полей? :D

VD>И это тоже. Найди, к примеру, описание полей HFONT.

BZ>>ясно, что аду ты тоже не знаешь

VD>Развивайся

:

уж кто бы говорил

первоначальная ада была атд языком. ещё три раза потворить?

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

VD>Что за языки имеются в виду? В Симуле концепция АТД вроде поодериживалась.

каким образом? ты её вообще отличаешь от концепции наследования?

BZ>> она появилась в других языках 70-х. в 80-х c++, эйфель объединили эти две идеи. поэтому тем, для кого ооп начался со знакомства с с++, и кажется что АТД — это изобретение ооп

VD>ОК. Допустим так. Ну, и что по-твоему, АТД не были промежуточным этапом на пути к ООП? Или ООП не включила эту концепцию в себя?

VD>А вот где эта концепция в ФП я лично не вижу.

бу-га-га. значит, если в ФП что-то не сразу появилось — то эта концепция для ФП не естественна? а если в ооп что-то не сразу появилось — значит оно было только промежуточный звеном на пути развития ооп? а симула в таком разрезе вообще не была ооп языком?

я тебе как раз и пытаюсь втолковать, что и ооп, и ag концепции развиваются, включая в себя всё новые возможности. и говорить о том, что ФП не работает сам по себе только потому, что некоторые из его возможностей имеют аналоги в появившихся раньше ООП языках — это значит выдавать желаемое за действительное. да, ФП сейчас не такое, какое было 20 лет назад. и ООП за это время тоже изменилось. надеюсь, после экскурса в историю АТД ты с этим согласишься

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

G>Кстати, я где-то встречал упоминание, что Олег Киселёв реализовал вычисление факториала на классах типов, однако так и не нашёл этого кода.
G>Никто не подскажет ссылку? Это было бы хорошим примером метапрограммирования на Хаскелле. Недаром разработчики Хаскелла стали использовать термин "миллиолег" для указания своего собственного уровня понимания системы типов Хаскелла. :о))

была целая бмблиотека матвычислений. typenats, afair

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

BZ> программисты прятали от товарищей исходники чтобы те не узнали имена полей? :D

Делаем
[ccode]
#define private public
#define protected public
[/code]
и юзаем кишки чужих классов по полной программе! :о))
Вот вам и information hiding... :О(

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

A>> Например, вызов функции от любого количества аргументов любого типа и выглядит как вызов совершенно обычной функции. Разумеется, со 100% статической проверкой типов.
VD>Для вызова функий не нужно метапрограммирования. Оно нужно для анализа и модификации/трансформации кода.

Хоть горшком назови. Напишите мне на Nemerle аналог printf со статической проверкой типов без синтаксического оверхеда при вызове и без метапрограммирования. Если напишете, я признАю, что нужного Вам метапрограммирования классы типов не обеспечивают.

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

VD>Это — да. Но исключения есть:
VD>1. Лисп.
VD>2. Руби.
VD>3. Питон.
VD>4. Немерле.
VD>...
VD>Я уже не говорю о разных эксперементах вроде ТемлеэйтХаскеля, МетаМЛ-я и т.п.

VD>Все живые языки с не плохими реализациями.

Вы вообще читаете текст на который отвечаете? Я пишу "кроме лиспообразных", Вы в ответ — "Но исключения есть: 1. Лисп."

На питон есть стандарт? На руби есть стандарт? На немерле есть стандарт и больше одной имплементации???

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

VD>В дотнете таких ограничений нет. Это ограничения конретных языков. Проистекает оно из идеологии разрешения перегрузки. К ООП вообще отношения не имеет.

Возможно, я чего то не знаю. Правильно ли я понимаю, что можно написать функцию (аналогов в чистом ОО нет — что то вроде метода класса, вызываемого без указания этого класса), которая, в зависимости от контекста вызова вернет нам 1 или 'a'?

Т.е. 41 + foo() будет 42, а putch(foo()) выведет нам на консоль 'a'?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD2>> Ага, проще уговорить себя в том, что вокруг одни недоумки, чем признать очевидное.

G>А вот этого я не утверждал.
G>Однако, ну сколько людей из отметившихся в этой теме являются глубокими теоретиками в области ФП и ООП?

Ты считаешь, что, чтобы ответить на вопрос Влада, необходимо быть профессором семи университетов?

G>Тот же Хаскелл — не так уж он и чист, как об этом твердят.

Если под "чист" имеется в виду чистота в смысле отсутствия побочных эффектов — чист на 100%.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>> Clu, Ada-83, Modula-2 считались "объектными" языками

BZ> честно говоря, такую характеристику впервые слышу. подозреваю, что это то же самое, что АТД-язык?

Так назывались языки, в которых были АТД (сокрытие информации), но не было возможности организовывать иерархии типов объектов с перегрузками и прочим ООП...
То есть, недо-ООП...

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

BZ>уж кто бы говорил

Ага, кто бы не говорил, но таким как ты бесполезно.

BZ> первоначальная ада была атд языком. ещё три раза потворить?

Тебе уже про это кажется... здесь. Иди поспорь. За одно поспорь с википедией и половиной мира.

VD>>Что за языки имеются в виду? В Симуле концепция АТД вроде поодериживалась.

BZ>каким образом?

Прямым. Созданием интерфейсных классов.

BZ>ты её вообще отличаешь от концепции наследования?

Ссылку на вики тебе дали. Кури.

VD>>ОК. Допустим так. Ну, и что по-твоему, АТД не были промежуточным этапом на пути к ООП? Или ООП не включила эту концепцию в себя?

VD>>А вот где эта концепция в ФП я лично не вижу.

BZ>бу-га-га. значит, если в ФП что-то не сразу появилось — то эта концепция для ФП не естественна?

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

BZ> а если в ооп что-то не сразу появилось — значит оно было только промежуточный звеном на пути развития ооп? а симула в таком разрезе вообще не была ооп языком?

В ООП эта концепция была, есть и будет есть (с).

ЗЫ

В общем, конструктива — 0. Я завязал с тобой общаться. Будут умные мысли на этот счет, подходи, так... всех благ в личной жизни.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>вы так и будете продолжать говорить о разных вещах?

мы же с Сергеем давно разобрались — я говорил про method override, при котором невозможен диспатчинг по типу возвращемого объекта ввиду особенностей ООП

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>ФП? Замечательно. Что в нем есть если отбросить фанатство и кастовость? Паттерн матчинг и алгебраические типы? Замечательно! Они позволяют более естественно решать некоторые задачи. Значит будем их применять. В прочем, к ФП как таковому они отностяс только потому, что были изобретены в рамках ФЯ. Рекусия? Помилуйте, я ее в С 15 лет назад использовал. Оптимизация концевой рекурсии? Замечательно! Берем!

Хотя это всего лишь оптимизация компилятора, ну да ладно. Неизменяемые переменные? Хорашая идея. Тоже берем, при условии, что это не единственный способ работы.
VD>Ну, а зацикливание на приемах/фичах исключительно ФП мне лично не нравится. Темболее, что ФП явно ограничен. Лично мне нужен быстрый код. Жить на списках и повсеместной ленивости мне не интересно.

Забавно, что самое главное, что есть в ФП ты не рассмотрел.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

G>>Кстати, я где-то встречал упоминание, что Олег Киселёв реализовал вычисление факториала на классах типов, однако так и не нашёл этого кода.

D>Не Олег, но...
D>здесь

мдя, круто:

:t fac four

fac four :: Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ Zero)))))))))))))))))))))))

:о)

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

L> Если под "чист" имеется в виду чистота в смысле отсутствия побочных эффектов — чист на 100%.

Боюсь, это миф... Или, как написал мне как-то Булат, "наш агитпункт".

Хотя в стандарте Хаскелл-98 нет, но реально во всех реализациях Хаскелла имеются те же самые IORef, MVar, unsafePerformIO...

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

G>мдя, круто:

G>:t fac four

G>fac four :: Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ Zero)))))))))))))))))))))))

G>:о)

Ну если нравится — юзай упомянутый Булатом Typenats.

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

VD>В нем присуствует расширение которое не имеет отношния к ООП. Хаскель обладает мощьной стистемой типов которая очень похожа на то, что мы выидим в ООП. Только в ООП это прямая заслуга парадигмы, а в Хаскеле исключительно его разработчиков.

Хиндли и Милнер разрабатывали Хаскель?

VD>Меня больше занимает другой вопрос. Имеет ли смысл вообще рассматривать ФП как отдельную прарадигму. Похоже, что в чистом виде она ущербна, и имеет смысл только в купе с некой иделогией типов которая в чистом виде имеется только в ООП.

Это вопрос взгляда. Чем больше я читаю теорию типов, тем больше убеждаюсь в ущербности именно ООП.
Чистый ООП — это объекты, получающие сообщения, — эдакий смолтолк без блоков, и даже наследования, он решает поставленную тобой проблему. Тем не менее каждый ОО язык расширяет эту схему. Точно так отличаются ФЯ от ФП. Чистое (в смысле "только") ФП — это лямбды.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>В общем, вопрос можно закрывать. Лично мне все стало полностью ясно. С этого времени я буду отровенно ражать над пропагандистами "чистого" ФП. Я и раньше предпологал, что чистый ФП — это вакуумный сфероконяра, а тепель я в этом просто уверен.

Откровенно рАжать над пропагандистами?? Боюсь даже представить себе эту сцену.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Возможно, я чего то не знаю. Правильно ли я понимаю, что можно написать функцию (аналогов в чистом ОО нет — что то вроде метода класса, вызываемого без указания этого класса), которая, в зависимости от контекста вызова вернет нам 1 или 'a'?

Процесс вызова метода в IL выглядит так. Мы помещаем параметры возова в стек виртуальной машины. Далее указываем инструкцию call или callvirt. Затем мы указываем полную сигнатуру метода который хотим вызвать.
Например:

L_0007: ldstr "TraceSourceLtm"
L_000c: call string System.Transactions.SR::GetString(string)

L>Т.е. 41 + foo() будет 42, а putch(foo()) выведет нам на консоль 'a'?

В такой постановке задачи ответ будет — да.

Но при приведенной тобой записи компилятор языка программирования должен уметь понять, что за сигнатуру метода нужно засунуть в IL. Компилятор C# туп и не может это сделат. А вот алгоритм вывода типов Немерле в 99% случаев способен вывести тип, так как делает это из всего использования. В первом случае он увидит, что есть две сигнатуры:

int foo()
char foo()

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

Самое смешное, что даже компилятор C# "балуется" разрешением вызова по возвращаемому значению когда он подбирает правлиьный оператор приведения типов.

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

ЗЫ

Блин. Что-то я снова погряз в форумах. Пора нафиг от сюда валить

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Хоть горшком назови. Напишите мне на Nemerle аналог printf со статической проверкой типов без синтаксического оверхеда при вызове и без метапрограммирования. Если напишете, я признАю, что нужного Вам метапрограммирования классы типов не обеспечивают.

Для этого достаточно перегрузки. Метод Console.WriteLine так и делает.
Но вообще для этой задачи какраз метапрограммирование подходит хорошо. Но ты же говорил про вызов метода, а не про проверку соответствия списка параметров некому шаблону.

VD>>Это — да. Но исключения есть:
VD>>1. Лисп.
VD>>2. Руби.
VD>>3. Питон.
VD>>4. Немерле.
VD>>...
VD>>Я уже не говорю о разных эксперементах вроде ТемлеэйтХаскеля, МетаМЛ-я и т.п.

VD>>Все живые языки с не плохими реализациями.

A>Вы вообще читаете текст на который отвечаете? Я пишу "кроме лиспообразных", Вы в ответ — "Но исключения есть: 1. Лисп."

А пункты 2-4 ты как бы незаметил?

A>На питон есть стандарт? На руби есть стандарт? На немерле есть стандарт и больше одной имплементации???

Есть стандарты де факто. А Лисп хоть формально стандартизирован, но я не смог скопилировать половину приперов на разных компиляторах которые казалось бы поддерживали стандарт CL.

Так что в твоем привязывании к стандарту я вижу попытку зацепиться за что-то чтобы обосновать неверное утверждение.

Наличие единой реализации — это намного лучше стадарта. Отчасти потому Руби и Питон во всю использются на практике, а Лисп при пенесометрии.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ> была целая бмблиотека матвычислений. typenats, afair

TypeNats

Description

This module defines type-level natural numbers and arithmetic operation on them including addition, subtraction, multiplication, division and GCD.

Numbers are represented as a list of binary digits, terminated by a distinguished type Z. Least significant digits are outermost, which makes the numbers little-endian when read.

Because a binary representation is used, reasonably large numbers can be represented. I have personally done tests with numbers at the order of 10^15 in GHC. However, larger numbers require the GHC '-fcontext-stack' option. For example, the test suite sets '-fcontext-stack64'.

Because of the limitations of typeclasses, some of the algorithms are pretty messy. The division algorithm is particularly ugly. Suggestions for improvements are welcome.

Впечатляет...
А что за limitations of typeclasses имеются в виду?

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

L>> Если под "чист" имеется в виду чистота в смысле отсутствия побочных эффектов — чист на 100%.

G>Боюсь, это миф... Или, как написал мне как-то Булат, "наш агитпункт".

G>Хотя в стандарте Хаскелл-98 нет, но реально во всех реализациях Хаскелла имеются те же самые IORef, MVar, unsafePerformIO...

IORef, MVar — не делают функции грязными. unsafePerformIO — увы.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Забавно, что самое главное, что есть в ФП ты не рассмотрел.

Дык мне оно и не надо. Мне ведь не шашечки, а ехать надо.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Хотя в стандарте Хаскелл-98 нет, но реально во всех реализациях Хаскелла имеются те же самые IORef, MVar, unsafePerformIO...

IORef и MVar — чистые на 100%. unsafePerformIO... — нет. Но так и RTS написана на C. Что теперь делать? Можно допустить формально грязные вещи, если вы покажете, что результат чист, (Киселев здесь употреблял термин trusted kernel). В библиотеках, входящих в поставку GHC, unsafePerformIO применяется безопасно. При практическом програмировании на GHC вы всегда можете исходить из презумпции абсолютной чистоты, если САМИ не применяете вовсе или применяете unsafe... безопасно. Это все очевидные вещи, тут не о чем говорить.

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

G>мдя, круто:

G>:t fac four

G>fac four :: Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ (Succ Zero)))))))))))))))))))))))

В Омеге есть интересная особенность, там этот тип сахарится как #24.
Удобно для практического использования dependent types.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Так что в твоем привязывании к стандарту я вижу попытку зацепиться за что-то чтобы обосновать неверное утверждение.

Да вовсе нет. Просто для GHC наличие Template Haskell было указано как "нестандартное расширение", на что я и возразил резонно, что у большинства воображаемых конкурентов нет даже ситуации "стандарт + несколько реализаций".

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

VD>Процесс вызова метода в IL выглядит так. Мы помещаем параметры возова в стек виртуальной машины. Далее указываем инструкцию call или callvirt. Затем мы указываем полную сигнатуру метода который хотим вызвать.

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

VD>ЗЫ

VD>Блин. Что-то я снова погряз в форумах. Пора нафиг от сюда валить

.

А?! Кто здесь?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Впечатляет...
G>А что за limitations of typeclasses имеются в виду?

ХЗ. Язык не тьюринг полон? Я просто не помню как чёрчевские нумералы делятся.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>Для этого достаточно перегрузки. Метод Console.WriteLine так и делает.
VD>Но вообще для этой задачи какраз метапрограммирование подходит хорошо. Но ты же говорил про вызов метода, а не про проверку соответствия списка параметров некому шаблону.

Не знаю Немерле, проверять лень.

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

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

И это только один из многочисленных вариантов использования классов типов для метапрограммирования. Например, в typechecker полностью вкладывается арифметика (все это есть по ссылкам), далее везде.

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

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

G>>Впечатляет...
G>>А что за limitations of typeclasses имеются в виду?

L>ХЗ. Язык не тьюринг полон? Я просто не помню как чёрчевские нумералы делятся.

рполон, но неудобен, там же написано — ugly code. по сравнению с тьюринг-машиной он даже в чём-то проще

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

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

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

G>>>Впечатляет...
G>>>А что за limitations of typeclasses имеются в виду?

L>>ХЗ. Язык не тьюринг полон? Я просто не помню как чёрчевские нумералы делятся.

BZ>рполон, но неудобен, там же написано — ugly code. по сравнению с тьюринг-машиной он даже в чём-то проще

Его фундепсы полным делают? Или достаточно мультипараметрических классов типов? Потому что у Haskell98 система типов, вроде, не полная.

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

BZ>>рполон, но неудобен, там же написано — ugly code. по сравнению с тьюринг-машиной он даже в чём-то проще

D>Его фундепсы полным делают? Или достаточно мультипараметрических классов типов? Потому что у Haskell98 система типов, вроде, не полная.

Кстати, задачка (которую и полноту докажет

)

Реализовать на типах S и K. (Можно и лямбду)

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

А>>Ну а в лиспе есть дженерики — позволяют "вызывать" методы, определённые вообще для чего угодно...

VD>Ну, вызови для массива car/cdr, если так.

И кто мне запретит в пределах моего модуля переопределить их как дженерики?

И опять же — тебе внешний вид, или результат?

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

А>>Не совсем понятно, что именно тебе "надо"

VD>Если очень сило себе это внушать, то возможно. Похже, что остальные поняли все отлично.

Только судя по ответам каждый понял своё...

А>>На списках можно сделать почти всё (см. SICP).

VD>"Почти" это уже само по себе смешно.

Я намеренно написал "почти", дабы ко мне не приставали с "квантором всеобщности"

VD>Да и вопрос не в этом. Скажем действительно все можно выразить буквально 5-ю ассемблерными инструкциями где даже call в общем-то не нужен. Но речь то и дет об абстрации.

В лиспе мало средств для построения абстракций?

А>>"Чистую парадигму" ФП на чём излагать?

VD>Меня больше занимает другой вопрос. Имеет ли смысл вообще рассматривать ФП как отдельную прарадигму. Похоже, что в чистом виде она ущербна, и имеет смысл только в купе с некой иделогией типов которая в чистом виде имеется только в ООП.

А с какого ты "идеологию типов" наделил характеристикой "принадлжеит ООП"?

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

VD>Есть стандарты де факто. А Лисп хоть формально стандартизирован, но я не смог скопилировать половину приперов на разных компиляторах которые казалось бы поддерживали стандарт CL.

Хух, а примеры полностью соответствовали стандарту?

VD>Наличие единой реализации — это намного лучше стадарта. Отчасти потому Руби и Питон во всю использются на практике, а Лисп при пенесометрии.

Ложь... Раньше я был о Вас лучшего мнения...

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

А>> На списках можно сделать почти всё (см. SICP).

VD> "Почти" это уже само по себе смешно.

Да не почти, а просто всё — вопрос желания и фантазии.
В самой первой версии Лиспа Маккарти даже арифметику сделал на списках, без чисел. Типа, 0 — пустой список, 1 — список из одного элемента и т.д.
Другое дело, что это может быть не практично в реальном использовании...

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

L>>ХЗ. Язык не тьюринг полон? Я просто не помню как чёрчевские нумералы делятся.

BZ>рполон, но неудобен, там же написано — ugly code. по сравнению с тьюринг-машиной он даже в чём-то проще

Как же он полон, если вывод типов всегда должен завершаться?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Как же он полон, если вывод типов всегда должен завершаться?
-fallow-undecidable-instances ?

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

VD>>Процесс вызова метода в IL выглядит так. Мы помещаем параметры возова в стек виртуальной машины. Далее указываем инструкцию call или callvirt. Затем мы указываем полную сигнатуру метода который хотим вызвать.

L>Прикольно, т.е. теоретически можно вывести и запихнуть,

Можно практически. Незнаю, только что значит "запихнуть".

L> но вот с полиморфизмом (когда от них зависят другие функции) уже не сработает,

Блин. Полиморфизм полиморфизму рознь. При перегрузке (overloading) используется статический полиморфизм. И только от устройства языка зависит можно ли перегружать функции по возвращаемому значению или нет. При переопределении (overriding) мы имеем один метод который просто физически не может возвращать разные значения.

L> потому что надо пихать сразу. Но хоть так, интересно.

Ничего не понял. Что куда надо пихать?

Еще раз. В C#/C++ не принято (стандартами языков) перегружать фукнции по возвращаемому значению. Для совместимости с ними другие языки зачастую выбирают ту же стратегию. Но ни к ООП ни к рантайму это отношения не имеет. А то кто утвреждает обратное просто профан и трепачь пытающийся сделать умное лицо (привет анониму).

VD>>Блин. Что-то я снова погряз в форумах. Пора нафиг от сюда валить

.

L>А?! Кто здесь?

И главное, зачем?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>...И это только один из многочисленных вариантов использования классов типов для метапрограммирования. Например, в typechecker полностью вкладывается арифметика (все это есть по ссылкам), далее везде.

А почему для метапрограммирования используются не предназначенные специально для этого вещи?

Зачем все делать через зад? Сами же говорите, что тот же ТемплэйтХаскель (или что-то там) доступен всем. Так почему бы им не воспользоваться?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

L>> но вот с полиморфизмом (когда от них зависят другие функции) уже не сработает,

VD>Блин. Полиморфизм полиморфизму рознь.

Это неважно.

L>> потому что надо пихать сразу. Но хоть так, интересно.

VD>Ничего не понял. Что куда надо пихать?

Точную сигнатуру в IL.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

VD>Блин. Полиморфизм полиморфизму рознь. При перегрузке (overloading) используется статический полиморфизм. И только от устройства языка зависит можно ли перегружать функции по возвращаемому значению или нет. При переопределении (overriding) мы имеем один метод который просто физически не может возвращать разные значения.

в ооп не может. с type classes может. я тебе уже раз 10 потворил, что у них разная семантика, а ты о type classes чисто с точки зрения синтаксиса судишь что это вроде как интерфейсы. вот и подумай, могут ли интефрейсы в c$ такое обеспечить

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

VD>>Блин. Полиморфизм полиморфизму рознь.

L>Это неважно.

Очень важно.

L>Точную сигнатуру в IL.

Она в нем всегда точная.

... << RSDN@Home 1.2.0 alpha rev. 637>>

VladD2,

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

VD>В общем, вопрос можно закрывать. Лично мне все стало полностью ясно. С этого времени я буду отровенно ражать над пропагандистами "чистого" ФП. Я и раньше предпологал, что чистый ФП — это вакуумный сфероконяра, а тепель я в этом просто уверен.

Твои посты в этом топике (увы, я всё прочитал) навевают только мысли подобные

Many a troll hath usenet seen,
none so fine as he hath been.
Feed him once, he's back for more,
calls himself a true Lisp whore.
Say "you fool", he says "I am!",
send him mail, he doth post spam.

Tell me, aged one of old:
Why oh why do they feed trolls?

или

                             ___________________________ 
                    /|  /|  |                          | 
                    ||__||  |       Please don't       | 
                   /   O O\__           feed           | 
                  /          \       the trolls        | 
                 /      \     \                        | 
                /   _    \     \ ---------------------- 
               /    |\____\     \     ||                 
              /     | | | |\____/     ||                 
             /       \|_|_|/   |    __||                 
            /  /  \            |____| ||                 
           /   |   | /|        |      --|               
           |   |   |//         |____  --|               
    * _    |  |_|_|_|          |     \-/                 
 *-- _--\ _ \     //           |                         
   /  _     \\ _ //   |        /                         
 *  /   \_ /- | -     |       |                         
   *      ___ c_c_c_C/ \C_c_c_c____________

или

          \|||/ 
          (@ @) 
 |~~~~ooO~~(_)~~~~~~~| 
 | Please            | 
 | don't feed the    | 
 | TROLL!            | 
 '~~~~~~~~~~~~~~Ooo~~' 
         |__|__| 
          || || 
         ooO Ooo

Зачем ты занимаешься этим?

ps: Хуже троля может быть только троль с банилкой.

A>>...И это только один из многочисленных вариантов использования классов типов для метапрограммирования. Например, в typechecker полностью вкладывается арифметика (все это есть по ссылкам), далее везде.

VD>А почему для метапрограммирования используются не предназначенные специально для этого вещи?

VD>Зачем все делать через зад? Сами же говорите, что тот же ТемплэйтХаскель (или что-то там) доступен всем. Так почему бы им не воспользоваться?

так им и пользуются. можно — не значит нужно

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

VD>>>Блин. Полиморфизм полиморфизму рознь.

L>>Это неважно.

VD>Очень важно.

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

L>>Точную сигнатуру в IL.

VD>Она в нем всегда точная.

Именно из-за этого.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

G>>То что есть в Хаскельном примере — это только полиморфизм. Зато какой!

ОО отдыхает.

VD>Полиморфизм и инкапсуляция присутсвтуют в полном объеме.

Инкапсуляция не присутствует в полном объеме. Присутствует ADT. А это не одно и то же.

G>>>То что есть в Хаскельном примере — это только полиморфизм. Зато какой!

ОО отдыхает.

VD>>Полиморфизм и инкапсуляция присутсвтуют в полном объеме.

G>Инкапсуляция не присутствует в полном объеме. Присутствует ADT. А это не одно и то же.

а что такое тогда инкапсуляция?

Здравствуйте, Аноним, Вы писали:

G>>благодаря ленивости и оптимизации deforestation промежуточный список компилятор вообще вырежет, и сгенерирует вместо него код однонаправленного итератора.

А>вряд ли. насколько я разбираюсь, спислк так и будет лениво генерироваться в процессе потребления. deforestatuion делают специально в отдельных библиотеках на RULES. реально оно сейчас есть в bytestring и parallel arrays — afaik. точнее, его называют stream fusion

А>(если я что-то неправильно понимаю — исправляйте)

Ок, я на самом деле точно не знаю, но пусть так — он будет лениво генерироваться. Даже в этом случае сложность пробежки по контейнеру у нас будет такая же, как в случае с итератором. Тут важно — будет ли этот код работать на постоянной памяти, т.е. будет ли дергаться GC при удалении ранее созданных елментов списка. Так вот — в Gentle Introduction вроде как сказано, что для случая с числами фибонначи (а это у нас превратиться в рекурсивную функцию генерящую список) копилятор статически рассчитывает, что надо хранить только два последних элемента, и работает в обход GC, управляя памятью статически. Что в сущности совершенно аналогично итератору.

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

G>>>>То что есть в Хаскельном примере — это только полиморфизм. Зато какой!

ОО отдыхает.

VD>>>Полиморфизм и инкапсуляция присутсвтуют в полном объеме.

G>>Инкапсуляция не присутствует в полном объеме. Присутствует ADT. А это не одно и то же.

BZ>а что такое тогда инкапсуляция?

ADT — Abstract Data Type. Тип данных, который определяется только операциями над ним (абстрактным интерфесом).
Инкапсуляция = ADT + инкапсулированное изменяемое состояние, к которому нет прямого доступа — только через абстрактный интерфейс. Внимание на наличии изменяемого состояния не акцентируют, так как наличие его в императивных языках — само собой разумеющийся факт.

Разница довольно тонка и кажется незначительной, однако на одном ADT без состояния (все методы const) нельзя сделать объектную декомпозицию. Вы не сможете представить систему как состоящую из набора объектов, каждый из которых живет своей жизнью. Первая же кольцевая или обратная ссылка вам испортит все.

Здравствуйте, Аноним, Вы писали:

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

VD>>Здравствуйте, <Аноним>, Вы писали:

А>>>первое. нужно противопоставить ООП и полиморфизм. при ООП каждый объект включает VMT, из которой берутся реализации операций. при полиморфном программировании реализации операций передаются отдельным (невидимым) аргументом. полиморфизм совместим с type inference. STL в C++ как я понимаю, это полиморфизм в чистом виде — никаких VMT, вывод типов, реализации алгоритмов не включены в состав объектов, хотя и не передаются отдельным аргументом — они просто подставляются во время компиляции. поравьте меня, если я плохо знаю STL, но там нет и не иожет быть никакого наследования алгоритмов, поскольку они сделаны на templates, a templates — это и есть compile-time polymorphism, не имеющий никакого отношения к ООП. в STL достаточно использовать стандартную схему наименования для новых коллекций, никакого ООП наследования не требуется, верно?

что-то ты не то говоришь

VD>>ООП никогда не упирался в VMT и другие проблемы реализации. В ООП есть главное, чего нет в ФП. В ООП есть понятие интерфейса. Чего-то абстрактного что определяет набор методов которые должен реализовать некий объект.

А>это есть уже в концепции АТД. ооп от неё отличается механизмами наследования, которые невозможно реализовать без VMT. если ты с этим несогласен — попробуй описать другую реализацию классов C++

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

>>Это позволяет применять к разнм (совсем, разные, не связанные ничем) объектам одни и те же функции/методы. Причем совершенно по фигу когда производится разрешение типов, в компайл-тайме (как в С++-шаблонах), или в рантайме (как в интерфейсах Явы/C# или трэйстах Скалы). Важно, что есть механизм полного абстрагирования от конкретного типа. Такой механизм есть и в Хаскеле. Это классы типов. Суть их полностью аналогична ОО-интерфейсам.

А>нет, это для тебя они все на одно лицо по незнанию сущности предмета. если производить резовлинг в compile-time, то достаточно совпадения имён. у одного типа есть метод show и у другого типа есть метод с таким же именем — значит его можно вызывать не задумываясь о конкретном типе. когда же дело доходит до выбора соотвествующей типу реализации этого show во время работы, то здесь уже одного совпадения имён недостаточно. нужно как-то в процессе работы превратить этот обобщённый вызов show в конкретный адрес процедуры. ООП подход делает таблицу методов частью самого объекта. type classes передаёт таблицу методов в качестве отдельного скрытого параметра. из этого различия в реализации вытекают различия в возможностях того и другого подхода

только фиртуальных, к твоему сведению. Ты вообще что хочешь этим сказать?

[]

G>>>благодаря ленивости и оптимизации deforestation промежуточный список компилятор вообще вырежет, и сгенерирует вместо него код однонаправленного итератора.

А>>вряд ли. насколько я разбираюсь, спислк так и будет лениво генерироваться в процессе потребления. deforestatuion делают специально в отдельных библиотеках на RULES. реально оно сейчас есть в bytestring и parallel arrays — afaik. точнее, его называют stream fusion

А>>(если я что-то неправильно понимаю — исправляйте)

G>Ок, я на самом деле точно не знаю, но пусть так — он будет лениво генерироваться. Даже в этом случае сложность пробежки по контейнеру у нас будет такая же, как в случае с итератором.

с этим я согласен

G>Тут важно — будет ли этот код работать на постоянной памяти, т.е. будет ли дергаться GC при удалении ранее созданных елментов списка. Так вот — в Gentle Introduction вроде как сказано, что для случая с числами фибонначи (а это у нас превратиться в рекурсивную функцию генерящую список) копилятор статически рассчитывает, что надо хранить только два последних элемента, и работает в обход GC, управляя памятью статически. Что в сущности совершенно аналогично итератору.

тут я могу дать более точные объяснения. память собирается в два поколения (надеюсь, ты в курсе этой системы, она сейчас похоже используется повсеместно — и в erlang, и в java). поэтому tail-recursive фукнция, генерящая короткоживущие объекты, будет заполнять 256-кб блок, затем он будет освобождаться minor GC и т.д. это работает очень эффективно (gc потом насчитывает гигабайты выделенных и освоюбодждённых данных), хотя строго говоря это всё же не статическое распределение. да, 256 кб блок выбран для того, чтобы влезать в кеш, его размер региулируется с командной строки, но к сожалению автоподбора размера этого блока нету

А>>это есть уже в концепции АТД. ооп от неё отличается механизмами наследования, которые невозможно реализовать без VMT. если ты с этим несогласен — попробуй описать другую реализацию классов C++

КЛ>я уже как-то раз уличал тебя в незнании c++, так ты опять говоришь о нем. VMT нужен только для полиморфизма (читай фиртуальных функций). Наследование же спокойно обходится без него.

я же подробнейшим образом об этом и пишу. мы можем опираться на compile-time overloading. наследвоание бещз виртуальных функций — это его разновидность, как и обычный overolad, и templates тоже. если же мы хотим делать run-time overloading, то нужно передавать информацию о типе, которая позволит найти нужную реализацию функций. OOP и type classes это делают по-разному, что приводит к различиям в их возможнстях. ты не поверишь, я это Владу пытаюсь втоковать уже несколько дней. но Влад у нас — не читатель, он модератор

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

BZ>тут я могу дать более точные объяснения. память собирается в два поколения (надеюсь, ты в курсе этой системы, она сейчас похоже используется повсеместно — и в erlang, и в java). поэтому tail-recursive фукнция, генерящая короткоживущие объекты, будет заполнять 256-кб блок, затем он будет освобождаться minor GC и т.д. это работает очень эффективно (gc потом насчитывает гигабайты выделенных и освоюбодждённых данных), хотя строго говоря это всё же не статическое распределение. да, 256 кб блок выбран для того, чтобы влезать в кеш, его размер региулируется с командной строки, но к сожалению автоподбора размера этого блока нету
Не знаю как в жабе но в .NET 3 поколения.
0 — для короткоживущих
1 — для тех кто случайно пережил сборку нулевого
2 — для долгоживущих

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

... << RSDN@Home 1.2.0 alpha rev. 673>>

BZ>>это работает очень эффективно (gc потом насчитывает гигабайты выделенных и освобождённых данных),

имеется в виду — в секунду. на простейших хвострекурсивных функциях

WH>Не знаю как в жабе но в .NET 3 поколения.
WH>0 — для короткоживущих
WH>1 — для тех кто случайно пережил сборку нулевого
WH>2 — для долгоживущих

в ghc регулируется от 1 до бесконечности, по умолчанию 2

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

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

Насколько я понимаю полиморфизм, как таковой, нужен исключительно для обобщенного программирования. Эта парадигма (техника?) программирования ИМХО ортогональна обоим подходам, т.е. в чистом виде не относиться ни туда ни туда. А служит для разделения алгоритма и поведения конкретного типа/класса. А реализации в ООЯ и ФЯ отличаются соответственно парадигме — есть состояние/нет состояния.

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

G>Разница довольно тонка и кажется незначительной, однако на одном ADT без состояния (все методы const) нельзя сделать объектную декомпозицию. Вы не сможете представить систему как состоящую из набора объектов, каждый из которых живет своей жизнью. Первая же кольцевая или обратная ссылка вам испортит все.

С ленивостью можно и кольцевую и обратную. Так что дело не в них, дело, насколько я понимаю, именно в изменении состояния.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>Разница довольно тонка и кажется незначительной, однако на одном ADT без состояния (все методы const) нельзя сделать объектную декомпозицию. Вы не сможете представить систему как состоящую из набора объектов, каждый из которых живет своей жизнью. Первая же кольцевая или обратная ссылка вам испортит все.

L>С ленивостью можно и кольцевую и обратную. Так что дело не в них, дело, насколько я понимаю, именно в изменении состояния.

Дело в состоянии и идентити. А кольцевые ссылки — пример, на которм это хорошо видно. Дело в том, что эти кольцевые ссылки разъедутся, когда ты попытаешься выполнить "функциональный апдейт", откопировав объект и изменив ему состояние (ссылки будут указывать на старые, не измененные объекты). А они разъезжаться не должны. Таким образом, ты не сможешь отмоделировать время в этой связанной кольцевыми ссылками системе. Эта тема очень хорошо покрыта в курсе SICP. Монадные фокусы, посредством которых это все-таки можно изобразить в Хаскеле, по сути — не чисты и не ФП.

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

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

DC>Насколько я понимаю полиморфизм, как таковой, нужен исключительно для обобщенного программирования. Эта парадигма (техника?) программирования ИМХО ортогональна обоим подходам, т.е. в чистом виде не относиться ни туда ни туда. А служит для разделения алгоритма и поведения конкретного типа/класса.

Согласен. Но я и не говорил, что ООП — это фактически классы типов

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>Здравствуйте, dr.Chaos, Вы писали:

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

DC>>Насколько я понимаю полиморфизм, как таковой, нужен исключительно для обобщенного программирования. Эта парадигма (техника?) программирования ИМХО ортогональна обоим подходам, т.е. в чистом виде не относиться ни туда ни туда. А служит для разделения алгоритма и поведения конкретного типа/класса.

L>Согласен. Но я и не говорил, что ООП — это фактически классы типов

Я, собственно, дополнил

VladD2 wrote:

> L>Реального списка может и не быть в бинарнике, код которого весь в этих
> списках.
> Это очень теоритически. В прочем, это уже другая тема.
Если вспомнить бесконечные списки в хаскеле, то они по твоей теории не могут существовать.

Posted via RSDN NNTP Server 2.1 beta

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

L>>С ленивостью можно и кольцевую и обратную. Так что дело не в них, дело, насколько я понимаю, именно в изменении состояния.

G>Дело в состоянии и идентити. А кольцевые ссылки — пример, на которм это хорошо видно. Дело в том, что эти кольцевые ссылки разъедутся, когда ты попытаешься выполнить "функциональный апдейт", откопировав объект и изменив ему состояние (ссылки будут указывать на старые, не измененные объекты). А они разъезжаться не должны.

Да, об этом я и говорил.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Инкапсуляция не присутствует в полном объеме. Присутствует ADT. А это не одно и то же.

Абстрактный тип данных полностью удовлетваряет принципу инкапсуляции.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>так им и пользуются. можно — не значит нужно

Как видишь тут идут разговоры о метапрограммировнии на базе системы типов, т.е. внеполовом извращении.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Я не понимаю как это может быть не важно.

L>Кстати, даже на уровне выражений вывести тип не всегда возможно из-за нестрогости типизации (в частности, неявного приведения).

Все зависит от алгоритма. Немерловому алгоритму приведения типо не мешают.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>Зачем ты занимаешься этим?

LCR>ps: Хуже троля может быть только троль с банилкой.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

LCR>>ps: Хуже троля может быть только троль с банилкой.

VD>Не надо пытаться приклеить ярлык к тому с кем не согласен, даже если не можешь возразить по существу.

тебе же сказали по существу — прочти статью Вадлера, разберись с тем, что такое type classes

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

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

G>>Инкапсуляция не присутствует в полном объеме. Присутствует ADT. А это не одно и то же.

VD>Абстрактный тип данных полностью удовлетваряет принципу инкапсуляции.

Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.

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

VD2> Как видишь тут идут разговоры о метапрограммировнии на базе системы типов, т.е. внеполовом извращении.

То есть смоллтокеры, занимающиеся метапрограммированием на метаклассах (на базе систему типов) — тоже извращенцы?

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

В конце концов, что есть метапрограмма? Это всего лишь программа, которая при трансляции или выполнении порождает другую программу (имею в виду — программу на том же языке, а не в машинных кодах), которая потом и выполняется.

Почему это нужно делать только на макросах-то???

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

G>Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.

АТД — это практически интерфейс плюс конструктор. Он родился в императивном мире. Состояние в нем не быть не может.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

VD2>> Как видишь тут идут разговоры о метапрограммировнии на базе системы типов, т.е. внеполовом извращении.

G>То есть смоллтокеры, занимающиеся метапрограммированием на метаклассах (на базе систему типов) — тоже извращенцы?

Вобще-то я за всю жизнь не видел ни одной прогарммы на Смолтоке (чтобы она что-то полезное делала). Так что говорить о нем как о чем-то реальном у меня рука не поднимается

Но все же их упражнения с метаклассами:
1. Не является полноценным средством МП, так как не опзволяет порождать код. Код они порождкают в виде текстовых строк, которые могут тупо интепретироват (возможно джитить).
2. Это не является нецеливым использованием системы типов. Их метаклассы — это захардкоженая реализация фабрик лассов. К саомй системе типов отношения не имющая.

С++ же, и как я понимаю, Хаскель испльзуют побочные эффекты работы именно ситемы типов.

G>Влад, ты зашорил своё представление о метапрограммировании макросами Лиспов и Немерле, а ведь есть и другие способы...

Я знаком со всеми известными на дакнный момент системами МП. И прекрасно понимаю как и что в них работает. Так что не надо.

G>В конце концов, что есть метапрограмма? Это всего лишь программа, которая при трансляции или выполнении порождает другую программу (имею в виду — программу на том же языке, а не в машинных кодах), которая потом и выполняется.

Не при трансляци, а при работе. Мета-программа — это программа порождающая программу. Все. Более ничего. Так вот есть огромная разница в том являются ли средства МП продуманными и что называется "нарошными", и когда используются разные побочные эффекты средств которые для данной цели не были предназначены. Второй путь ведет к дикому переусложению, неполноценности, и как следствие, к вострженным возгласам "а Вася Пупкин на ххх умудрился фибаначи посчитать". Причем такой бред несется с горящими глазками, как будто была решена вселенская задача, а не примитивный, никому не нужный примерчик.

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

G>Почему это нужно делать только на макросах-то???

Да пофигу как это назвать. Главное чтобы было полноценно, удобно и не через зад.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>тебе же сказали по существу — прочти статью Вадлера, разберись с тем, что такое type classes

Я разабрался с тем, что такое классы типов, по крайней мерее в той степени, чтобы понимать что это такое.

Так что если есть, что сказать... иначе не фига засорять эфир.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

G>>Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.

VD>АТД — это практически интерфейс плюс конструктор. Он родился в императивном мире. Состояние в нем не быть не может.

Ты что-то часто стал апеллировать к такой "неестественной" науке, как история

ADT — это абстрактный тип данных, и чем больше он абстрагирован, тем лучше.

Например, стек:
это три операции

push :: Stack -> Elem -> Stack
pop :: Stack -> Stack
top :: Stack -> Elem

и два закона

pop (push s e) === s
top (push s e) === e

Этого достаточно для описания аксиоматической семантики ADT стек (хотя можно ещё расширить её с помощью isEmpty). Язык описания, как ты понимаешь, можно выбрать другой.

в качестве ремарки:

Обобщаем интерфейс

f :: a -> b -> a
g :: a -> a
h :: a -> b

+ те же законы

g (f s e) === s
h (f s e) === e

Любая пара типов a и b, с заданным набором функций f, g, h, подчиняющихся этим двум законам, всё равно образуют АТД стек.

А есть там в реализации состояние или нет — это дело десятое. И эту абстракцию ты в ООП не выразишь.

Здравствуйте, deniok, Вы писали:
D> Язык описания, как ты понимаешь, можно выбрать другой.
Например

{} push(s,e) {top(s)=e}
{top(s)=e} push(s,x);pop(s) {top(s)=e}

VD>Я разабрался с тем, что такое классы типов, по крайней мерее в той степени, чтобы понимать что это такое.

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

VD>С++ же, и как я понимаю, Хаскель испльзуют побочные эффекты работы именно ситемы типов.

я же тебе ясно сказал, что система типов используеьтся для своих целей, TH — для своих. последний полностью аналогичен макросам в немерле или любой другой системе и иногда является не самым простым способом что-то реализовать. у тебя же всё как всегда сводится к лозунгам: макросы хорошо (посокльку они есть в немерле), система типов плохо (поскольку есть в C++). неужто ты не понимаешь, что некоторые задачи решаются проще на одном, другие — на другом?

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

G>>Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.

VD>АТД — это практически интерфейс плюс конструктор. Он родился в императивном мире. Состояние в нем не быть не может.

Состояния в нем может не быть.

class Queue
{
public:
  Queue push( Element ) const;

  struct Pair
  {
    Queue queue;
    Element element;
  }

  Pair Queue pop() const;
}

Как нет состояния в этом классе. Как в любом хаскельном АДТ — нет состояния. Как в таких АДТ Эрланга как queue и gb_tree.

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

VD>Да пофигу как это назвать. Главное чтобы было полноценно, удобно и не через зад.

Вот именно.

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

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

VD>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?

Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."

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

VD>Замечательно. Только в Хаскеле классы типов — это фактически вариант интерфейсов. А их воплощения ни что иное как аналог реализации интерфейсов в классаях.
VD>Выходит используется фактически ОО-подход.
VD>Не так ли?

Холиварная тема, но всё-таки выскажусь. Не соглашусь насчёт ОО.
Классам типов Хаскелла можно найти аналогию в ОО-мире, и это действительно будут интерфейсы. Фикус в том, что это действие — поиск аналогии — наш произвол.
Особенность ООП — это полиморфизм времени исполнения. Классы типов же относятся исключительно ко времени компиляции. В этом плане Эрланг с его традицией передавать кортежи с тэгами гораздо более похож на ООЯ, чем Хаскелл.

... << RSDN@Home 1.2.0 alpha rev. 655>>

К>Особенность ООП — это полиморфизм времени исполнения. Классы типов же относятся исключительно ко времени компиляции.

это не так. читай статью Вадлера или объяснения, которые я давал Владу. повторять это в 4-й раз у меня нет желания

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

BZ>>немерле-подобных языках

VD>О. Новая терминалогия. Оказывается Немерле является родоначальником целой плеяды языков.

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

... << RSDN@Home 1.2.0 alpha rev. 655>>

Здравствуйте, <Аноним>, Вы писали:

А>>>видишь ли, полиморфизм не реализуется неким волшебным образом. есть различные механизмы его реализации, которые отражаются в выразительных средствах языка. например, в C++ нет оверлоадинга по возвращаемому типу — это невомзожно в ООП. в хаскеле (и templates, afaik) такое поддерживается

СТ>>Это потому что тип возвращаемого значения в С++ не входит в сигнатуру, и mangled names для функций отличающихся только им будут одинаковы.

А>в сигнатуру он как раз входит, но для выбора реализации метода не используется. и это ограничение возникло не с бухты-барахты, оно является следствием используемой в ООП реализации классов. информация о типе содержится только в самих объектах, поэтому невозможно выбрать между двумя функциями, различающимися только возвращаемым типом. в отличие от этого в реализации type classes информация о типе передаётся отдельным аргументом, поэтому такое ограничение отсутствует. надеюсь в третий (или четвёртый?) раз объяснять одно и то же не придётся?

Думаю, что дело в другом. У С++, как у наследника С, есть развитая система неявного приведения типов. Которая катастрофически усложняет вывод типа от результата к аргументам.

long foo(long);
char foo(char);

int bar(int);

int main()
{
    auto x = 0; // 0 - полиморфный литерал
    int y = bar(/*здесь неявный оператор приведения*/foo(x)); // какое из foo вызвать?
    // возможно, что многими этажами ниже будет ясно, что x - это исключительно long или исключительно char
    // но может быть и так, что x участвует и в других неявных преобразованиях или сложных уравнениях
}

Хиндли-Милнеровские языки разными способами избегают этого:
— запрет неявных приведений
— диагностика неоднозначности с сообщением об ошибке
— ограничение контекста для уравнений (например, зависимость только от предшествующих, но не последующих определений констант)
— использование универсального вариантного типа в случае дефолта

... << RSDN@Home 1.2.0 alpha rev. 655>>

А>>в сигнатуру он как раз входит, но для выбора реализации метода не используется. и это ограничение возникло не с бухты-барахты, оно является следствием используемой в ООП реализации классов. информация о типе содержится только в самих объектах, поэтому невозможно выбрать между двумя функциями, различающимися только возвращаемым типом. в отличие от этого в реализации type classes информация о типе передаётся отдельным аргументом, поэтому такое ограничение отсутствует. надеюсь в третий (или четвёртый?) раз объяснять одно и то же не придётся?

К>Думаю, что дело в другом. У С++, как у наследника С, есть развитая система неявного приведения типов. Которая катастрофически усложняет вывод типа от результата к аргументам.

не в большей степени, чем обратный вывод

что действительно является приницпиальным ограничением, так это передача словаря методов класса (VMT) как части объекта. нет объекта — нет и VMT. в type classes она передаётся отдельно, поэтому можно сделать что-нибудь в духе

class C a where
  nul :: a
instance C Int where
  nul = 0
main = print (nul + length [])

в C++ есть templates, которые ввиду их резолвинга во время компиляции не обладают этим ограничением, и насколько я понимаю, тоже отлично резолвятся в обе стороны

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

К>>Думаю, что дело в другом. У С++, как у наследника С, есть развитая система неявного приведения типов. Которая катастрофически усложняет вывод типа от результата к аргументам.

BZ>не в большей степени, чем обратный вывод

BZ>что действительно является приницпиальным ограничением, так это передача словаря методов класса (VMT) как части объекта. нет объекта — нет и VMT.

В чём препятствие? VMT — это кортеж лямбд (которые можно с самого начала замкнуть на конкретный объект — хоть это и оверхед).
Для нормальной работы нужно, чтобы система типов допускала наследование структур.
Кажется, это не ломает ХМ, потому что обращение к определённому полю VMT означает заведомый up-casting до базовой структуры VMT, содержащей это поле, и в дальнейшем информация о типе VMT уже не нужна.
Как-то я путано сказал — поскольку сам до конца не вкурил.
Если можешь привнести ясность — буду благодарен.

BZ> в type classes она передаётся отдельно, поэтому можно сделать что-нибудь в духе

В type classes передаётся статическая информация о типе, там про VMT можно вообще не задумываться (тем более, про VMT конкретных объектов).

BZ>в C++ есть templates, которые ввиду их резолвинга во время компиляции не обладают этим ограничением, и насколько я понимаю, тоже отлично резолвятся в обе стороны

В плюсовых шаблонах утиная типизация — поэтому они и резолвятся (на уровне шаблонов) отлично, что уравнения типов сводятся ну максимум к проверке арности.

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

D>>Никаких объектов с состояниями (то есть ООП) в классах типов нет.

VD>Ну, состояние конечно же есть. Просто оно не так явно заметно. Иноче свертку массива произвести было бы прсото невозможно.

Откуда взяться состоянию в "чистых" функциях? На которых свертка (fold в частности) реализуется элементарно.

VD>Важно, что мы можем объеявить интерфейс Foldable (не важно будет ли это интерфейс Явы, трэйтс Скалы или класс типов Хаскеля), и реализовать его в/для разных (подчеркиваю, совсем разный) типов (таких как массивы, списки, деревья и т.п.).

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

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

Например, для того, чтобы перестать пытаться заткнуть ОО-средствами императивных языков все дыры.
Кроме того, не думаю, что словосочетание "интерфейс типа данных" было бы удачнее "класс типов данных".

К>Если можешь привнести ясность — буду благодарен.

три раза уже вносил для Влада

ладно. вот смотри. есть функция, печатающая значение, условно говоря, объекта. для этого она вызывает функцию, возвращающую строкове представление этого объекта:

print x = putStrLn (show x)

для осукществления своих коварных планов она должна каким-то образом помимо *данных* x получить и *функцию*, переводящую x в строку. какие здесь есть варианты:

1) в compile time подставить тело print в каждую точку вызова и выбрать нужную реализацию show в каждой точке вызова отдельно. т.е. compile-time polymorphism. он реализуется в C++ механизмом overload и темплейтами, которые готовы в любой момент сгенерировать код для нужной комбинации типов. ты, как я порнимаю, до сих пор полагал, что type classes устроены так же

2) сгенерить один-единственный type-independent code для print, и упаковать таблицу виртуальных функций (VMT) вместе с каждым объектом. это и есть ООП подход. когда print должна вызвать функию show — она лезет в VMT и берёт её адрес оттуда. таким образом, один-единственный откомпилированный экземпляр print может работать с любым объектом, реализующим этот интерфейс

3) также сгенерить один-единственный экземпляр print, но передавать информацию обо всех вызываемых полиморфных функиях в так назыавемом словаре класса — дополнительном невидимом аргументе. т.е. после дешугаринга этот вызов выглядит так:

print show x = putStrLn (show x)

если скажем, передаётся объект класса Number, реализующий 4 действия арифметики, то вызов после дешугаринга выглядит как:

double (+,-,*,/) x = x*2

как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается. с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)

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

BZ>1) в compile time подставить тело print в каждую точку вызова и выбрать нужную реализацию show в каждой точке вызова отдельно. т.е. compile-time polymorphism. он реализуется в C++ механизмом overload и темплейтами, которые готовы в любой момент сгенерировать код для нужной комбинации типов. ты, как я порнимаю, до сих пор полагал, что type classes устроены так же

Ага.

BZ>2) сгенерить один-единственный type-independent code для print, и упаковать таблицу виртуальных функций (VMT) вместе с каждым объектом. это и есть ООП подход. когда print должна вызвать функию show — она лезет в VMT и берёт её адрес оттуда. таким образом, один-единственный откомпилированный экземпляр print может работать с любым объектом, реализующим этот интерфейс

BZ>3) также сгенерить один-единственный экземпляр print, но передавать информацию обо всех вызываемых полиморфных функиях в так назыавемом словаре класса — дополнительном невидимом аргументе. т.е. после дешугаринга этот вызов выглядит так:

Заодно стало понятно, как (правда, ценой косвенных вызовов) можно компилировать и экспортировать обобщённые функции.

Поскольку ещё на стадии вывода типов становится понятно предусловие о классах, ну скажем,

showfac n = show $ fac n
fac 0 = 1
fac n = n * fac (n-1)

:t fac
Num a => a -> a
:t showfac
Num a, Show a => a -> [Char]

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

BZ>как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается.

В ООП print может получить объект не любого типа, а принадлежащего классу Show. Или, говоря по-ООП-шному, поддерживающему этот интерфейс.
Эта информация прекрасно выводится и соответствующим образом обуславливает пользователей функции print. Те, в свою очередь, обуславливают своих пользователей, и так далее.
Ну а конечный пользователь подсунет объект, проходящий через все эти фильтры, причём его методы обязаны возвращать объекты, фактические типы которых принадлежат ожидаемым классам.

BZ> с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)

А вот здесь я снова не понял.
Ясно, что когда VMT идёт отдельно от данных, то полиморфизм делается с велосипедным приводом.
Но когда VMT вместе с данными...
В определении fac всё, что можно сказать про n, n-1, fac(n-1) и их произведение — это то, что их фактические типы должны поддерживать интерфейс Num и начинаться от одной общей базы (поскольку у всех — одинаковый статический тип Num a => a). А как мультиметоды (-) и (*) будут заниматься скрещиванием — компилятору пофиг. Наверное, если пользователь подсунул в fac объект из какой-то вычурной иерархии имени Мичурина и Менделя, то он и мультиметоды смог написать.

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

BZ>как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается. с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)
Бред.

Вывод типов в немерле надо пологать галюцинация?

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

Проблема же состоит в том что разные интерфейсы могут содержать одинаковые функции.
И именно это, а не передача VMT вместе с объектом, мешает выводу типов.
Попробуй вывести типы в этом примере:

interface Foo1
{
    Foo(i : int) : int;
}
interface Foo2
{
    Foo(i : int) : int;
}
...
def Bar(foo)
{
    foo.Foo(1);
}

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

interface Foo1
{
    Foo(i : int) : int;
}
...
def Bar(foo)
{
    foo.Foo(1);
}

Также затрудняют вывод всякие перегрузки и неявные привидения типов.

И если мне не изменяет скалероз то в хаскеле запрещено создавать одинаковые функции в разных классах типов те мы имеем второй вариант, а в немерле у нас первый вариант те вывод типов ограничен тем не мение немерле весьма не плохо выводит типы.

А словарь методов передается отдельно по тому что в хаскеле можно реализовать класс типа для конкретного типа в любой момент, а не как в распространенных ОО языках только при объявлении типа.
Те в хаскеле банально трудно создать классическую VMT.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

BZ>>как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается. с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)

WH>Бред.

Вывод типов в немерле надо пологать галюцинация?

Судя по тому, что написано здесь, вывод типов в Nemerle и HM type inference — весьма разные вещи. В Nemerle вывод направлен на поиск конкретного частного типа, удовлетворяющего всем ограничениям на тип. В HM type inference, наоборот, ищется наиболее общий тип, удовлетворяющий всем ограничениям.

WH>Бред.

Вывод типов в немерле надо пологать галюцинация?

ты бы прежде чем высасывать чушь из пальца, поинтересовался хоть ограничениями type inference в немерле

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

D>Судя по тому, что написано здесь, вывод типов в Nemerle и HM type inference — весьма разные вещи. В Nemerle вывод направлен на поиск конкретного частного типа, удовлетворяющего всем ограничениям на тип. В HM type inference, наоборот, ищется наиболее общий тип, удовлетворяющий всем ограничениям.
Я вобщемто объяснил что препятствует выводу общих типов.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

BZ>ты бы прежде чем высасывать чушь из пальца, поинтересовался хоть ограничениями type inference в немерле
Я о них знаю лучше тебя.
А еще я в отличии от тебя знаю почему так происходит.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

BZ>>ты бы прежде чем высасывать чушь из пальца, поинтересовался хоть ограничениями type inference в немерле
WH>Я о них знаю лучше тебя.
WH>А еще я в отличии от тебя знаю почему так происходит.

молоджец, теперь возьми с полки пирожок и перестань рассуждать о том, чего не знаешь

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

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

D>>Судя по тому, что написано здесь, вывод типов в Nemerle и HM type inference — весьма разные вещи. В Nemerle вывод направлен на поиск конкретного частного типа, удовлетворяющего всем ограничениям на тип. В HM type inference, наоборот, ищется наиболее общий тип, удовлетворяющий всем ограничениям.
WH>Я вобщемто объяснил что препятствует выводу общих типов.
Описанная тобой проблема легко решается квалифицированными именами.

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

BZ>молоджец, теперь возьми с полки пирожок и перестань рассуждать о том, чего не знаешь

Это ты перестань говорить о том что не понимаешь. Ибо это ты утверждаешь что VMT внутри класса мешает выводу типов

Что мешает я написал.
Если не понятно ты скажи. Я еще раз объясню.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>>Я вобщемто объяснил что препятствует выводу общих типов.
D>Описанная тобой проблема легко решается квалифицированными именами.
Те фактически явным указанием типа.

... << RSDN@Home 1.2.0 alpha rev. 673>>

BZ>>молоджец, теперь возьми с полки пирожок и перестань рассуждать о том, чего не знаешь

WH>Это ты перестань говорить о том что не понимаешь. Ибо это ты утверждаешь что VMT внутри класса мешает выводу типов

WH>Что мешает я написал.
WH>Если не понятно ты скажи. Я еще раз объясню.

ты ошибся. доступно излагаю? попытайся сначала разобраться как делается type inference прежде чем пытаться о нём рассуждать

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

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

WH>>>Я вобщемто объяснил что препятствует выводу общих типов.
D>>Описанная тобой проблема легко решается квалифицированными именами.
WH>Те фактически явным указанием типа.

Неа, модуля. Это конфликт библиотек, а не типов.

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

BZ>ты ошибся. доступно излагаю? попытайся сначала разобраться как делается type inference прежде чем пытаться о нём рассуждать
Если ты все понимаешь то тебе не составит труда объяснить что препятствует выводу типов в случае если в двух интерфейсах нельзя описать метод с одинаковой сигнатурой.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

WH>>>>Я вобщемто объяснил что препятствует выводу общих типов.
D>>>Описанная тобой проблема легко решается квалифицированными именами.
WH>>Те фактически явным указанием типа.

D>Неа, модуля. Это конфликт библиотек, а не типов.

Но ведь в модуле нельзя в двух разных классах типов описать функции с одинаковыми сигнатурами.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

WH>>>>>Я вобщемто объяснил что препятствует выводу общих типов.
D>>>>Описанная тобой проблема легко решается квалифицированными именами.
WH>>>Те фактически явным указанием типа.

D>>Неа, модуля. Это конфликт библиотек, а не типов.

WH>Но ведь в модуле нельзя в двух разных классах типов описать функции с одинаковыми сигнатурами.

С одинаковыми названиями? Нельзя. А зачем в модуле разные функции называть одинаково?

Тут фишка в том, что объект в ООП "стягивает" на себя все свои интерфейсы. Он о них должен знать на этапе компиляции. А в Хаскелле не так. Int ни фига не знает, что он Typeable. И пока нам не пришло в голову воспользоваться для него

cast :: (Typeable a, Typeable b) => a -> Maybe b

подключив модуль Data.Typeable, то это знание ни самому Int, ни функциям, этот Int использующим, ни на фиг не упало.

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

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

BZ>>ты ошибся. доступно излагаю? попытайся сначала разобраться как делается type inference прежде чем пытаться о нём рассуждать
WH>Если ты все понимаешь то тебе не составит труда объяснить что препятствует выводу типов в случае если в двух интерфейсах нельзя описать метод с одинаковой сигнатурой.

проблема в том, что вы вообще не с той стороны пляшете. синтаксис второстепенен, главное — какие возможности предлагает семантика, "объектная модель". я это несколько рахз объянял Владу, затем Сергую, наконец Кодту. очему бы тебе не прочитать внимательней? и тогда станет ясно, что дело не в синтаксисе, а в том, что во время выполнения просто не сущетсвует информации, необходимой для реализации функции, аналогичной моему nul. а все синтаксические возможности немерле или любого другого ООП языка — это всего лишь средство, предоставляющее доступ ровно к тем влзможностям, которые даёт данная объектная модель. семантика — первична, синтаксис — вторичен

К>Заодно стало понятно, как (правда, ценой косвенных вызовов) можно компилировать и экспортировать обобщённые функции.

да, именно так

type classes в этом отношении полностью соотвествуют ОО classes, а никак не templates. хотя на практике их можно заинлайнить прагмой, так что в нынешнем GHC есть и поддержка аналога компилированных темплейтов. с одной стороны получается удобно, что один и тот же синтаксис и на compile-time, и на run-time полиморфизм (в отличие от С++), с другой стороны, директива — это не какое-то строгое обязательство, и когда компилятор из-за своих ограничений отказывается что-либо инлайнить... у меня как-то скорость программы упала в 200 раз из-за одной пропцщенной директивы

К>Поскольку ещё на стадии вывода типов становится понятно предусловие о классах, ну скажем,

да, всё именно так — требования к классам входят в тип (поскольку словари каждого класса придётся передать отдельным аргументом) и выводятся из требований использованных операций — всё это рекурсивно вплоть до операций, непосредственно объявленных в классах

BZ>>как видишь, все функции класса просто идут в этом неявном аргументе. вот и всё. у этого подхода свои преимущества и недостатки, но главное для FP — что он в отличие от OO classes совместим с HM type inference. поскольку в OOP print может получить объект любого типа — всё определяется в run-time, и весь type inference на этом кончается.

К>В ООП print может получить объект не любого типа, а принадлежащего классу Show. Или, говоря по-ООП-шному, поддерживающему этот интерфейс.
К>Эта информация прекрасно выводится и соответствующим образом обуславливает пользователей функции print. Те, в свою очередь, обуславливают своих пользователей, и так далее.
К>Ну а конечный пользователь подсунет объект, проходящий через все эти фильтры, причём его методы обязаны возвращать объекты, фактические типы которых принадлежат ожидаемым классам.

ладно, это сработает, но для практического применения HM type inference прицнипиально важно, что он работает в обе стороны. поэтому информация о типах должна быть вынесена в compile-time. динамичсекая типизация, допускаемая в ООП, является здесь непозволительной роскошью:

[ccode]
Figure *create()
{
switch (getch()) {
case 'a': return new Triangle;
case 'b': return new Circle;
}
}
[/code]

поэтому и появилась объектная модель, делающая такую роскошт невозможной

BZ>> с type classes же такой проблемы не возникает. зато, с другой стороны, нельзя например делать полиморфные коллекции без дополнительных ухищрений (фактически эмулирующих VMT)

К>А вот здесь я снова не понял.

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

реализация этого требует так называемых existentials, которые включают VMT класса вместе с каждым объектом:

diplayAll1 :: Figure a =>   [a] -> IO ()
diplayAll2 :: [exist a . Figure a => a] -> IO ()

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

type figure a  =  a -> IO ()
diplayAll1 :: figure a -> [a] -> IO ()
diplayAll2 :: [exist a . (figure a, a)] -> IO ()

"figure a" здесь — тип словаря для класса Figure, cостоящий в данном случае из одной-единственной функции. ну а квантор exists даёт возможность разным элементам списка иметь разные типы, в отличие от первой функции

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

D>С одинаковыми названиями? Нельзя.
Именно это ограничение и позволяет выводить типы на право и на лево.
Тк нет функций с одинаковыми именами то встречая функцию с определенным именем мы точно знаем какой класс типа взять.
А еслибы этого ограничения небыло то привет...
Хотя тут можно генерить перегрузки на каждый интерфейс.
Те из такого

interface Foo1
{
    Foo(i : int) : int;
}
interface Foo2
{
    Foo(i : int) : int;
}
...
def Bar(foo)
{
    foo.Foo(1);
}

получаем такое

interface Foo1
{
    Foo(i : int) : int;
}
interface Foo2
{
    Foo(i : int) : int;
}
...
def Bar(foo : Foo1) : int
{
    foo.Foo(1);
}

def Bar(foo : Foo2) : int
{
    foo.Foo(1);
}

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

D>А зачем в модуле разные функции называть одинаково?
Это уже другой вопрос.

D>Тут фишка в том, что объект в ООП "стягивает" на себя все свои интерфейсы. Он о них должен знать на этапе компиляции. А в Хаскелле не так. Int ни фига не знает, что он Typeable. И пока нам не пришло в голову воспользоваться для него
D>

D>cast :: (Typeable a, Typeable b) => a -> Maybe b
D>

D>подключив модуль Data.Typeable, то это знание ни самому Int, ни функциям, этот Int использующим, ни на фиг не упало.
Это я понимаю.
Я не понимаю как "стягивание" интерфейсов на себя мешает выводу типов.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

BZ> семантика — первична, синтаксис — вторичен

Предлагаю перейти с Хаскелла на Лискелл!
Семантика хаскелловская, синтаксис... Синтаксис вторичен! :о))

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

D>>Тут фишка в том, что объект в ООП "стягивает" на себя все свои интерфейсы. Он о них должен знать на этапе компиляции. А в Хаскелле не так. Int ни фига не знает, что он Typeable. И пока нам не пришло в голову воспользоваться для него
D>>

D>>cast :: (Typeable a, Typeable b) => a -> Maybe b
D>>

D>>подключив модуль Data.Typeable, то это знание ни самому Int, ни функциям, этот Int использующим, ни на фиг не упало.
WH>Это я понимаю.
WH>Я не понимаю как "стягивание" интерфейсов на себя мешает выводу типов.

Во-первых.

class Stack s e where
push :: s -> e -> s
pop  :: s -> s
top  :: s -> e

На какой объект в рантайме будет "стягиваться" этот обобщенный интерфейс? На конкретную реализацию контейнера s или на конкретную реализацию элемента e?

Во-вторых.
Ещё раз повторяю, что алгоритм вывода HM ищет наиболее общий (principle) тип, то есть подходящий для выражения тип максимально обобщённого характера. Причём это касается не только выражений зацепляющих "интерфейсы", но и выражений без ограничений. Тип оператора композиции

(.) f g x = f( g x)

таков

(.) :: (b -> c) -> (a -> b) -> a -> c

Всё, вывод типа для выражения успешно завершён, principle type найден.

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

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

BZ>ты бы прежде чем высасывать чушь из пальца, поинтересовался хоть ограничениями type inference в немерле

Предлагаю, и очень настоятельно, прекратить вещание в таком тоне.

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

G>Предлагаю перейти с Хаскелла на Лискелл!
G>Семантика хаскелловская, синтаксис... Синтаксис вторичен! :о))

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

Lisp:
(foo x y z) == foo . (quote x y z)

Haskell:
foo x y z   == ((foo $ x) $ y) $ z
foo (x,y,z) == foo $ (x,y,z)

где лисповский конструктор конс-пары . является заодно и аппликацией (т.е. хаскелловским оператором $).

Чтобы сделать карринг на лиспе, нужно перевернуть список с ног на голову (сделать так называемый снок-список)

((((foo . x) . y) . z)

Конечно, синтаксис вторичен, но не до такой же степени!

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

G>>Предлагаю перейти с Хаскелла на Лискелл!
G>>Семантика хаскелловская, синтаксис... Синтаксис вторичен! :о))

К>Не выйдет.
К>В Хаскелле и Лиспе разное строение синтаксических деревьев, что оказывает влияние на семантику.

Ну вапще-то автор Лискелла утверждает, что Лискелл — это именно хаскеллевская семантика с лисповским синтаксисом.
Даже компилятор Лискелла основан на GHC 5.04...

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

G>Ну вапще-то автор Лискелла утверждает, что Лискелл — это именно хаскеллевская семантика с лисповским синтаксисом.
G>Даже компилятор Лискелла основан на GHC 5.04...

А... я думал, ты прикалываешься. Ан нет, действительно, http://liskell.org, http://clemens.endorphin.org/ILC07-Liskell-draft.pdf

Хотя, конечно, заодно приобретаем все прелести lots of silly idiotic paretheses...

... << RSDN@Home 1.2.0 alpha rev. 655>>

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

BZ>полиморфные коллекции — это соджержащие объекты разных типов, реализующих общий интерфейс. пусть скажем, это фигуры, которые можно рисовать на экране — треугольники, овалы и т.д. если каждый объект включает свою собственную VMT, то из неё вы узнаёте, как нарисовать это конкретный объект. если же вы перелаёте одну VMT на всё-про всё, то нифига хорошего не выйдет

реализация этого требует так называемых existentials, которые включают VMT класса вместе с каждым объектом:

BZ>

BZ>diplayAll1 :: Figure a =>   [a] -> IO ()
BZ>diplayAll2 :: [exist a . Figure a => a] -> IO ()
BZ>

Разве в GHC есть exist? Я думал он через forall делается. Если есть — где почитать?

Насчёт forall — тут уже не будет так однозначно, т.к. тип

[forall a. Figure a => a]

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

data Shape = forall a. Figure a => Shape a
displayAll :: [Shape] -> IO ()
displayAll = mapM_ display

уже сработает.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?

D>Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."

Это не вопрос. Это подлог. Потому как исходно речь шла об ООП. В ООП такие средства несомненно есть. В ФП,как мы выяснили, нет.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

VD>>>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?

D>>Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."

VD>Это не вопрос. Это подлог. Потому как исходно речь шла об ООП. В ООП такие средства несомненно есть. В ФП,как мы выяснили, нет.

Мы? Никола... Ой! VladD2?

Может это обобщенное программирование? здесь

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

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

VD>>>С Хаскелем у меня вопросов нет. У меня вопрос в том может ли сама парадигма ФП предоставить что-то для решения этой проблемы? Или все она нуждается в расширении некой идеологией сходной с иделогией ОО-интерфейсов или классов типов Хаскеля?

D>>Вопрос аналогичен следующему: "может ли сама парадигма императивного программирования предоставить что-то для решения этой проблемы?". Ответ на оба вопроса: "Нет, не может. Задача, неформулируемая в терминах парадигмы не может быть решена исключительно средствами парадигмы."

VD>Это не вопрос. Это подлог.

Какой подлог? false analogy? это не она

Был приведен вопрос, аналогичный обсуждаемому. Ответ был дан на оба вопроса, независимо.

VD>Потому как исходно речь шла об ООП. В ООП такие средства несомненно есть. В ФП,как мы выяснили, нет.

Исходно речь шла о решении проблемы, сформулированной в терминах ООП. Соответственно, можно сказать, что в ФП и проблемы-то такой нет.

Часто вижу, как ярые защитники императивных языков неверно истолковывают слова восторженных функциональщиков о бесполезности ООП. Часто имеется в виду очевидная вещь: в ФП отсутствуют многие проблемы императивного мира, в частности, решаемые средствами ООП (в тех ИЯ, где они есть). Т.е. на достаточно крупной задаче обнаружится наверное необходимость OOD и OO-средств, но этот момент наступит значительно позже, чем в императивном мире при прочих равных условиях. Например, решаемая задача в реальных условиях разработки на ФЯ попросту не возникнет, imo.

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

D>Откуда взяться состоянию в "чистых" функциях? На которых свертка (fold в частности) реализуется элементарно.

Подумай.

VD>>Важно, что мы можем объеявить интерфейс Foldable (не важно будет ли это интерфейс Явы, трэйтс Скалы или класс типов Хаскеля), и реализовать его в/для разных (подчеркиваю, совсем разный) типов (таких как массивы, списки, деревья и т.п.).

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

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

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

Алё! Гараж? Я вообще-то говорил о выборе устоявшихся терминов. Другими словами, о том, что не стоит придумывать уникальную терминалогию без необходимости.

D>Кроме того, не думаю, что словосочетание "интерфейс типа данных" было бы удачнее "класс типов данных".

А зачем "интерфейс типа данных" просто "интерфейс" было бы достаточно. Просто особенность Хаскеля заключается в том, что интерфес может быть реализован и для уже существующего типа данных, в том время как в классических ЯП они обычно реализуются в самом описании типа данных. Это несомненно очень удобная особенность, но сути дела она все же не меняет.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

D>Исходно речь шла о решении проблемы, сформулированной в терминах ООП. Соответственно, можно сказать, что в ФП и проблемы-то такой нет.

Проблема есть. Ести кто-то ее не хочет замечать, то это его проблемы.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

BZ>у тебя же всё как всегда сводится к лозунгам: макросы хорошо (посокльку они есть в немерле), система типов плохо (поскольку есть в C++).

Примеры подобных высказываний с моей стороны в студию. До тех пор будем считать это вымыслом.

BZ>неужто ты не понимаешь, что некоторые задачи решаются проще на одном, другие — на другом?

Я заню только две задачи которые на С++ диелаются лучше всего:
1. Писать С++-код.
2. Делать ошибки.

Если этих задач не стоит, то всгеда можно найти лучший инструмент.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

К>>Особенность ООП — это полиморфизм времени исполнения. Классы типов же относятся исключительно ко времени компиляции.

BZ>это не так. читай статью Вадлера или объяснения, которые я давал Владу. повторять это в 4-й раз у меня нет желания

Лучше давать сыылку...

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

D>>Откуда взяться состоянию в "чистых" функциях? На которых свертка (fold в частности) реализуется элементарно.

VD>Подумай.

Э... Просветишь? На всякий случай напомню, что чистыми называются функции, результат вычисления которых зависит исключительно от значений ее параметров.

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

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

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

VD>Алё! Гараж? Я вообще-то говорил о выборе устоявшихся терминов. Другими словами, о том, что не стоит придумывать уникальную терминалогию без необходимости.

Согласен, но в данном случае, необходимость очевидна, по меньшей мере, тем, кто потрудился выяснить суть обсуждаемого термина. Я думаю, этому (выяснению) может мешать костность мышления, часто преодолеваемая при помощи шоковой терапии.

Кстати, использование терминов class и instance в Haskell я тоже не считаю удачным решением, в силу той же перегруженности терминов.

D>>Кроме того, не думаю, что словосочетание "интерфейс типа данных" было бы удачнее "класс типов данных".

VD>А зачем "интерфейс типа данных" просто "интерфейс" было бы достаточно.

'Просто "интерфейс"' — термин очень перегруженный.

VD>Просто особенность Хаскеля заключается в том, что интерфес может быть реализован и для уже существующего типа данных, в том время как в классических ЯП они обычно реализуются в самом описании типа данных. Это несомненно очень удобная особенность, но сути дела она все же не меняет.

В целом, мысль понятна. Однако, классы типов в Haskell допускают default-рализацию, в том числе частичную, что, согласись, также не свойственно интерфейсам в обсуждаемом смысле, ближе к абстрактным классам в ОО.

От:	VladD2	www.nemerle.org
Дата:	31.05.07 22:19
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	31.05.07 23:31
Оценка:	+1

От:	VladD2	www.nemerle.org
Дата:	01.06.07 00:07
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	01.06.07 04:23
Оценка:

	От:	deniok
	Дата:	01.06.07 04:30
	Оценка:	+1

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	01.06.07 05:21
Оценка:	42 (3) +1

От:	Gaperton	http://gaperton.livejournal.com
Дата:	01.06.07 09:03
Оценка:

От:	konsoletyper	https://github.com/konsoletyper
Дата:	01.06.07 14:07
Оценка:

От:	Курилка	http://kirya.narod.ru/
Дата:	01.06.07 14:16
Оценка:

	От:	Аноним
	Дата:	02.06.07 12:23
	Оценка:	+2 -2

От:	Сергей Туленцев	http://software.tulentsev.com
Дата:	02.06.07 14:15
Оценка:

От:	geniepro	http://geniepro.livejournal.com/
Дата:	02.06.07 16:50
Оценка:

	От:	BulatZiganshin
	Дата:	02.06.07 20:43
	Оценка:	10 (1)

	От:	Константин Л.
	Дата:	04.06.07 10:26
	Оценка:

От:	dr.Chaos	Украшения HandMade
Дата:	04.06.07 12:05
Оценка:	+1