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

EC>>Можете привести какие-то из задач, которые вы решаете где макросы самое оно?
M>Чем сложнее программа, тем проще привести пример.

M>Я написал систему трансформации AST, которая мне генерирует все необходимые дополнительные классы и методы.

Если нужна кодогенерация, то лучше макросов ничего нет. Однако в этом смысле исходный вопрос этого топика можно перефразировать как "Является ли кодогенерация свидетельством недостаточной выразительности языка, в который мы генерим". К сожалению, я не знаю подробностей задачи — что именно ты генеришь, чем отличаются эти сущности и т.д. Сам скажи — если бы таргет язык был более мощным (если да — то что именно для этого надо) — можно было бы обойтись без макросов?

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

C>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.

[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?

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

K>Нет, немного не то. То какой в результате текст генерится можно в студийной интеграции посмотреть простым наведением мышки на макрос. Я имел ввиду полноценную отладку, такую как если бы это был обычный код. Т.е. поставить в каком либо месте брейкпойнт, пройтись через F10-F11 по коду, смотреть какие значения переменных в данный момент, следить за калл стеком, условные брейкпойнты итд итп

Понятно. Да, если это встроено — это здорово.

В принципе, это можно сделать и в нормальной среде/отладчике, которая/ый допускает вменяемое программирование себя (т.е. скидывать сгенеренный текст во временный файл, автоматом проставить там все брейкпоинты и заинклудить его куда надо). В принципе, это же я делаю вручную, когда отлаживаю макросы — просто ставлю в нужном месте #include "generated.h", где generated.h — это результат работы препроцессора, и в нем уже расставляю брейкпоинты. Правда, я сомневаюсь, что в студии можно такую автоматику навернуть.

You will always get what you always got
  If you always do  what you always did

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

AVK>LINQ подразумевает неявное представление лямбды ввиде expression tree или генерации кода в зависимости от ожидаемого типа делегата, а немерлевые макросы вызываются только явно, по атрибуту, псевдофункции или ключевому слову. Все это осложняется extension methods.

Влад утверждал, что возможен вызов макроса не по имени. Правда, не берусь утверждать, что я его верно понял. Ответа я не получил (может позже). Хотя мне кажется, что имелось в виду что то вроде вызова макроса на самом-пресамом-верхнем уровне что то вроде boo{...}, либо атрибута на верхнем уровне, который будет перелопачивать потроха нужным образом.

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

C>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.
К>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.

Вот тут более подробно про эту фичу в IDEA: http://www.jetbrains.net/confluence/display/CONTEST/IntelliLang

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

C>Здравствуйте, Курилка, Вы писали:

C>>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.
К>>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
C>Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.
А на эту тему ссылок нет под рукой?

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

C>>>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.
К>>>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
C>>Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.
К>А на эту тему ссылок нет под рукой?
Я это где-то на TheServerSide видел, сейчас найти быстро не могу.

Или тебе ссылки на архитектуру Eclipse нужны?

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

C>Здравствуйте, Курилка, Вы писали:

C>>>>>Кстати, добавление своего плагина для обработки injected language в IDEA делается достаточно просто и безболезненно.
К>>>>[OFFTOP] А у Эклипса есть что-нибудь на эту тему? Не в курсе?
C>>>Пока нет. У них архитектура для этого плохо подходит. Хотя начинают шевелится в эту сторону.
К>>А на эту тему ссылок нет под рукой?
C>Я это где-то на TheServerSide видел, сейчас найти быстро не могу.
Ну поверю на слово тогда

C>Или тебе ссылки на архитектуру Eclipse нужны?

Да не, спасибо, пока туда лезть не хочу

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

IT>В-четвётых. Аналогичная проблема возникает при ручном конструировании запросов, что необходимо для реализации всевозможных фильтров. Линк здесь уже никак не поможет и придётся заниматься самой обычной императивщиной.

Здесь можно поподробнее?

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


IT>Давай возьмём для примера тот же линк и попробуем его применить, допустим, для веб-приложения. У linq есть следующие весьма привлекательные возможности:

IT>- устранение одноразовых структур для ad-hoc запросов;
IT>- устранение pass-through слоёв.
Я испуган...

IT>Учитывая, что в большинстве случаев логика веб-приложения диктуется именно UI, у нас вместо трёх слоёв и дополнительной структуры может получится вот такая простая вещь из 3-х строк:

IT>

IT>grid.Source = from c in customers   
IT>              join o in orders on c equals o.Customer into oo   
IT>              select new { c.CompanyName, OrderCount = oo.Count() 
IT>

IT>Пока всё просто замечательно.
Не согласен. То что ты здесь написал — это есть "встроенный макрос". Мне вообще непонятно зафигом его ввели. Говорить о том, что визуальность по сравнению с функциональной записью кардинально увеличилось — не приходится. А вот ограничения введеные данным макросом — налицо.


IT>Во-первых, из-за кривой реализации баиндинга в ASP.NET, при работе с навороченными веб-контролами типа GridView, объект должен реализовывать интерфейс ICustomTypeDescriptor. В противном случае мы нарываемся на рефлекшин со всеми вытекающими последствиями. Будут ли анонимные типы реализовывать ICustomTypeDescriptor? У меня есть на этот счёт определённые сомнения.
На фоне генерации грида и работы с бд — выигрыш будет очень незначительным.

IT>Во-вторых, несмотря на то, что вся информация о запросе у нас доступна в компайл-тайм, мы получим генерацию SQL в райн-тайм, опять же со всеми вытекающими последствиями.
Это нормально. Провайдер может быть подменен.

IT>В результате, хотя всё и выглядит зашибись, мы уже получили неустранимые проблемы. Точнее первую можно легко устранить, но за счёт отказа от анонимных типов и возврата к одноразовым типам. Второе даже не знаю, разве что написать Linq2Me и огранизовать кешироание запросов самостоятельно.
Кэширование запросов или результатов?

IT>Поехали дальше.

IT>В-третьих. Обрати внимание вот на этот

Автор: fuurin
Дата: 04.08.07

знаковый топик и особенно на ответ.

IT>

IT>Нет, потому что штатно LINQ2SQL этого не поддерживает, а расширять генерацию SQL можно будет только в следующей версии.

IT>Учитывая, что разница между версиями у нас 2005 — 2008, то как говорится обещанного три года ждут.
Это особенности провайдера LINQ2SQL. К макросам отношение имеет мало.

IT>В-четвётых. Аналогичная проблема возникает при ручном конструировании запросов, что необходимо для реализации всевозможных фильтров. Линк здесь уже никак не поможет и придётся заниматься самой обычной императивщиной.
Линк ленив. Забудь о встроенном макросе — пиши в функциональном виде. Собрать запрос — вещь тривиальная.

IT>В-пятых. Предположим, что я захотел добавить кеширование результата запроса в зависимости от параметров. Как мне поможет в этом линк? Да никак. Мне теперь придётся отказаться не только от анонимного типа, но и вернуться к слоям.
Ага. Посему и удивился твоему утверждению про pass-through.

IT>В-шестых. Предположим, что ко всему прочему в моём приложении используется система ограничения доступа к контенту. При использовании линк я вынужне буду добавлять фильтрацию контента к каждому запросу. Вопрос, справятся ли с этим обезъянки.
Аналогично. Отказ от pass-throught и встроенного макроса.

IT>Что можно было бы сделать на макросах?
Не убедил.


IT> И уж точно не придётся править компилятор для того, чтобы повторить возможности линка, т.к. никуда не надо будет проталкивать expression tree. Всё можно будет посчитать в компайл-тайм.
Так и не понял, а нужно ли?

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

С уважением, Gleb.

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

K>Basic — статически типизированный язык.

Ага. Такой же, как я — папа римский.

LET F = 1
LET D = 1.0
PRINT F+D
LET F = "string"

Классику надо знать, даже если это такое дерьмо как бейсик.

BZ>>препроцессор pl/1 имел синтаксис, аналогичный самому pl/1

K>Ну так что? Ключевой момент то в том, что это был препроцессор. Даже очень крутой препроцессор вроде Camlp4 все равно не является макросистемой, ведь он не может получить информацию о типах — для статически типизированного языка это имеет значение.

Балшыт. Макросистема не обязана уметь получать информацию о типах. Дело в том, что ее вообще может не быть, этой информации, так же как и типов. К примеру, макросистема в любом чисто динамическом языке без аннотаций типов этой информации получить не может в принципе. Взять хотя бы тикль. А в ряде приложений, где возможно применение макросистем, типов вообще в природе не существует как понятия — например при обработке текстов или в случае макроассемблера, или языка FORTH.

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

VD>>Вообще-то уже через жопу и уже автогеном. Ты ведь с автоматами вручную копаться стал. Понятно, что паттерн-матчинг тут хоршее подспорье, но я бы предпочел работать с EBNF или другим ДСЛ-ем.

G>Влад, разбор грамматик не только не единственный, но и далеко не самый ходовой случай, когда можно строить конечный автомат. Более того, при разборе грамматики руками никто автоматов не пишет, в таких случаях разбирают рекурсивным спуском. Это гораздо читабельнее и для простых грамматик вполне адекватно.

Полностью согласен. Только я нигде не сказал, что КА == EBNF или что-то подобное. Так что можно было этого всего и не говорить.

G>Есть масса самых разных задач, где встречается КА

Ага. И для каждой такой задачи всегда есть (или можно легко создать) DSL описывающий решаемые задачи очевидным образом. Ну, а уже по текстам на этом языке автоматически генерировать КА.

G>- например, связанных с реализацией сетевых протоколов.

Хороший пример. Вот тот же твой любимый Эрланг включает фактически встроенный DSL для разбора битовых полей. ОК, Эрлангу повезло в этой области. Он разрабатывался людям которым такой ДСЛ был нужен. Но для другой задачи Эрланг будет уже непреспособлен. И только его авторы смогут расширить язык должным образом. А что делать универсальным языкам в которых по их статусу неположено иметь специаилизированных решений? Вот тут МП получается отличным решением.

G> Так что не через жопу и не автогеном.

Да, нет... Как раз именно через жопу и именно неподходящим для этого органа инструментом.

G> Программеру, который под каждый случай разработки КА будет свое языковое расширение или ДСЛ писать, довольно быстро коллеги отстрелят то, что ему танцевать мешает.

Это если коллеги дауны. Уверен, что разумные коллеги сами понимают, что ручное программирование КА, а уж темболее ручная их оптимизация (устранение лишних путей, преобразование НКА в ДКА и т.п.) — это работа для машины. А выполнять вручную работу машины — это и есть первый признак ламерстава. Оставим копипэст для секритарш.

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

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

Макросы — это не колдовство, а способ избавиться от заката солнца вручную. Способ представить решение задачи в наиболее интуитивно-понятном для человека виде, а решение генерировать автоматически с использованием очень правильных, но чересчур низкоуровневых "заковнов физики".

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

BZ>а достаточно ли ты хорошо знаешь хаскел, чтобы это утверждать? это как раз типичная задача на generic programming, которое в хаскеле цветёт бурным цветом (даже я смог насчитать десяток различных средств для него, а ведь я так, мелкий пользователь)

Мне кажется, что достоточно. А вот ты явно недостаточно понял задачу и твои фантазии далеки от реальности.

BZ>у одного из спецов, работающих в этой сфере, любимый пример — есть развесистая структура данных, представляющая собой структуру некоей организации. нужно увеличить зарплату всем сотрудникам организации на 10% если для представления зарплат выделен специальный тип данных:

BZ>data Salary = Salary Double

BZ>то это делается одной строчкой:

BZ>gmap (\Salary x -> Salary (x*1.1))

BZ>в общем и целом, generic программирование обеспечивает автоматическую навигацию по любым контейнерам с организацией обработки только интересующих нас частей информации. основные алгоритмы — gmap, отображающий структуру данных в изоморфную ей, gfold, собирающий информацию (скажем, сумму всех зарплат или список номеров кабинетов), gunfold, конструирующий структуру данных (скажем, при десериализации), gzip, обрабатывающий параллельно два объекта с одинаковой структурой

Если правильно понимаю действие этой штуки, то конечно это интересное решение, вот только боюсь, что не пригодное в реальной жизни. Одним из важнейших аспектов работы этого алгоритма является скорость. Она не просто важна, она жизнанно важна. И тут есть две проблемы. Во-первых универсальные алгоритмы сами по себе не быстры. В том числе и универсальный map скорее всего будет не быстр (ну, да это мои домыслы). А во-вторых, для ускорения работы приходится исключать некоторые ветки из просмотра. Ну, то есть заранее известно, что в таких-то подветках искать бессмысленно, а подветки огромные. Плюс еще некоторые ветки имеют цеклические ссылки, так что нужно как-то исключать зацикливание алгоритма обхода. Лично я даже не представяю как в Хаскеле сделать циклический граф (предпологаю, что без ленивости не обойдется).

Конечно это все общие рассуждения, но на практике весь из себя распрекрасный Хаскель имет очень убогую интеграцию с VS, а вот язык с макросами очень даже полноценную. Конечно можно всегда сказать, что мол программисты делающие интеграцию с VS для Хаскеля слабоваты, но это тоже вряд ли можно считать плюсом для Хаскеля.

BZ>а наиболее известная статья в этой области — "Scrap your boilerpate!", т.е. "выкиньте ваш шаблонный код!" — как будто написана специально для тебя

Вряд ли. Я конечно люблю помечтать. Но мои мечты обязательно должны материализовываться. А вот в то, что Хаскель это материалистический язык я как-то поверить не могу. Уж больно он далек от реальной жизни.

BZ>по теме: ответ да. другое дело, что абсолютно выразительных языков не бывает, в хаселе тоже без макросов не всегда обойдёшься. так что вопрос не в наличии их в языке (запас карман не тянет), а в том, когда их приходится применять.

Согласен. Конечно наличие чудо gmap — это несоменно полезно. Вот только ты прав и в том, что на все случи жизни не напасешся. И тот же gmap отлично можно было бы реализовать на макросах.

Правильно ли я понимаю, что gmap (и другие g*) — это встроенная фукнция языка? Если нет, то очень интересно поглядеть на ее реализацию (и получить пояснения к ней). Если, да, то это еще один случаяй добротного хардкодинга. Но не более того. В любой язык моно захардкодить что угодно. Вот только есть два "но". 1. Все захардкодить нельзя. 2. Захардкоденые решения в большинстве случаев старадат от различных проблем (скорость низка, гикость недостаточная и т.п.).

В общем, gmap — это ХОРОШО! Но лучше если он создан в виде макроса. Чтобы можно было бы создать на его основе специализированную версию. Да и вообще, чтобы на языке можно было создавать подобные вещию.

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

Ну и что? Язык был не полноценным. С++ и сейчас таковым остается. Мы же ведем речь не о таких случаях?

Возмем тот же gmap. gmap и есть та самая магия. Почему магия? А его нельзя объяснитьв термирах основного языка (если я правильно понял). Скажем в Ява/дотнете его аналог можно создать на базе рефлексии. Работать будет на ура, но медленно, а значит не всегда приемлемо. Возможно в каких-то языках его аналог можно будет создат не базе компайлтайм-рефлексии. Но без подобных средств создать gmap мне не представляется возможным. А многие нуждаются в создании подобных магических фунций. И не телько. Кому-то просто хочется сделать синтаксис именно таким как он видит. А кто-то хочет интегрировать в свои программы некий фрэймворк. В общем, бесспорно, что если имеется отлично подходящие средства встроенные в язык, то лучше выбирать их, а не заниматься самодеятельностью и клепать макросы. Но макросы иметь тоже нужно. Иначе рано или поздно прийдется идти на компромисы и довольствоваться огрызками с барского стола.

BZ>то же самое относится и к немерле или хаскелю — случаи, когда приходится применять макросы, высвечивают недостатки языка.

Согласен.

BZ>хорошо, что эти проблемы можно решить хотя бы так, но ещё лучше, если бы макросы совсем не были нужны.

Это утопия.

BZ> особенно кстати это относится к хаскелю, где TH реализован только в одном компиляторе и крайне неудобен в использовании — имо это главным образом инструмент защиты диссертаций, а не реального порграммирования

А это проблемы Хаскеля и его сообщества. Примеры где макросы на очень высоком уровне интегрированы в язык и является частью его спецификации нам известны — Лисп и Немерле.

BZ>на Немерле, насколько я понял, макросы писать проще, но ситуации, когда их приходится использовать, точно так же высвечивают недостатки языка (и вообще всех языков этой группы).

Ты проповедушь совершенно неверную, на мой взгляд, идею — в язык нужно впихнуть все что попало. Я за компактный язык с возможностью гибкого его расширения. DSL-и — это отдельная область. И для их строителсьтва макросы вседа будут идеальным решением. А вот извороты вроде Хаскелевских всегда будут сопровождаться коментариями вроде (ну, вот все замечательно только А кривовато, а Б медленновато, а С зависит от компилятора и направления ветра). Реализация разны магических фунций вроде gmap опять же отличное поле для макросов. В итоге мы получим и там, и там фунцию gmap, которую внешне нельзя будет отличить. Но в одном случае ее смогут создать только создатели компилятора, а в друго любой смертный. Думаю не надо объяснять почему путь макросов лучше?

BZ> например, в хаскеле можно определять управляющие стурктуры — это всего лишь high-order функции, и они пишутся, используются, типо-порверяются, и передаются куда угодно как самые обычные функции. в немерле, С или лиспе это макросы, имеющие иной способ описания и не проверяющие типы своих аргументов

Я не очень понял что значит "управляющие стурктуры". Посему не могу об этом рассуждать. С точки зрения манипуляции функциями Хаскель мало чем отличается от Немерле.

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

L>Если нужна кодогенерация, то лучше макросов ничего нет.
Не совсем верно. Написание макросов значительно легче чем кодогенерация, но в классе задач когда нужна кодогенерация у клиента в зависимости от внешних условий — макросы бесполезны.

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

L>>Если нужна кодогенерация, то лучше макросов ничего нет.
GZ>Не совсем верно.

Ну, в общем да. Это было сказано в контексте разговора.

GZ>Написание макросов значительно легче чем кодогенерация, но в классе задач когда нужна кодогенерация у клиента в зависимости от внешних условий — макросы бесполезны.

Это не понял. Пример?

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

C>>А вот для макросов у нас отладчиков пока нормальных нет.
IT>Макрос отлаживается тем же отладчиком что и любой другой код.
Угу. Во время компиляции.

Я пробовал Nemerle'евые макросы отлаживать — нет, спасибо.

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


GZ>>Написание макросов значительно легче чем кодогенерация, но в классе задач когда нужна кодогенерация у клиента в зависимости от внешних условий — макросы бесполезны.
L>Это не понял. Пример?
По метаданным генерятся типизированные классы. В процессе работы (в runtime), метаданные могут быть изменены пользователем.

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

C>>Вот только это все достаточно просто отлаживается многочисленными существующими инструментами. А вот для макросов у нас отладчиков пока нормальных нет.
M>А библиотеки как отлаживают? Cверяют ожидаемый выход данных с фактическим.
А еще отладчиком ставят брейкпоинты, watch'и добавляют, дампят stacktrace'ы и т.п.

M>Так и макросы отлаживают. Сверяют ожидаемый сгенерированный код с фактически сгенерированным. Инструменты для анализа сгенерированого кода — есть. Они появляются вместе с компилятором, поскольку компиляторы отлаживать тоже надо.
Это все в теории. А на практике нужно будет выяснять почему при определенных стечениях обстоятельств программа вдруг не работает.

M>Опыт отладки макросов может дать, например, такая среда разработки как Eclipse. Только там плагины к IDE отлаживаются, а не макросы, но суть процесса та-же самая. Не пробовали к Eclipse плагины писать?
Пробовал. Не понравилось.

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

M>>Я написал систему трансформации AST, которая мне генерирует все необходимые дополнительные классы и методы.

L>Если нужна кодогенерация, то лучше макросов ничего нет.

Это на каком основании такое утверждение?
Самым мощным средством является непосредственная трансформация AST. Это что-то вроде ассемблера для расширяемого языка/компилятора.
Но она-же и неудобная (в той-же мере, как неудобен ассемблер).
Есть другие способы задания правил трансформации, макросы — один из них, и не более того.

L>Однако в этом смысле исходный вопрос этого топика можно перефразировать как "Является ли кодогенерация свидетельством недостаточной выразительности языка, в который мы генерим". К сожалению, я не знаю подробностей задачи — что именно ты генеришь, чем отличаются эти сущности и т.д. Сам скажи — если бы таргет язык был более мощным (если да — то что именно для этого надо) — можно было бы обойтись без макросов?

Нет, нельзя, ибо генерируемый код и правила генерации являются чисто project-specific.
Если же под "более мощным" понимать язык, в который пихают всякий специфический мусор — то PL/1 покажется стройным и простым