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

C>Не "на халяву". С помощью макросов просто можно сделать только
C>простенькие примеры. Чего-то нестандартное (типа создания логического
C>языка, например) будет уже того же порядка сложности, что и написание
C>отдельного компилятора.

Фигуленьки. Показать, как написать по тупому эффективный компилятор Пролога на Схеме?

C>Даже наоборот, для отдельного компилятора я могу использовать AntLR для
C>которого есть замечательные визуальные построители грамматик. А вот
C>макросы мне придется руками самому делать.

От визуальных лабалок нигде толку нет — кроме как разве что для демонстрации видимости бурной деятельности.

C>Не макросы, просто интерпретатор. Это проще и быстрее.

C>Может для каких-то очень специфичных задач макросы и подходят, но я их
C>пока что-то не вижу.

Зря. А мне без них тяжко — любая задача без макр решается раз в десять сложнее.

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

NB>>>>Тогда еще вопрос. Зачем нужны макросы.
NB>>>>ИМХО, они позволяют
NB>>>>1. избежать дублирования кода.
G>>>Самые обычные функции с этим прекрасно справляются.

NB>>ну вот из последнего
NB>>

NB>>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>>

NB>>как сделать с помощью функций?

G>Лямбда должна поддерживаться языком. И тогда этот ужас просто не нужен. Тем более, что нормальную лямбду ты все равно не сделаешь, хоть обложись макросами — все равно в мало-мальски сложном случае придется объявлять функтор.

чтобы не было вырвано из контекста: http://aleksey.loginov.googlepages.com/index.html
стандартные функторы (plus,bind1st,equal,...) заменяет прекрасно.
при отсутствии нормальной лямбды, увеличивает читаемость в разы.
например, удаление дублирующихся пробелов:

unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );

G>Пример твоего кода — это как раз такой код, которого в продакшне я видеть не хочу ни под каким видом. Тебя же я переубеждать не собираюсь — это твое дело, как писать. Спорить я с тобой тоже не буду, я уже объяснил, чем такой код с моей точки зрения плох, достаточно доходчиво, чтобы не отвечать в десятый раз на вопросы "почему" — кому надо тот поймет. Ты не обижайся, ничего личного. Это нормально, когда кто-то несогласен со мной или с тобой. Я тебя понимаю прекрасно, возможно и ты поймешь меня когда-нибудь.

Win2k wrote:
> C>Не "на халяву". С помощью макросов просто можно сделать только
> C>простенькие примеры. Чего-то нестандартное (типа создания логического
> C>языка, например) будет уже того же порядка сложности, что и написание
> C>отдельного компилятора.
> Фигуленьки. Показать, как написать по тупому эффективный компилятор
> Пролога на Схеме?
Эффективный? С поддержкой модулей и IO? А может еще с сильной типизацией?

В общем не надо туфту гнать. Простой недоязык получится очень быстро, но
как потребуется добавить обвязку — сразу начнутся интересности (типа:
откуда брать путь поиска для модулей).

> C>Даже наоборот, для отдельного компилятора я могу использовать AntLR для
> C>которого есть замечательные визуальные построители грамматик. А вот
> C>макросы мне придется руками самому делать.
> От визуальных лабалок нигде толку нет — кроме как разве что для
> демонстрации видимости бурной деятельности.
Не видел — не говори. Визуальный построитель грамматики для ANTLR
чрезвычайно удобен, так как умеет подсказывать какие правила применимы в
данный момент, смотреть дерево разбора и т.п.

http://antlreclipse.sourceforge.net/

> C>Может для каких-то очень специфичных задач макросы и подходят, но я их
> C>пока что-то не вижу.
> Зря. А мне без них тяжко — любая задача без макр решается раз в десять
> сложнее.
ROTFL. Советую прочитать про методику Усова и писать на Обероне — так
вообще производительно в 1000 раз возрастет.

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

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

NB>>>>>Тогда еще вопрос. Зачем нужны макросы.
NB>>>>>ИМХО, они позволяют
NB>>>>>1. избежать дублирования кода.
G>>>>Самые обычные функции с этим прекрасно справляются.

NB>>>ну вот из последнего
NB>>>

NB>>>MAKE_BINARY_OP (Plus,plus,T1,+,T2,T1)
NB>>>MAKE_BINARY_OP (Minus,minus,T1,-,T2,T1)
NB>>>

NB>>>как сделать с помощью функций?

G>>Лямбда должна поддерживаться языком. И тогда этот ужас просто не нужен. Тем более, что нормальную лямбду ты все равно не сделаешь, хоть обложись макросами — все равно в мало-мальски сложном случае придется объявлять функтор.

NB>чтобы не было вырвано из контекста: http://aleksey.loginov.googlepages.com/index.html
NB>стандартные функторы (plus,bind1st,equal,...) заменяет прекрасно.
NB>при отсутствии нормальной лямбды, увеличивает читаемость в разы.
NB>например, удаление дублирующихся пробелов:
NB>

NB>unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );
NB>

Лямбда получилась хорошая, на самом деле. Не ожидал, что будет выглядеть настолько хорошо. Но все равно.

Чем это радикально лучше вот этого:

bool my_fun( char x, char y ) { return x == y && y == ' '; }

...
unique(str.begin(),str.end(), my_fun );
...

Этот вариант, в отличии от твоего, не вызовет у нового человека взрыва мозга, он его поймет сходу. Т.е. время на понимание кода новым человеком будет меньше на порядок, при этом, я добавил всего одну строку кода по сравнению с твоим вариантом. Учитывая это и общее незначительное количество употреблений лямбд в прикладном коде — какой смысл применять твою лямбду?

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

NB>>например, удаление дублирующихся пробелов:
NB>>

NB>>unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );
NB>>

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

G>Чем это радикально лучше вот этого:
G>

G>bool my_fun( char x, char y ) { return x == y && y == ' '; }

G>...
G>unique(str.begin(),str.end(), my_fun );
G>...
G>

ну, например, в с++ нет вложеных функций.
саппорту придется, как ты верно заметил, возвращаться и искать, что-же такое my_fun.
можно через функтор, но это уже будет не одна строчка.

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

а в твоем мозгу произошел большой взрыв, чтобы понять написанное?

G>Учитывая это и общее незначительное количество употреблений лямбд в прикладном коде — какой смысл применять твою лямбду?

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

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

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

NB>можно через функтор, но это уже будет не одна строчка.
Через функтор реально нужно тогда, когда у тебя должно быть состояние в функции, или надо зафиксировать ей некоторые параметры. Функторы у нас симулируют замыкания. Здесь не тот случай.

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

NB>а в твоем мозгу произошел большой взрыв, чтобы понять написанное?

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

Тем более я предпочту сделать так, если мне нужно в ограниченное время привернуть новую фичу в твоем коде — я вместо разбирательств с твоей лямбдой просто за минуту добавлю новую функцию, почти не проиграв в читабельности.

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

Ну, скажем так — поводов применять лямбды в реальных проектах на С++ вообще не очень много, если сравнивать с ФЯ. Учитывая, что лямд получается сравнительно мало — совокупный эффект от твоей красивой лямбды невелик. Особенно учитывая нюансы из реальной жизни, что я написал выше.

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

NB>>а в твоем мозгу произошел большой взрыв, чтобы понять написанное?

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

а зачем саппорту понимать как реализована библиотека? ему нужно понимать, что она делает.
расширить список в стандартных операторов в с++ врядли удастся.
добавление именнованого оператора старался сделать максимально комфортным:

struct Pair : lambda::Lambda<Pair>
{
    template<typename First, typename Second>
    struct sig : std::binary_function < First, Second, std::pair<First,Second> > {};

    template<typename First, typename Second>
    typename sig<First,Second>::result_type operator () ( First & x, Second & y ) const {
        return std::make_pair (x,y);
    }

} const pair = Pair ();

согласен, новый человек без чтения документации такое врядли напишет

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

G>Тем более я предпочту сделать так, если мне нужно в ограниченное время привернуть новую фичу в твоем коде — я вместо разбирательств с твоей лямбдой просто за минуту добавлю новую функцию, почти не проиграв в читабельности.

наличие какой-то возможности не принуждает тебя эту возможность использовать.
однако твоя позиция мне понятна.
возможно ты прав.

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

NB>>

NB>>unique(str.begin(),str.end(), fun(x,y) [ x==y && y==' ' ] );
NB>>

G>Чем это радикально лучше вот этого:
G>

G>bool my_fun( char x, char y ) { return x == y && y == ' '; }

G>...
G>unique(str.begin(),str.end(), my_fun );
G>...
G>

Мне кажется, что чем больше расстояние между строкой

bool my_fun( char x, char y ) { return x == y && y == ' '; }

и строкой

unique(str.begin(),str.end(), my_fun );

тем хуже это будет читаться.

G>Этот вариант, в отличии от твоего, не вызовет у нового человека взрыва мозга, он его поймет сходу. Т.е. время на понимание кода новым человеком будет меньше на порядок, при этом, я добавил всего одну строку кода по сравнению с твоим вариантом. Учитывая это и общее незначительное количество употреблений лямбд в прикладном коде — какой смысл применять твою лямбду?

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

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

K>Мне кажется, что чем больше расстояние между строкой
K>

K>bool my_fun( char x, char y ) { return x == y && y == ' '; }
K>

K>и строкой
K>

K>unique(str.begin(),str.end(), my_fun );
K>

K>тем хуже это будет читаться.

Это так. На самом деле расстояние не особо важно — все равно определение такой функции ищется поиском. И это сделать существенно проще, чем разбираться с устройством лямбды или добавлять в лямбду свои операторы — тут даже и говорить не о чем. Код с функцией поймет с ходу любой человек, знакомый на С++ на среднем уровне. Что не скажешь про "лямбду".

G>>Этот вариант, в отличии от твоего, не вызовет у нового человека взрыва мозга, он его поймет сходу. Т.е. время на понимание кода новым человеком будет меньше на порядок, при этом, я добавил всего одну строку кода по сравнению с твоим вариантом. Учитывая это и общее незначительное количество употреблений лямбд в прикладном коде — какой смысл применять твою лямбду?

K>Все-таки сложность несколько преувеличена.
Преувеличена? Знаешь, когда на мне висит дефект или suggestion первого приоритета, мне типа делать больше нефиг, как разбираться с реализацией "простой" лямбды, из-за того, что кому-то было лень лишнюю строку кода добавить, или казалось, что "так некрасиво".

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

Да не будет она часто встречаться. Как только встанет необходимость внутри дурацкой "лямбды" сделать что-нибудь нетривиальное, кроме x==y, любой вменяемый разработчик выкинет ее к чертям собачьим и заменит функцией — и все сделает за 1 минуту.

K>Но с тем, что в нормальном языке такие вещи должны быть я полностью согласен.
О чем и речь. Вопрос — нафига нам макросы в нормальном языке? Почему они бывают популярны в ненормальном — понятно, люди пытаются править эти ненормальности. Да и то, нафиг-нафиг. Лучше уж ненормальный язык, но знакомый и предсказуемый, чем "исправленый" макросами.

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


G>Чем это радикально лучше вот этого:
G>

G>bool my_fun( char x, char y ) { return x == y && y == ' '; }

G>...
G>unique(str.begin(),str.end(), my_fun );
G>...
G>

Слава Создателю, сотворившее всё ненужное трудным и всё трудное ненужным.

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

G>На самом деле расстояние не особо важно — все равно определение такой функции ищется поиском.

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

G>И это сделать существенно проще, чем разбираться с устройством лямбды или добавлять в лямбду свои операторы — тут даже и говорить не о чем. Код с функцией поймет с ходу любой человек, знакомый на С++ на среднем уровне. Что не скажешь про "лямбду".

Вот вот. Но проблема тут не в лямбде, а в том, что это никакая не лямбда на самом деле. И проблем будет больше даже не у того, кто первый раз увидит "лямбду", а у того, кто лямбду уже видел и будет думать что от такой "лямбды" можно ожидать того же, что от лямбды нормальной. Если такой человек что-то попытается сделать, руководствуясь этим убеждением, то немедленно ударится лбом о притолоку. Но это ситуация фантастическая, так как того, что лямбда в C++ будет работать как надо, наверное никто и не ждет. Первая же мысль будет о том, в чем же тут подвох? А потом придется копаться во внутренностях "лямбды".
Тоесть сама мысль о том, что расширение будет работать как надо — чистое безумие. И не потому, что расширение может быть глючным, а потому, что оно полноценным быть не может в принципе. И никем на практике не рассматривается как повышение уровня абстракции, но только как присыпаный листьями взведенный капкан, который оставлен вам в подарок добрыми людьми.
Понятно, что такие расширения не нужны. Правда, понятно не всем.

Вобщем, рассуждения о вреде макросов на примере C++, который вообще заставляет мыслить в параноидальном ключе это, может и увлекательно, но довольно странно. Хотябы потому, что никаких макросов в C++ нет.

G>Вопрос — нафига нам макросы в нормальном языке? Почему они бывают популярны в ненормальном — понятно, люди пытаются править эти ненормальности. Да и то, нафиг-нафиг. Лучше уж ненормальный язык, но знакомый и предсказуемый, чем "исправленый" макросами.

Во-первых, я разделю макросы и синтаксические расширения. Синтаксические расширения — опасная штука, тут я с Вами полностью согласен, применять их повсеместно неразумно. Тем не менее даже и они в нормальном языке могут пригодиться. Для написания стандартных расширений. Всякие using-и, foreach-и и тем более yield-ы в С# генерируют код, вот только посмотреть тут же, на месте, какой код они сгенерируют нельзя. Разве только декомпилировать, но это не совсем то. А кодогенератор вообще никак не посмотреть. Это уже минус, хотя человек, который не знает, что может быть по другому, об этом жалеть не будет. Если же расширения реализованы на синтаксических макросах, то такая информация доступна.

Теперь, для чего нормальному языку макросы, которые не меняют синтаксис. Для решения тех задач, которые сейчас решают кодогенераторами, я полагаю. Чем кодогенератор, который может быть недоступен и куча нагенеренного им кода лучше, чем макросы в данном случае?
Или чем лучше выделение паттерна проектирования в коде, а перед тем его реализация, чем простая декларация?
В чем принципиальная разница таких макросов и других параметрических типов? Тип может быть параметризован другим типом или веткой AST. Или любые параметрические типы — это одни проблемы?
Вобщем, Ваши доводы против макросов изменяющих синтаксис понятны. А каковы доводы против макросов, синтаксис не меняющих?

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

K>Теперь, для чего нормальному языку макросы, которые не меняют синтаксис. Для решения тех задач, которые сейчас решают кодогенераторами, я полагаю. Чем кодогенератор, который может быть недоступен и куча нагенеренного им кода лучше, чем макросы в данном случае?
K>Или чем лучше выделение паттерна проектирования в коде, а перед тем его реализация, чем простая декларация?
Давайте перейдем к конкретным примерам, и все станет ясно. Предлагайте пример, где помогают макросы, обсудим.

Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка и слабости системы типов. Большое количество паттернов, которые надо знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь — исключительно для примера — эрланг, как видим, так и пишем, например так:

Облегчим себе жизнь в одну строку:
switch( { State, Data }, Transition ) -> State( Transition, Data ).

И поехали описывать автомат:

state1( { ivegotevent1, EventData }, StateData ) -> ... { stateN, NewData }
state1( { ivegotevent2, EventData }, StateData ) ->

и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

K>В чем принципиальная разница таких макросов и других параметрических типов? Тип может быть параметризован другим типом или веткой AST. Или любые параметрические типы — это одни проблемы?

Нет, почему же, параметрические типы это хорошо. Я пожалуй попрошу вас показать, чем он отличается от макроса, а то я не вполне понимаю, о чем речь. Ну, и что такое "тип, параметризованный веткой AST", тоже непонятно.

Gaperton wrote:
> Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка
> и слабости системы типов.
НЕТ! Паттерн — это конкретный прием программирования.

> Большое количество паттернов, которые надо
> знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по
> грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь —
> исключительно для примера — эрланг, как видим, так и пишем, например так:
И что? В Эрланге паттерн "конечный автомат" просто вмонтирован в
сам язык.

Точно так же, в С можно сделать паттерн "наследование", а в С++ он уже
вмонтирован.

> и так далее. Вопрос: куда девался навороченный паттерн с double
> dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь
> макросы?
Он просто реализуется по-другому.

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

Хорошо пишеш.
Напиши еще чтонибудь...
Если можно — на заказ. Хочу прочитать про "Резкое падение популярности .NET. Кто виноват и что делать. Тематический обзор, интервью и аналитика с диаграммами и картинками." Обещаю поставить 3 раза по х3 там где пальцем покажеш.

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

C>Gaperton wrote:
>> Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка
>> и слабости системы типов.
C>НЕТ! Паттерн — это конкретный прием программирования.

Вопрос точки зрения. Я считаю что ДА. А дальше свой тезис иллюстрирую примером. А вы?

>> Большое количество паттернов, которые надо
>> знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по
>> грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь —
>> исключительно для примера — эрланг, как видим, так и пишем, например так:
C>И что? В Эрланге паттерн "конечный автомат" просто вмонтирован в
C>сам язык.

Да вы что . А "квиксорт" туда нне "вмонирован" — ведь там квиксорт записывается в 4 строки ? Может, туда вмонтированы все алгоритмы на деревьях? И вообще — черт знает что туда вмонтировано, но

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

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

C>Точно так же, в С можно сделать паттерн "наследование", а в С++ он уже
C>вмонтирован.

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

>> и так далее. Вопрос: куда девался навороченный паттерн с double
>> dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь
>> макросы?
C>Он просто реализуется по-другому.
Вот именно. По другому.

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

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

E>>Все, что вы так цените в Nemerle у меня в распоряжении уже было два года назад -- Ruby.

Д>Нет там ничего подобного. Мануал ты читал или по диагонали, или просто ничего в нем не понял.
Д>Может быть, тебе просто не хочется признаться даже самому себе, что ты потратил время и силы на Руби зря?

Я уже показывал (Re[5]: Питон наступает :)

Автор: FR
Дата: 23.07.06

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

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


G>Кстати, знаете, что такое "паттерн"? Это типовая обходка кривизны языка и слабости системы типов. Большое количество паттернов, которые надо знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь — исключительно для примера — эрланг, как видим, так и пишем, например так:

G>Облегчим себе жизнь в одну строку:
G>switch( { State, Data }, Transition ) -> State( Transition, Data ).

G>И поехали описывать автомат:

G>state1( { ivegotevent1, EventData }, StateData ) -> ... { stateN, NewData }
G>state1( { ivegotevent2, EventData }, StateData ) ->

G>и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

Возможно не самый известный факт, но pattern matching в переписывающих языках вообще и в функциональных в частности реализуется обычно именно через конечный автомат. Не совсем обычный правда, а для т.н. Tree Languages, но тем не менее.
В этом вообще говоря очень много смысла — связь между автоматами и логикой (особенно переписывающей, включая лямбда-исчисление) — это очень важная часть современного CS.

То есть этот пример — скорее пример использования уже готового автомата
Что, впрочем, ни на секунду не уменьшает его полезности: автоматы — штуки, неисчерпаемые как электрон и жизнь облегчают постоянно и везде.
А вот программировать их на ОО-языках — это одно мучение, да. Я вот именно сейчас как раз занимаюсь тем, что пытаюсь сделать дизайн такого автомата на Java. На чистом Си было бы легче.

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

Умно говоришь.

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

G>и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?
На немерле это пишется примерно также и без единого макроса.

variant State
{
    | State1 { i : int; }
    | State2 { s : string; }
}
variant Event
{
    | Event1 { f : float; }
    | Event2 { l : list[string]; }
}
def fsm(_ : State, _ : Event) : State
{
| (State1 as s, Event1 as e) => State.State2("ads");
| (State2 as s, Event1 as e) => State.State1(123);
...
}

А макросы это тяжолое оружие которое как правило стоит и пылится. Но вот если оно понадобится, а его нет то все. Тушите свет. Я однажды нарвался на такую задачку Пришлось копипастить.

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

K>>Теперь, для чего нормальному языку макросы, которые не меняют синтаксис. Для решения тех задач, которые сейчас решают кодогенераторами, я полагаю. Чем кодогенератор, который может быть недоступен и куча нагенеренного им кода лучше, чем макросы в данном случае?
K>>Или чем лучше выделение паттерна проектирования в коде, а перед тем его реализация, чем простая декларация?
G>Давайте перейдем к конкретным примерам, и все станет ясно.

Вообще-то мы говорим не о какой-то конкретной ситуации, чтобы решить нужны для данного конкретного случая макросы или нет, а обсуждаем такое вот Ваше утверждение:

Вопрос — нафига нам макросы в нормальном языке? Почему они бывают популярны в ненормальном — понятно, люди пытаются править эти ненормальности. Да и то, нафиг-нафиг. Лучше уж ненормальный язык, но знакомый и предсказуемый, чем "исправленый" макросами.

Достаточно общее утверждение, не так ли? По второй части я с Вами согласен. В ненормальном языке с убогими макросами как не старайся исправить — получится накошмарить только еще больше. Казалось бы — это интуитивно понятно, однако и это не так.

Вот только какой язык считать нормальным?

G>Предлагайте пример, где помогают макросы, обсудим.

Пример привести легко. Генерация кода сериализации в compile time. Но, как я сказал выше, это к делу не относится.
Что характерно, привести примеры пагубного влияния изменения синтаксиса на maintainability для Вас большого труда не составило, однако с макросами, не меняющими синтаксис вышла заминка.

G>Кстати, знаете, что такое "паттерн"?

Возможно.

G>Это типовая обходка кривизны языка и слабости системы типов.

В некоторых случаях так и есть, но далеко не во всех.

G>Большое количество паттернов, которые надо знать — симптом. Давайте, я приведу пример. Конечный автомат. Делаем по грамотному, по ООП-шному, в С++. Представили себе паттерн? А теперь — исключительно для примера — эрланг, как видим, так и пишем, например так:
G>Облегчим себе жизнь в одну строку:

switch( { State, Data }, Transition ) -> State( Transition, Data ).

G>И поехали описывать автомат:

state1( { ivegotevent1, EventData }, StateData ) -> ... { stateN, NewData }
state1( { ivegotevent2, EventData }, StateData ) ->

G>и так далее. Вопрос: куда девался навороченный паттерн с double dispatch, абстрактными классами, и прочим дерьмом? И второй: Где здесь макросы?

Пример, по-моему, не очень удачный. FSM как раз к разряду костылей не относится. Ответ: Паттерн никуда не девался. Просто он реализован не "по грамотному, по ООП-шному, в С++", а с помощью pattern matching (впрочем, я Erlang не знаю, могу и ошибаться) и, что вополне естественно, выглядит значительно элегантнее.

Возвращаясь к нормальному языку. Что Вы под словом "нормальный" подразумеваете можно вывести разве только из того самого утверждения.
Я вижу три варианта
1) Это язык в котором и так все есть. Поэтому макросы не нужны. Я даже не знаю, страшно это или смешно. Наверное и то и другое. Но, к счастью, это не возможно.
2) Это язык в котором есть все, что надо, а если чего-то нет, то вам этого и не надо. Подход знакомый, хорошо опробованный, но не без недостаков. В частности, всегда выясняется, что тот, кто принимал решения что нам всем нужно ошибался.
3) Это язык, в котором можно сделать (почти)все что нужно, но без всяких макросов. Мне не особо нравится. Макросы одним своим существованием хоть как-то выделяют "рискованное" подмножество возможностей, чего от таких "нормальных" языков ожидать не приходится.

Видимо, подразумевается второй вариант, а в качестве примера нормального языка, как я понял, Erlang, в котором пару дыр заделать

Автор: Gaperton
Дата: 18.08.06

и все будет хорошо.

K>>В чем принципиальная разница таких макросов и других параметрических типов? Тип может быть параметризован другим типом или веткой AST. Или любые параметрические типы — это одни проблемы?
G>Нет, почему же, параметрические типы это хорошо. Я пожалуй попрошу вас показать, чем он отличается от макроса, а то я не вполне понимаю, о чем речь. Ну, и что такое "тип, параметризованный веткой AST", тоже непонятно.

Ну пусть лучше будет — выражением. Это так, на правах бреда, близко к сердцу не принимайте.
В принципе, параметрических тип это что-то вроде

Type -> Type

Что касается макросов, то тут могут быть варианты. Для начала тот же, что и у параметрических типов.
А также такой вариант:

Expr -> Expr

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

Expr*Type -> Type

Здесь тоже все в порядке.
Но есть вариант и не такой безоблачный.
Можно одним макросом сгенерировать и выражение в точке вызова макроса и типы в контексте класса, а может и пространства имен.
Это не очень очевидно, но не в большей степени чем рантайм функция с побочным эффектом.