Здравствуйте, lomeo, Вы писали:
IT>>А как быть с декомпозицией кода?
L>Прости, не понял. Что имеется в виду?
Обсуждаемый в этом топике ПМ используется как раз для декомпозиции кода, т.е. для разложения входного потока AST на составляющие и дальшейшего анализа. Например, вот как раскладывает макрос when входные параметры для реализации дополнительных возможностей, если используется конструкция when (x is something):
Здравствуйте, Andrei N.Sobchuck, Вы писали:
IT>> Например, макрос Немерле, анализируя контекст вызова может порождать принципиально разный код.
ANS>Ну, так и любая ST-программа может, например, скомпилировать регэксп непосредственно в ST-байткод. Все манипуляции с кодом, выполняются манипулированием соответствующими объектами. Есть тулзы которые автоматизируют наиболее частые задачи.
Method wrapper — это уже ход в правильном направлении, но он всё ещё далёк от совершенства. Например, похожий способ используется в BLToolkit для генерации абстрактных и расширения виртуальных методов. Но это лишь способ слепить конфетку из того, что было. Тут не может быть никакого сравнения со штатными, специально заточенными для этого средствами метапрограммирования.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Ну, надоело, чесс-слово. ANS>Тебе нужно побуквенное совпадение названия макры?
Я не об опечатках или не совпадениях. Я о том, что это не фича языка, а андстройка реализованная на макросах.
ANS>Или тебе не нравится то, что это макра, а не вколоченная гвоздями сущность?
Мне не ненравится. Это просто факт. Это не языковая фича, хотя несомненно она есть. Только вот не везде.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Какая текстуальная компиляция? Окстись. Я жу написал, если нужен класс создаём объект и всё. Никакой компиляции вообще.
Какой объект надо создать чтобы реализовать некий метод?
VD>>Ну, так мы дойдем, что и C# обладает охриниельной системой метапрограммирования, так как есть библиотеки компиляции кода на лету и возможность его испонять в рантайме.
ANS>Срочно читать мой пост еще раз.
Срочно в лес.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT> Но это лишь способ слепить конфетку из того, что было. Тут не может быть никакого сравнения со штатными, специально заточенными для этого средствами метапрограммирования.
Моя твоя не понимает.
И ежу понятно, что тулза заточенная на работу с АСТ, должна работать с АСТ лучше, чем та, которой на АСТ наплевать. Но это не делает патерн матчинг средством метапрограммирования. Тем более единственным средством. Я тебе показал как создаются новые классы и методы. Это уже метапрограммирование. Если не нравится уровень абстракции, то его всегда можно повысить при помощи либы. Действительно, стандартных средств доступа к АСТ метода нет. Refactoring Browser, как я уже говорил, для этих целей тащит свою компилятор. Кстати, если очень хочется, то можно добавить в объект-метод переменную, в которой и сохранять АСТ, но я сейчас не представляю зачем это нужно.
Что касается макросов и манипуляций с кодом, то в ST _сознательно_ отказались от этого. (afair, в ST-72 каждый объект сам задавал синтаксис потока сообщений, но возникли проблемы "совместимости" синтаксисов). Для создания новых управляющих конструкций в ST есть блоки. А со всякими хитромакросами из Nemerle может получиться продукт, который превзойдёт Perl по количеству способов достичь чего-то. Но к метапрограммированию это не имеет никакого отношения.
ЗЫ. Ты еще раз обрати внимание на то, что разницы между временем компиляции и временем выполнения в ST нет вообще.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
IT>> Но это лишь способ слепить конфетку из того, что было. Тут не может быть никакого сравнения со штатными, специально заточенными для этого средствами метапрограммирования.
ANS>Моя твоя не понимает.
ANS>И ежу понятно, что тулза заточенная на работу с АСТ, должна работать с АСТ лучше, чем та, которой на АСТ наплевать. Но это не делает патерн матчинг средством метапрограммирования. Тем более единственным средством.
Этого никто и не утверждает. Утверждается другое. А именно, что метапрограммирование (*) не живёт без ПМ.
ANS>Я тебе показал как создаются новые классы и методы. Это уже метапрограммирование.
(*) Как я уже сказал, скорее всего у нас есть нестыковка в терминологии. Возможно это метапрограммирование, но это такое же метапрограммирование, как и программирование ячеек в Excel по сравнением с программированием на тех же плюсах. Т.е. несравнимо другой уровень. Я ничего не имею против такого метапрограммирования, но я не его имею ввиду. Если же тебе хочется оспорить сам термин, то, извини, но мне это не интересно. Хочешь, заведи другой топик.
ANS>Если не нравится уровень абстракции, то его всегда можно повысить при помощи либы. Действительно, стандартных средств доступа к АСТ метода нет. Refactoring Browser, как я уже говорил, для этих целей тащит свою компилятор. Кстати, если очень хочется, то можно добавить в объект-метод переменную, в которой и сохранять АСТ, но я сейчас не представляю зачем это нужно.
С этого надо было начинать.
ANS>Что касается макросов и манипуляций с кодом, то в ST _сознательно_ отказались от этого. (afair, в ST-72 каждый объект сам задавал синтаксис потока сообщений, но возникли проблемы "совместимости" синтаксисов). Для создания новых управляющих конструкций в ST есть блоки. А со всякими хитромакросами из Nemerle может получиться продукт, который превзойдёт Perl по количеству способов достичь чего-то. Но к метапрограммированию это не имеет никакого отношения.
Это всё твои домыслы. Может быть приведёт к перлу, а может быть не приведёт. Лично для меня уровень метапрограммирования, предоставляемый Немерле вполне востребован, т.к. более низкие уровни я уже прошёл и нашёл их недостаточными для моих задач.
ANS>ЗЫ. Ты еще раз обрати внимание на то, что разницы между временем компиляции и временем выполнения в ST нет вообще.
Поздравляю с этим всех поклонников ST. Честно, я очень за всех за вас рад.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>(*) Как я уже сказал, скорее всего у нас есть нестыковка в терминологии. Возможно это метапрограммирование, но это такое же метапрограммирование, как и программирование ячеек в Excel по сравнением с программированием на тех же плюсах. Т.е. несравнимо другой уровень.
Безусловно! Незачем заниматься дрыканьем с АСТ, когда всё можно решить на гораздо более высоком уровне абстракции.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
IT>>(*) Как я уже сказал, скорее всего у нас есть нестыковка в терминологии. Возможно это метапрограммирование, но это такое же метапрограммирование, как и программирование ячеек в Excel по сравнением с программированием на тех же плюсах. Т.е. несравнимо другой уровень.
ANS>Безусловно! Незачем заниматься дрыканьем с АСТ, когда всё можно решить на гораздо более высоком уровне абстракции.
А если нельзя?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Вот я показал, как заменить один метод на другой, добавить/удалить метод. Имхо, это именно метапрограммирование и есть. Только оно осуществляется не манипулированием ни АСТ, ни текстуальным представлением программы, а манипулированием теми сущностями, которые есть результат кодогенерации в других языках. То бишь, если в Nemerle тебе, для создания класса нужно произвести манипуляции с AST, то в ST достаточно сделать `Metaclass new`. Всё, наш новый класс можно использовать в программе.
Добавить новый класс, темболее копированием, проблемы не составляет. Проблема заключается в анализе существующего кода, его декомпозиции, построении нового. Понятно, что любой скрипт может сдалеть фукнцию eval и метода addMethod. Проблема в том, что это очень убогий способ создающий много проблем.
ANS>Добавлю, что в ST нет разницы между write time/compile time/run time. Это важное идеологическое отличие от других систем, где все три этапа четко отличимы. Например, когда я в ИДЕ в ST добавляю класс, то он в самом низу создаётся при помощи того же `Metaclass new`. То есть сама ИДЕ метапрограммирует программу.
Ага. А так же нет реального контроля компилятора и по скорсоти он С никогда конкурировать не будет. Только в бредовом тесте вызова виртуальных методов.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, lomeo, Вы писали:
L>Насколько я понимаю строками Потом даём компилеру. Ну или байткод генерить.
И чем это оличается от вызова компилятора во вроемя исполнения?
Понимаешь, ли в чем дело. Основная проблема метапрограммирования не в том, том чтобы скопилировать и выполнить код врантайме. Это практически для любого языка можно сделать. Уж для управляемх вроде Дотнета и Явы точно делается легко. Сделать хотя бы приличную копозцицию кода — это проблема еще та. А уж декомпозиция — это проблемка очень не простая. И решана она на практике только в языках использующих квази-цитирование и сплайсинг (Лисп-ы, МетаОКамл, ТемплейлХаскель). Паттерн-матчин в сочетании с квази-цитированием является вполне удобным средтсвом как композиции, так и декомпозиции.
Вот поглядите на то как можнро сделать печать кода представленного в вдие АСТ: http://nemerle.org/svn/nemerle/trunk/ncc/misc/PrettyPrint.n
Не трудно понять, что аналогичный императивный код был бы практически не читатбельным, а паттерн-матчинг в купе с квази-цитированием делает его почти декларативным.
Если бы еще формирование текста было декларативным, то вообще было бы высший пилота. Причем сделать декларативный вывод текста тоже можно. В АНТЛР сейчас применяется фрэймворк StrigTemplate которая отлично решает эту задачу. Создать ее на макросах более чем ожно и это входит в мои планы. Тогда, например, печать выглядила бы примерно так:
| <[ def $n = $val ]> => %%"def $n = $val;"// $переменная заменяется на значение этой переменной преобразованное в строковый вид.
...
| <[ $obj .[..$args] ]> => %%"$obj.[..$args];"// ..$args раскрывает спиосок разделяя его элементы запятыми
...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, IT, Вы писали:
IT>Обсуждаемый в этом топике ПМ используется как раз для декомпозиции кода, т.е. для разложения входного потока AST на составляющие и дальшейшего анализа.
Втом то и дело что никак. Не факт, что код можно хотя бы в текстовой форме получить. А если и можно, то дальше труба.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Если так, то практический пример в студию.
Лучший практический пример — сам Немерле. Базовые средства языка нестолько бедны, что вряд ли их было бы достаточно, чтобы писать простой и лаконичный код. Тем не менее макро библиотека расширяет язык до уровня, до которого тому же C# ещё как на четвереньках до Парижу.
Если этого недостаточно, то можно ещё упомянуть компайл-тайм анализ кода, на подобии FxCop. Возможность взаимодействия компилятора с SQL сервером для валидации SQL выражений. Эмуляция или взаимодействие со Spec# для выявления логических ошибок в коде. И т.п. На самом деле, достижимый уровень возможностей макросов Немерле пока ограничены лишь фантазией. А с этим, в силу нашей инертности, у нас у всех проблемы.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, eao197, Вы писали:
E>Сложность функциональных языков я вижу не столько в их синтаксисе или еще каких-то внешних проявлений, сколько в необходимости выдумывания решений в функциональном стиле. Что требует серьезной перестройки сознания. В отличии от императивного подхода. Даже переход от процедурного к объектно-ориентированному стилю не требует такого сдвига в способе мышления.
Ой, не скажи.
Не знаю как там переход на ФП, не пробовал еще серьезно перейти, но вот переход от процедурного к объектному стилю очень сложен. И очень много народу до сих пор не умеют применять ООП...
Тут ведь в чем закавыка. Императивные ООП позволяют делать вид, что ты пишешь ООП, хотя на самом деле программируешь процедурно. Это не так редко встречается. Вроде бы да, человек пишет классы, использует private и public, применяет наследование... А посмотри внимательно — и видно, что это лишь программа в процедурном стиле с очень хорошей поддержкой пространств имен (коими выступают классы). По факту отсутсвует правильное разбиение на объекты, разделение обязанностей, выделение интерфейсов и реальная инкапсуляция. С качественным взаимодействием объектов вообще труба.