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

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

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

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

ЗЫ

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

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

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

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

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

ЗЫ

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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 написанный для списка будет падать на массивх.

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

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++.

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: deniok
Дата: 05.01.07

.

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