Вот возник вопрос:
в ФЯ есть полиморфизм типов, что имхо есть очень близко к шаблонам C++. Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ?
Заранее сенкс за любую инфу!
22.10.04 22:49: Перенесено модератором из 'Философия программирования' — AndrewVK
Здравствуйте, Курилка, Вы писали:
К>Вот возник вопрос: К>в ФЯ есть полиморфизм типов, что имхо есть очень близко к шаблонам C++. Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ? К>Заранее сенкс за любую инфу!
Трудно найти людей, которые одновременно в курсе реализации полиморфизма типов в ФЯ и в еще не существующих языках
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Здравствуйте, Курилка, Вы писали:
К>>Вот возник вопрос: К>>в ФЯ есть полиморфизм типов, что имхо есть очень близко к шаблонам C++. Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ? К>>Заранее сенкс за любую инфу!
INT>Трудно найти людей, которые одновременно в курсе реализации полиморфизма типов в ФЯ и в еще не существующих языках
Я думаю, что множества скорее всего почти совпадают, но мощность у них очень мала
З.Ы. Интересно — кто-нибудь видел всуе живого теоретика/практика ФП? (в смысле близкого к разработке ФЯ)
Здравствуйте, Курилка, Вы писали:
К>Вот возник вопрос: К>в ФЯ есть полиморфизм типов, что имхо есть очень близко к шаблонам C++. Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ? К>Заранее сенкс за любую инфу!
В смысле статический или динамический?
Думаю, оба варианта. Тот же патер-матчинг — это по сути динамический полиморфизм. Ведь вариант функции для пустого списка может быть подобран только в рантайме. С другой стороны работать с известными типами можно и статически (если они известны во время компиляции).
И вообще, если подумать по лучше, то вопрос необходиомсти "динамичности" в полиморфизме — это вопрос достаточноности информации. Если инфомрации достаточно еще при компиляции, то можно спокойно принять решение и жетсно закодировать алгоритм.
Если же информация доступна при компиляции не вся, и полный ее объем становится доступен программе только на этапе выполнения, то без динамических проверок не обойтись, а стало быть статического полиморфизма недостаточно.
Кстати, забавно, что очень часто динамический полиморфизм применяется исключительно для увучшения модульности приложения. Так КОМ не мыслим без виртуальных вызовов. А тот же АТЛ использу применяет забавные методы эмуляции полиморфизма на базе шаблонов.
И еще забавно, что среды вроде дотнета (обладающие средствами JIT-компиляции) потенциально способны превращать динамический полиморфизм в статический. Ведь на самом деле ложки (тфу-ты, компонентов) на самом деле не существует. Реальное приложение монолитно. Оно загружает все модули превращая их в один исполняемый файл. И в момент когда становятся извесны все входящие в приложение модули (это может быть момент когда все они загружены в процесс или даже момент инсталляции приложения на машину клиента) теоритически нет препятствий для преобразования динамического полиморфизма в статический.
В общем, думаю что через несколько лет (возможно десятков) у разработчиков компиляторов/рантаймов и т.п. руки дойдут и до этого. Тогда вопрос статичности или динамичности полиморфизма станет таким же важным как сейчас вопросы автоматического инлайнинга методов, т.е. будут интересовать только разработчиков компиляторов.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, INTP_mihoshi, Вы писали:
INT>Трудно найти людей, которые одновременно в курсе реализации полиморфизма типов в ФЯ и в еще не существующих языках
Ложки нет (с)
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Курилка, Вы писали:
К>Я думаю, что множества скорее всего почти совпадают, но мощность у них очень мала К>З.Ы. Интересно — кто-нибудь видел всуе живого теоретика/практика ФП? (в смысле близкого к разработке ФЯ)
Ява 1.5, кстати, вышла. А бэты дотнета более чем достаточно для изучения.
... << RSDN@Home 1.1.4 beta 3 rev. 206>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>И еще забавно, что среды вроде дотнета (обладающие средствами JIT-компиляции) потенциально способны превращать динамический полиморфизм в статический. Ведь на самом деле ложки (тфу-ты, компонентов) на самом деле не существует. Реальное приложение монолитно. Оно загружает все модули превращая их в один исполняемый файл. И в момент когда становятся извесны все входящие в приложение модули (это может быть момент когда все они загружены в процесс или даже момент инсталляции приложения на машину клиента) теоритически нет препятствий для преобразования динамического полиморфизма в статический.
В общем случае не получится. Потому как существует внешняя среда (включая пользователя), которая часто владеет львиной долей информации, необходимой для превращения динамического метода в статический.
Здравствуйте, Курилка, Вы писали:
К>Вот возник вопрос: К>в ФЯ есть полиморфизм типов, что имхо есть очень близко к шаблонам C++. Наряду с шаблонами C++ есть generics Java и C#, но там используются несколько иные механизмы. Так вот — какой из подходов будет ближе к тому, как это работает в ФЯ? К>Заранее сенкс за любую инфу!
На самом деле, полиморфные функции в ФЯ достаточно далеки от шаблонов. Шаблоны — это, скорее, примитивный аналог макросов из Лиспа (идея та же). Примитивный в том смысле, что Лисп позволяет делать более мощные модификации программы на основе параметров макроса. Полиморфные функции существуют в единственном экземпляре для любых подходящих для них типов, в то время как в случае шаблонов для каждого типа генерируется своя функция.
Здравствуйте, Quintanar, Вы писали:
Q>На самом деле, полиморфные функции в ФЯ достаточно далеки от шаблонов. Шаблоны — это, скорее, примитивный аналог макросов из Лиспа (идея та же). Примитивный в том смысле, что Лисп позволяет делать более мощные модификации программы на основе параметров макроса. Полиморфные функции существуют в единственном экземпляре для любых подходящих для них типов, в то время как в случае шаблонов для каждого типа генерируется своя функция.
Думаю, ты ошибашся. И в ФЯ при статическом полиморфизме генерируются тучи воплощений. (тому примером являются декомпилированные исходники того же SML.NET). И макросмаи конечно шаблоны не являются, так как проходят синтаксическую проврку. И примитивными они не являются, так как на ним очень многое можно сделать.
В общем, ненадо недооценивать технологии которые не нравятся. И переоценивать те, которые нравятся.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, prVovik, Вы писали:
V>В общем случае не получится.
Еще как, получится. Единственное что может помещать — это динамическое изменение ссылок на объект. Но и это в принципе решается. Хотя и сложнее.
V> Потому как существует внешняя среда (включая пользователя), которая часто владеет львиной долей информации, необходимой для превращения динамического метода в статический.
Какя на фиг внешная среда? И что может сделать пользователь? После того как все модули загружены в процесс никакая внешняя среда никого уже не волнует. При подгрузке новых модулей можно проводить пересборку критический участков кода.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Какя на фиг внешная среда? И что может сделать пользователь? После того как все модули загружены в процесс никакая внешняя среда никого уже не волнует. При подгрузке новых модулей можно проводить пересборку критический участков кода.
Динамический полиформизм используется далеко не только для связи компонент. Это скорее факультативная функция. В общем случае, динамический полиформизм в ООП используется в случаях, когда тип объекта невозможно определить на этапе компиляции. Я уже приводил классический пример графического редактора, где используется полиморфная коллекция графических примитивов. Как этот пример можно привести к статическому виду? Предлагаешь на этапе компиляции сгенерировать пару миллиардов всевозможных вариантов этой коллекции (которая в данном случае станет уже кортежем) и выбирать во время работы нужную в зависимости от желания пользователя?
Здравствуйте, VladD2, Вы писали:
VD>В общем, похоже дальнейшие объяснения бесполезны. По крайней мере я ретируюсь.
Влад, ты не похож сам на себя
Из товего исходного сообщения я сделал вполне логичный вывод, что ты считаешь, что единственным препятствием для преобразования динамического полифорымизма к статическому являеются динамически загружаемые компоненты. Как еще иначе можно интерпретировать твою фразу:
И в момент когда становятся извесны все входящие в приложение модули (это может быть момент когда все они загружены в процесс или даже момент инсталляции приложения на машину клиента) теоритически нет препятствий для преобразования динамического полиморфизма в статический.
В общем, думаю что через несколько лет (возможно десятков) у разработчиков компиляторов/рантаймов и т.п. руки дойдут и до этого. Тогда вопрос статичности или динамичности полиморфизма станет таким же важным как сейчас вопросы автоматического инлайнинга методов, т.е. будут интересовать только разработчиков компиляторов.
Я с этим утвнрждннием не согласился и привел свои доводы. Скажи, где моя ошибка?
Здравствуйте, VladD2, Вы писали:
VD>Думаю, ты ошибашся. И в ФЯ при статическом полиморфизме генерируются тучи воплощений. (тому примером являются декомпилированные исходники того же SML.NET). И макросмаи конечно шаблоны не являются, так как проходят синтаксическую проврку. И примитивными они не являются, так как на ним очень многое можно сделать.
VD>В общем, ненадо недооценивать технологии которые не нравятся. И переоценивать те, которые нравятся.
Даже если и генерируются, то исключительно в целях оптимизации. А про макросы. Ты вообще в курсе, что из себя представляют макросы в Лиспе? Они тоже проходят синтаксическую проверку, ну и что, единственное их отличие от обычных функций состоит в том, что они преобразуют код программы на этапе компиляции. А сделать ими можно просто на несколько порядков больше, чем в С++. В С++, например, невозможно объявить новую конструкцию в языке. Если там не было бы while (бы ли бы только goto), никаким удовлетворительным образом невозможно было бы создать макрос реализующий эту конструкцию, а в Лиспе — это одна из простейших задач. Тут вообще не о чем спорить, в Лиспе данные и код выглядят одинаково и последний легко обрабатывать средствами самого языка. С++ с его шаблонами такое и не снилось.
(while (cond) (operators)) <- Вот такое возможно в Лиспе
Кстати, уверен, что с утверждением, что шаблоны в С++ примитивны по сравнению с макросами в Лисп, согласится любой, кто знает оба языка. И еще раз, примитивны не в смысле, что они просты, а что возможностей они предоставляют на порядки меньше.
Здравствуйте, Quintanar, Вы писали:
Q>Даже если и генерируются, то исключительно в целях оптимизации.
Достаточно этого. В С++ все делается исключительно для оптимизации. Язык, понимаш, системного программирования.
Q> А про макросы. Ты вообще в курсе, что из себя представляют макросы в Лиспе?
В курсе, более менее. Но вот Лисп тут приплетать не стоит. Уж лучше поговорить о препроцессоре Окамла. А то для лиспа по барабану, что код, что данные. Один фиг интерпретация.
Q> Они тоже проходят синтаксическую проверку,
Ага. На совместимость с С-выражениями.
Q> ну и что, единственное их отличие от обычных функций состоит в том, что они преобразуют код программы на этапе компиляции.
Которой по сути нет. И получается, что точно так же генерируют специализации, только из-за того, что рантайм пермешан с компайлтаймом, черт ногу сломит в классификации того или иного явления.
Q> А сделать ими можно просто на несколько порядков больше, чем в С++.
Очередное преувеличение. Аналогично моожно сделать обратное заявление. А что? Попробуй сделать типизированную конструкцию на Лиспе?
Q> В С++, например, невозможно объявить новую конструкцию в языке.
Да можно. Есть маньяки которые уже пол Плюсов переписали. Вот только получается так же натянуто и криво как и на Лиспе. В итоге черт ногу сломит в этом коде.
Честно говоря Лисп с его миллионом скобочек меня вводит в состояние гипноза.
Q> Если там не было бы while (бы ли бы только goto), никаким удовлетворительным образом невозможно было бы создать макрос реализующий эту конструкцию,
Да?
#define While(condition) { if (!(condition)) goto end_while;
#define EndWhile end_while: }
...
int i = 0;
While(i < 10)
...
i++;
EndWhile
Q> а в Лиспе — это одна из простейших задач. Тут вообще не о чем спорить, в Лиспе данные и код выглядят одинаково
одинаково фигово.
Q> и последний легко обрабатывать средствами самого языка. С++ с его шаблонами такое и не снилось.
Ну, а Лиспу не снилось то что делают на шаблонах плюсов. Лисп конечно можно выразить через самого себя. Но вот работать это будет еще медленее чем он сам. А плюсы не смотря на ве количество граблей заложенных в них позволяют писать шустрый код.
Q>Кстати, уверен, что с утверждением, что шаблоны в С++ примитивны по сравнению с макросами в Лисп, согласится любой, кто знает оба языка. И еще раз, примитивны не в смысле, что они просты, а что возможностей они предоставляют на порядки меньше.
Да разные они. Для разного предназначены. Твое утверждение изначально некорректно. И принципияльно содержит в сбебе желаение узизить эти самые шаблоны. Нормально бы звучал заявление вроде "В лиспе есть возможности которые или вообще отстсуствуют в С++ или трудно реализуются." Как в прочем верно было ы и братное. Но тут и спорить бы никто не стал.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Достаточно этого. В С++ все делается исключительно для оптимизации. Язык, понимаш, системного программирования.
Но специализация необязательна. Шаблоны же специализируются не по желанию, а по необходимости и в этом значительно отличаются от полиморфных функций. И язык системного программирования не С++, а С.
VD>В курсе, более менее. Но вот Лисп тут приплетать не стоит. Уж лучше поговорить о препроцессоре Окамла. А то для лиспа по барабану, что код, что данные. Один фиг интерпретация.
Поскольку Лисп изучается во многих западных университетах, то весьма вероятно, что идея шаблонов возникла не на пустом месте, а по аналогии с Лиспом. Ибо это первый язык, где подобная идея была внедрена и используется очень интенсивно. Препроцессор OCaml'a тоже не на пустом месте возник. Люди видят насколько полезны макросы и пытаются внедрить их в другие языки.
VD>Которой по сути нет. И получается, что точно так же генерируют специализации, только из-за того, что рантайм пермешан с компайлтаймом, черт ногу сломит в классификации того или иного явления.
Для Лиспа существуют компиляторы. Так что рантайм и компайлтайм там разграничены. Никто не запрещает естесвенно пользоваться интерпретатором, но для эффективности стоит программы компилировать.
VD>Очередное преувеличение. Аналогично моожно сделать обратное заявление. А что? Попробуй сделать типизированную конструкцию на Лиспе?
Лисп нетипизированный язык, поэтому предложение сделать типизированую конструкцию бессмысленно. Нужно сравнивать какие возможности предлагают шаблоны и макросы. С++ не позволяет значительно преобразовывать свой код, все, что он позволяет, это осуществить замену какого-нибудь Т на название реального класса в теле шаблона. Подобное безусловно легко сделать на Лиспе. С другой стороны мы не можем передать в качестве параметра шаблону операторы С++ (если не считать, что мы это эмулируем с помощью специального класса, что не очень здорово) и, наконец, мы уж точно не можем как-то изменить эти операторы — какие-то может быть выкинуть, что-то добавить в зависимости от того, что нам передали.
VD>Да можно. Есть маньяки которые уже пол Плюсов переписали. Вот только получается так же натянуто и криво как и на Лиспе. В итоге черт ногу сломит в этом коде.
Это в С++ криво и натянуто, а в Лиспе нормально. Может написать макрос или понять его не так уж легко, но пользоваться им можно без проблем, поскольку это выглядит как вызов обычной функции.
VD>Честно говоря Лисп с его миллионом скобочек меня вводит в состояние гипноза.
А если есть 2 вложенных while?
Q>> а в Лиспе — это одна из простейших задач. Тут вообще не о чем спорить, в Лиспе данные и код выглядят одинаково VD>одинаково фигово.
Опять же, дело привычки.
VD>Ну, а Лиспу не снилось то что делают на шаблонах плюсов. Лисп конечно можно выразить через самого себя. Но вот работать это будет еще медленее чем он сам. А плюсы не смотря на ве количество граблей заложенных в них позволяют писать шустрый код.
Хм. макросы обрабатываются на этапе компиляции программы, поэтому замедлять Лисп они врядли могут.
VD>Да разные они. Для разного предназначены. Твое утверждение изначально некорректно. И принципияльно содержит в сбебе желаение узизить эти самые шаблоны. Нормально бы звучал заявление вроде "В лиспе есть возможности которые или вообще отстсуствуют в С++ или трудно реализуются." Как в прочем верно было ы и братное. Но тут и спорить бы никто не стал.
Почему же унизить? Если я скажу, что в С++ поддержка списков и деревьев на уровне языка примитивная, я его унижу? Я вижу явные аналогии между макросами и шаблонами и думаю, что последние были придуманы под влиянием Лиспа. Но как не извращайся в С++ выше головы не прыгнешь. Лисп уникален в том смысле, что позволяет модифицировать свой код и писатели макросов этим активно пользуются. В С++ возможны только самые примитивные операции с кодом типа Find&Replace и поэтому макросы-шаблоны там автоматически будут более примитивными. В OCaml придумали кое-что попродвинутей, кстати.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
К>>Я думаю, что множества скорее всего почти совпадают, но мощность у них очень мала К>>З.Ы. Интересно — кто-нибудь видел всуе живого теоретика/практика ФП? (в смысле близкого к разработке ФЯ)
VD>Ява 1.5, кстати, вышла. А бэты дотнета более чем достаточно для изучения.
И к чему это ты?
Ява уже у нас ФЯ теперь чтоли и исходники компилятора её смотреть???
Здравствуйте, Quintanar, Вы писали:
Q>И язык системного программирования не С++, а С.
Отчасти это так, но только из-за того, что компиляторы С проще, и, следовательно, более распространены.
Q>Поскольку Лисп изучается во многих западных университетах, то весьма вероятно, что идея шаблонов возникла не на пустом месте, а по аналогии с Лиспом. Ибо это первый язык, где подобная идея была внедрена и используется очень интенсивно. Препроцессор OCaml'a тоже не на пустом месте возник. Люди видят насколько полезны макросы и пытаются внедрить их в другие языки.
какая разница, что появилось первым?
Q>Лисп нетипизированный язык, поэтому предложение сделать типизированую конструкцию бессмысленно. Нужно сравнивать какие возможности предлагают шаблоны и макросы.
Именно потому, что лисп нетипизированный язык, сравнвать его с С++ просто не имеет смысла! Шаблоны в С++ оперируют типами, а в лиспе на этапе компиляции типов нет, следовательно, он не может покрыть возможностей шаблонов С++. А дальше обсуждать нечего.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, Quintanar, Вы писали:
Q>>И язык системного программирования не С++, а С. V>Отчасти это так, но только из-за того, что компиляторы С проще, и, следовательно, более распространены.
Да неужто? Везде где есть gcc есть и g++. Даже на древних HPUX'ax у нас в универе есть С++.
И не от части, а почти всегда.
Q>>Поскольку Лисп изучается во многих западных университетах, то весьма вероятно, что идея шаблонов возникла не на пустом месте, а по аналогии с Лиспом. Ибо это первый язык, где подобная идея была внедрена и используется очень интенсивно. Препроцессор OCaml'a тоже не на пустом месте возник. Люди видят насколько полезны макросы и пытаются внедрить их в другие языки. V>какая разница, что появилось первым?
Большая. Потому что выдумать что-то новое нелегко, проще адаптировать чужие идеи под свои нужды.
V>Именно потому, что лисп нетипизированный язык, сравнвать его с С++ просто не имеет смысла! Шаблоны в С++ оперируют типами, а в лиспе на этапе компиляции типов нет, следовательно, он не может покрыть возможностей шаблонов С++. А дальше обсуждать нечего.
Бред какой-то. Типа, если в Лиспе нет оператора for, то он не может покрыть возможностей С++? Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны.
Здравствуйте, Quintanar, Вы писали:
Q>Да неужто? Везде где есть gcc есть и g++. Даже на древних HPUX'ax у нас в универе есть С++.
И что с того?
Q>Большая. Потому что выдумать что-то новое нелегко, проще адаптировать чужие идеи под свои нужды.
И что с того?
Q>Бред какой-то. Типа, если в Лиспе нет оператора for, то он не может покрыть возможностей С++? Лиспу не нужны эти возможности шаблонов, поскольку в его рамках они бессмысленны.
Повторяю еще раз. Шаблоны в С++ нужны для манипуляции типами. Ты говоришь, что шаблоны в лиспе лучше, чем шаблоны в С++. Из этого сравнения следует вывод, что шаблоны лиспа лучше манипулируют типами, чем шаблоны С++. Но в лиспе нет типов!!! Следовательно, само сравнение шаблонов С++ и лиспа БРЕДОВОЕ! Это разные, несравнимые вещи.
