Здравствуйте, Аноним, Вы писали:
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>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
BZ>>это работает очень эффективно (gc потом насчитывает гигабайты выделенных и освобождённых данных),
имеется в виду — в секунду. на простейших хвострекурсивных функциях
WH>Не знаю как в жабе но в .NET 3 поколения. WH>0 — для короткоживущих WH>1 — для тех кто случайно пережил сборку нулевого WH>2 — для долгоживущих
в ghc регулируется от 1 до бесконечности, по умолчанию 2
Здравствуйте, lomeo, Вы писали:
L>Но это уже философия. Я что сказать хочу — исходя из задачи и решение будет. Ведь вопрос был именно о перегрузке? Есть ли перегрузка в ФП? Есть. Из-за того, что она есть также и в ОО это не делает ее ОО решением.
Насколько я понимаю полиморфизм, как таковой, нужен исключительно для обобщенного программирования. Эта парадигма (техника?) программирования ИМХО ортогональна обоим подходам, т.е. в чистом виде не относиться ни туда ни туда. А служит для разделения алгоритма и поведения конкретного типа/класса. А реализации в ООЯ и ФЯ отличаются соответственно парадигме — есть состояние/нет состояния.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Gaperton, Вы писали:
G>Разница довольно тонка и кажется незначительной, однако на одном ADT без состояния (все методы const) нельзя сделать объектную декомпозицию. Вы не сможете представить систему как состоящую из набора объектов, каждый из которых живет своей жизнью. Первая же кольцевая или обратная ссылка вам испортит все.
С ленивостью можно и кольцевую и обратную. Так что дело не в них, дело, насколько я понимаю, именно в изменении состояния.
Здравствуйте, lomeo, Вы писали:
G>>Разница довольно тонка и кажется незначительной, однако на одном ADT без состояния (все методы const) нельзя сделать объектную декомпозицию. Вы не сможете представить систему как состоящую из набора объектов, каждый из которых живет своей жизнью. Первая же кольцевая или обратная ссылка вам испортит все.
L>С ленивостью можно и кольцевую и обратную. Так что дело не в них, дело, насколько я понимаю, именно в изменении состояния.
Дело в состоянии и идентити. А кольцевые ссылки — пример, на которм это хорошо видно. Дело в том, что эти кольцевые ссылки разъедутся, когда ты попытаешься выполнить "функциональный апдейт", откопировав объект и изменив ему состояние (ссылки будут указывать на старые, не измененные объекты). А они разъезжаться не должны. Таким образом, ты не сможешь отмоделировать время в этой связанной кольцевыми ссылками системе. Эта тема очень хорошо покрыта в курсе SICP. Монадные фокусы, посредством которых это все-таки можно изобразить в Хаскеле, по сути — не чисты и не ФП.
Здравствуйте, dr.Chaos, Вы писали:
L>>Но это уже философия. Я что сказать хочу — исходя из задачи и решение будет. Ведь вопрос был именно о перегрузке? Есть ли перегрузка в ФП? Есть. Из-за того, что она есть также и в ОО это не делает ее ОО решением.
DC>Насколько я понимаю полиморфизм, как таковой, нужен исключительно для обобщенного программирования. Эта парадигма (техника?) программирования ИМХО ортогональна обоим подходам, т.е. в чистом виде не относиться ни туда ни туда. А служит для разделения алгоритма и поведения конкретного типа/класса.
Согласен. Но я и не говорил, что ООП — это фактически классы типов
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, dr.Chaos, Вы писали:
L>>>Но это уже философия. Я что сказать хочу — исходя из задачи и решение будет. Ведь вопрос был именно о перегрузке? Есть ли перегрузка в ФП? Есть. Из-за того, что она есть также и в ОО это не делает ее ОО решением.
DC>>Насколько я понимаю полиморфизм, как таковой, нужен исключительно для обобщенного программирования. Эта парадигма (техника?) программирования ИМХО ортогональна обоим подходам, т.е. в чистом виде не относиться ни туда ни туда. А служит для разделения алгоритма и поведения конкретного типа/класса.
L>Согласен. Но я и не говорил, что ООП — это фактически классы типов
Я, собственно, дополнил .
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
VladD2 wrote:
> L>Реального списка может и не быть в бинарнике, код которого весь в этих > списках. > Это очень теоритически. В прочем, это уже другая тема.
Если вспомнить бесконечные списки в хаскеле, то они по твоей теории не могут существовать.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gaperton, Вы писали:
L>>С ленивостью можно и кольцевую и обратную. Так что дело не в них, дело, насколько я понимаю, именно в изменении состояния.
G>Дело в состоянии и идентити. А кольцевые ссылки — пример, на которм это хорошо видно. Дело в том, что эти кольцевые ссылки разъедутся, когда ты попытаешься выполнить "функциональный апдейт", откопировав объект и изменив ему состояние (ссылки будут указывать на старые, не измененные объекты). А они разъезжаться не должны.
Здравствуйте, lomeo, Вы писали:
L>Неважно не то, что полиморфизм полиморфизму рознь, а то, что ты об этом говоришь — я указал, какой полиморфизм я рассматриваю.
Я не понимаю как это может быть не важно.
L>Кстати, даже на уровне выражений вывести тип не всегда возможно из-за нестрогости типизации (в частности, неявного приведения).
Все зависит от алгоритма. Немерловому алгоритму приведения типо не мешают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
LCR>>ps: Хуже троля может быть только троль с банилкой.
VD>Не надо пытаться приклеить ярлык к тому с кем не согласен, даже если не можешь возразить по существу.
тебе же сказали по существу — прочти статью Вадлера, разберись с тем, что такое type classes
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gaperton, Вы писали:
G>>Инкапсуляция не присутствует в полном объеме. Присутствует ADT. А это не одно и то же.
VD>Абстрактный тип данных полностью удовлетваряет принципу инкапсуляции.
Абстактный тип данных неполностью удовлетворяет принципу инкапсуляции. АДТ не обязан иметь состояние и идентити. Без них — нет объектов и нет никакого ООП.
ОО отдыхает.
.
