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

G>

G>ось представляла собой колоссальное количество макросов.

Это пять. Все равно как если бы Испания сегодня попыталась привлечь астронома Фрэнка Дрэйка к отвественности за Номбре де Диос. "Верни наше серебро, подлый пират!"

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

G>>Индустрия имела макросы в далеких 70-х. И отказалась от них вместе с ассемблерами и языками-монстрами вроде PL/1 — с появлением простых и понятных языков высокого уровня.
IT>Я не уверен в том, что макросы имела именно индустрия. Отдельные исследовательские проекты возможно. Но насчёт всей индустрии я бы не стал утверждать. Вообще, востребованность инструмента напрямую зависит от сложности вхождения в него. Если сложность вхождения в те макросы была запредельной, то результат вполне закономерный.

На самом деле макросов, как преобразований над AST, индустрия не имела никогда. Индустрия имела текстуальные препроцессоры a la препроцессор C и макроассемблеры. Все это к современным макросистемам вроде Nemerle или Template Haskell имеет такое же отношение как и макросы Word-а, т.е. сходство только в названии.
70-е годы это раннее детство Scheme, с ее гигиеническими макросами, ну а Scheme никогда в индустрии широко не использовалась.
Поскольку тогда таких средств композиции/декомпозиции кода как квазицитирование и паттерн-матчинг не существовало, LISP и Scheme платили за наличие в них макросов специфическими синтаксическими особенностями, из-за которых отношение к ним в индустрии было в лучшем случае холодным, а в худшем — резко отрицательным. (Естественно, лисперы скажут, что это, наоборот, очень сертезное преимущество. А LISP, по моему, вообще один из самых недооцененных языков. Вот и я его всегда недооценивал, недооцениваю сейчас и буду недооценивать и дальше, по всей видимости.) Со времен LISP макросистемы развивались в основном в сторону повышения безопасности (лиспер скажет — в сторону увиличения числа ограничений).
Посмотрел бы я, что сделали здесь с ветераном, заявившим что-то вроде "Видел я ваш сборщик мусора в шестьдесят-лохматом году в Simula — жуткий тормоз. То ли дело FORTRAN 77 там проблем с хипом вообще нет!" — а обсуждать недостатки макросистемы на примере PL/I это еще смешнее.
Короче говоря, Gaperton валит с больной головы если и не на здоровую, то, по крайней мере, на неизвестно какую. Учитывая, что новые макросистемы — изделия начала — середины двухтысячных годов, легко видеть, что в индустрии их еще никто не имел возможности испробовать, так что все грабли в этой области еще ожидают своих первооткрывателей.

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

K>На самом деле макросов, как преобразований над AST, индустрия не имела никогда. Индустрия имела текстуальные препроцессоры a la препроцессор C и макроассемблеры. Все это к современным макросистемам вроде Nemerle или Template Haskell имеет такое же отношение как и макросы Word-а, т.е. сходство только в названии.

Вы определитесь. А то ведь Nemerle и Haskell тоже к индустрии отношения не имеет.

K>70-е годы это раннее детство Scheme, с ее гигиеническими макросами, ну а Scheme никогда в индустрии широко не использовалась.

А Dylan куда забыли? IMHO, по идеологии очень мало от него Nemerle ушло.

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

K>>Это решение моей задачи? Я прямо-таки недоумеваю, дорогая редакция!

E>Именно:
E>

E>Имеем: x := alpha * p + omega * s;

E>Разворачивается в:
E>

E>for(i = 0; i < x.Length; i++)
E>{
E>    x[i] = alpha * p[i] + omega * s[i];
E>}
E>

E>конкретно это и производится.

Я заметил. А где возможность написать второй пример из моей задачи?

r := b - A*x;

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

Что Вы! Я не просто "больше математик, чем программист" — я вообще не программист, а физик. Образования программиста я не получал.
И хотя некоторые физики не любят, когда их называют математиками, мне все равно очень приятно, спасибо.

E>Поскольку из показанного мной решения можно сделать, например, вот такое:

Да. Вы привели пример решения какой-то другой задачи, из которого таки можно сделать пример решения моей. С этим я согласен.

E>

<...>

E>void
E>main()
E>    {
E>        const int vector_size = 5;
E>        float a_src[ vector_size ] = { 1, 2, 3, 4, 5 };
E>        float b_src[ vector_size ] = { 0.5, 1.5, 2.5, 3.5, 4.5 };

E>        vector_t a( a_src, a_src + vector_size );
E>        vector_t b( b_src, b_src + vector_size );
E>        vector_t d( b_src, b_src + vector_size );
E>        vector_t c;

E>        c << 0.0 * a + 2.0 * b - 1 * d + b / 0.2;

E>        std::cout << c << std::endl;
E>    }
E>

E>А если потратить еще некоторое количество времени, то можно сделать еще и поддержку некоторых других сочетаний. Но здесь, вероятно, придется задействовать динамическую память, чтобы классы, производные от vector_element_extractor_t могли сохранять свои операнды по указателю. Чтобы можно было обрабатывать выражения типа:
E>

E>((a1 * v + a2 * v2)/0.5 - (a3*v3 - a4*v4)*2) * 0.75;
E>

E>Но такие операции будут эффективны только на больших размерностях. В противном случае расходы на new/delete окажутся значительно дороже, чем сами вычисления.

Да, это уже больше похоже на решение моей задачи, но с оверхедом по производительности ее можно решить во многих языках и без всяких макросов. Но я-то интересовался как ее сделать без оверхэда. Поэтому вопрос остается открытым.

E>Все проще. Если вы решаете свои вычислительные задачи в рамках своей работы, то можете сами оценить, во что обходится качественный, надежный, универсальный и расширяемый библиотечный код. Соответственно, можете предположить, что я не могу пренебречь своей собственной работой для того, чтобы потратить несколько дней на проектирование достаточно хорошей библиотеки отложенных векторно-матричных вычислений. Тем не менее, данный код показывает, что в C++ можно значительно к этому делу приблизится.

Ну разумеется, я не расчитывал на то, что Вы специально ради меня напишите качественный, надежный, универсальный и расширяемый библиотечный код. Я ожидал пример, иллюстрирующий принцип. Во второй раз у Вас получилось гораздо лучше.

E>Сначала я дал точную ссылку на Страуструпа, где показан принцип отложенных вычислений. Розовый слон косвенно обвинил меня в трепачестве.

Я знаю о Вашей войне с "Розовым слоном" и был бы просто счастлив, если бы Вы меня в нее не вовлекали.

E>Я потратил 15 минут на воспроизводство примера Страуструпа и еще 15 минут своего времени на оформление сообщения с этим кодом. Это практически все, что я мог себе позволить. Вам этого недостаточно? Отлично, я потратил еще 45 минут на это сообщение и новый пример. Что дальше?

Да ничего. Я от Вас вообще ничего не требую. Разумеется, я безмерно благодарен Вам за потраченное на меня время, пусть даже это и было сделано ради тактического контр-наступления на "Розового слона" или чего-то вроде того.

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

EC>В случае макросов обезьянка не может их изучить за свой счёт. Следовательно издержки растут.
EC>Я правильно понимаю твою позицию?

Вроде того. Только не "не может", а "не будет". Единственный шанс — если будет библиотека макросов очень широко используемая, типа boost.

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

M>Свобода действий устрицы ограничена двумя состояними — открытой или закрытой раковиной. Именно это деалет поведение устриц столь понятным и надёжным. Увы, пока эти значительные преимущества не превратились в доминирование устриц как биологического вида, но природа работает над этим.

Доказательство по аналогии есть голая демагогия.

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

K>Поскольку тогда таких средств композиции/декомпозиции кода как квазицитирование и паттерн-матчинг не существовало

http://en.wikipedia.org/wiki/Pattern_matching#History

History

The first computer programs to use pattern matching were text editors. At Bell Labs, Ken Thompson extended the seeking and replacing features of the QED editor to accept regular expressions. Early programming languages with pattern matching constructs include SNOBOL from 1962, NPL from 1977, and KRC from 1981. The first programming language with tree-based pattern matching features was Fred McBride's extension of LISP, in 1970.

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

К>Будет новый набор решений, но вот обязательны ли для них макросы?

Я не знаю. Это будет напрямую зависеть от решаемой задачи. Главное, что я предпочитаю иметь в своём арсенале весь набор возможных средств, а не только тот, который мне определили те, кто считает нас всех обезъянками.

К>Имхо, нужно ограничить их реализумость/применимость/видимость. Т.е. сделать что-то аля "только программист с чёрным поясом по N может писать макросы и он должен учитывать по возможности последствия их применения".

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

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

K>На самом деле макросов, как преобразований над AST, индустрия не имела никогда.
???????
LISP!

Я точно знаю, что квазицитирование в нем точно использовалось. А еще были кучи Лисп-подобных языков.

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

AVK>Доказательство по аналогии есть голая демагогия.

Это не доказательство, а повод для размышления.

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

EC>>Зная этот базовый набор можно изучить любую библиотеку.

K>Теоретически — да. На практике — нет. Вот только если изучить любую библиотеку — не проблема, то тогда и с макросами проблем нет, потому, что макрос — это библиотечный класс, написанный на том-же языке что и любой другой библиотечный класс.

Если речь о том, что макрос чисто технически это просто класс, то это никак дело не менят.
Речь о другом.
Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).
Макрос же совсем другое дело.

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

EC>Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).
EC>Макрос же совсем другое дело.
В Java-мире такие библиотеки — достаточно распространенное явление. Только они работают обычно уже над байт-кодом скомпилированых классов.

Большинство Java-программистов стараются использовать такие библиотеки как можно меньше, так как ошибки в них находить и исправлять на порядок сложнее, чем в обычном коде.

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

EC>>Мне пока не встречались библиотеки, модифицирующие код, который я пишу (или может я просто не в курсе).
EC>>Макрос же совсем другое дело.
C>В Java-мире такие библиотеки — достаточно распространенное явление. Только они работают обычно уже над байт-кодом скомпилированых классов.

Ты говоришь об инструментировании байт кода?
Это всё-таки работает уровнем ниже — соответственно эффект не настолько значительный.
Насколько я знаю таким образом решаются очень узкие классы задач.
Видимо потому как куча семантической информации уже потеряна к моменту инструментирования.

C>Большинство Java-программистов стараются использовать такие библиотеки как можно меньше, так как ошибки в них находить и исправлять на порядок сложнее, чем в обычном коде.

Я их очень понимаю. Я бы использовал такие средства в самую последнюю очередь.

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

EC>Я правильно понимаю, что для того, чтобы понять что делает макрос нужно довольно подробно представлять как устроено AST,

Зависит от сложности макроса. Наример, для написания такого макроса много знать не надо:

macro repeatmacro (times, body)
syntax ("repeat", "(", times, ")", body)
{
  <[ for (mutable t = $times; t > 0; --t) $body ]>
}

EC>какие есть фазы компиляции, как AST может трансформироваться на каждой из них?

Для написания более сложных вещей желательно иметь полное представление.

EC>Т.е. при применении макроса с моим кодом может произойти практически любая трансформация?

Практически любая.

EC>Если так, то именно это людей и настораживает.

Пока я услышал только две версии, которые настораживают людей:

— обезъянкам будет трудно;
— неадекватные девелоперы накосячат.

EC>Потому как я применяя yield return точно знаю, что сделает компилятор и как это всё локализовано.

Тогда как ты можешь использовать библиотечные классы и их методы, если ты не знаешь точно, что они делают?

Вообще, есть одна простая мысль, которую я уже неоднократно высказывал.

Сложность/качество/функциональность/добавить-по-вкусу программного обеспечения не может превышать более чем на порядок сложности/качества/функциональности/дабавить-по-вкусу инструмента, на котором оно разработано.

Нельзя в одиночку выкопать котлован для многоэтажного здания с помощью совковой лопаты. Нужен экскаватор. Но и экскаватор абсолютно бессилен перед вечной мерзлотой. Здесь уже нужен Камацу или Катарпиллер со специальным клыком. Может ли быть опасен Камацу в обычных условиях? Может. Сам видел в стройотряде в Новом-Уренгое, как один советский камацист, нажрамшись показывал нашему комиссару как работает буржуазная техника. По неосторожности опустил клык и, даже не заметив этого, пропахал попрёк всю автобазу. Опасно? Опасно. Но, простите, господа, советский камацист был в жопу пьян. Если бы тогда тяжелую технику не стали использовали по причине того, что пьяные трактористы (читай неадекватные девелоперы) будут представлять на ней опасность, то сегодня Вова не показывал бы факи налево и направо всяким Англиям.

Не вижу никакой разницы для производства софта. Сегодня мы уже ограничены теми средствами, которые используем. Всё, приплыли. Даже такая контора как MS, в которой работают тысячи талантливых программистов не может вот так взять и с нуля зафигачить новую операционную систему. Попробовали, не получилось. Пришлось по быстрячку перекрашивать 2003-й сервер в Висту. А почему? Не из-за уровня ли используемых средств разработки? Думаю, во многом из-за этого тоже.

Короче, пора переходить на декларацию, а это в крупных масштабах возможно только с макросами.

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

IT>Зависит от сложности макроса. Наример, для написания такого макроса много знать не надо:
IT>

IT>macro repeatmacro (times, body)
IT>syntax ("repeat", "(", times, ")", body)
IT>{
IT>  <[ for (mutable t = $times; t > 0; --t) $body ]>
IT>}
IT>

Так ведь такой макрос почти бесполезен. А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.

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

AVK>http://en.wikipedia.org/wiki/Pattern_matching#History

А первым компьютерным (вычислительным) устройством были счёты.

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

C>Так ведь такой макрос почти бесполезен. А сложные макросы уровня реализации LINQ'а писать будет нааамного сложнее.

Я разве утверждал обратное? Я лишь ответил на вопрос. Может быть не достаточно ясно? Но ты — молодец, безжалостно эту неясность искоренил

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

M>Вы определитесь. А то ведь Nemerle и Haskell тоже к индустрии отношения не имеет.

Любезнейший, Вы меня с кем-то путаете. Где я говорил, что они опробированы индустрией?

M>А Dylan куда забыли? IMHO, по идеологии очень мало от него Nemerle ушло.

Dylan с Nemerle имеет очень мало общего. Начнем с того, что он динамически-типизированный, так что он на Схему больше похож (не синтаксически, конечно) чем на Немерле.

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

K>>Поскольку тогда таких средств композиции/декомпозиции кода как квазицитирование и паттерн-матчинг не существовало
AVK>The first computer programs to use pattern matching were text editors. At Bell Labs, Ken Thompson extended the seeking and replacing features of the QED editor to accept regular expressions. Early programming languages with pattern matching constructs include SNOBOL from 1962, NPL from 1977, and KRC from 1981. The first programming language with tree-based pattern matching features was Fred McBride's extension of LISP, in 1970.[/q]

См. выделенное. Я говорил не про pattern-matching вообще — а про pattern-matching, как средство декомпозиции AST в макросистеме.

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

K>>На самом деле макросов, как преобразований над AST, индустрия не имела никогда.
C>???????
C>LISP!

А что, LISP широко применялся индустрией? Вот это новость.

C>Я точно знаю, что квазицитирование в нем точно использовалось.

Честно говоря, принимая во внимание лисповский синтаксис и общую идеологию code is data is code, я вообще с трудом представляю, зачем в LISP нужно (квази)цитирование, как я его понимаю. И термин этот вместе с LISP вообще очень редко встречается. Но я не поленился и поискал статьи по этой теме на CiteSeer. Да, статьи по квазицитированию в LISP есть. Самая старая, что я нашел — 1999 года.