D>Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style
Здравствуйте, BulatZiganshin, Вы писали:
D>>Классы типов находятся в рамках "чисто функциональной парадигмы". Они однозначно и автоматически транслируются в стандартную функциональщину с помощью dictionary-passing style
D>Правильно! А Булат является тем самым Анонимом, и все давно об этом догадались. :Ь
типа на свет выманили? :D я просто решил выяснить запоминания скольких вещей я счатливо избёг, создавая многопотчные программы на хаскеле, а не немерле-подобных языках
Здравствуйте, 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Нет. Конечно. Ни один применяемый в ООЯ элемент сам по себе не является ООП-ом. Но мы же понимаем, что именно в ООП родилась и развилась идея абстрактных интерфейсов?
сколько раз тебе повторять — эта идея появилась в языках с АТД. уж хотя бы про аду ты должен был слышать. это тоже ооп язык? до ады в 70-х появилась куча атд-языков. в 80-х эти идеи были привнесены в классичекий ООП (подразумевавший только наследование) и появились языки, совмещающие и то, и другое. понятное дело, что с точки зрения современных недорослей, не знающих мезу и клу, АТД являются фичей впервые появившейся в c++
Здравствуйте, 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>А о производительности вообще говорить не приходится.
Когда как. Реального списка может и не быть в бинарнике, код которого весь в этих списках.
Здравствуйте, 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). В ООП такое, насколько я понимаю, невозможно.
Хотя это всего лишь оптимизация компилятора, ну да ладно. Неизменяемые переменные? Хорашая идея. Тоже берем, при условии, что это не единственный способ работы. 
