Являются ли макросы свидетельством недостаточной выразительн - Философия программирования

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

L>"ab" | "aa"

L>Будет ли ошибка при компляции макроса?

А с чего это она должна быть? Даже в случае:

AA = "aa"
AB = "ab"

Не будет неоднозначности. А неоднозначности вида:

subst Letter = U_Ll | U_Lu | U_Lt | U_Lm | U_Lo;
Identifier = Letter+;
DoKeyword = "do";
IfKeyword = "if";
...

решает в пользу последних правил.

L>Насчёт смешивания — это ещё вопрос, хорошо это или плохо. Хотя для лексера может особого смысла и нет.
L>Но я бы не отказался определять правила не только с помощью жёстко забитых значков.

А с помощью чего ещё?

... << RSDN@Home 1.2.0 alpha rev. 672>>

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

K>А с чего это она должна быть?

А. Я так Влада понял, что у тебя это определяется.

L>>Насчёт смешивания — это ещё вопрос, хорошо это или плохо. Хотя для лексера может особого смысла и нет.
L>>Но я бы не отказался определять правила не только с помощью жёстко забитых значков.

K>А с помощью чего ещё?

Комбинаторов, которые можешь задавать сам.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>>Короче, макросы и раные там навороченные шаблоны конечно крутая штука для шифрования исходного кода и чесания левой пяткой за правым ухом, только на практике не нужная. Думаете, почему в большинстве современных языков нет макросов? В 70-х годах вот были популярны развитые макросистемы. Сейчас — нет, потому что нафиг не нужны. Рынок, так сказать, голосует.
WH>Наверное я программы писать не умею... ибо мне постоянно попадаются задачки которые без кодогенератора не решить...

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

WH>вот буквально недавно написал кодогенератор который парсит ~12К кода и генерит еще ~70К (из которых примерно 44К вызовы сишных макросов те в конце концов кода получается еще больше).
WH>Внутри есть алгоритм со сложностью O(N^4)... На данный момент N == 19 но будет рости по ходу добавления функциональности.
WH>И делать ручками то для чего нужен алгоритм четвертой степени при малейших изменениях исходных деклараций мне мягко говоря не хочется. Особенно при том что машина это делает за доли секунды и без ошибок.

У тебя сложность кодогенератора О(N^4)? Ужас какой. Ну так давай пример в студию, посмотрим на этого зверя

. В смысле — задачу опиши.

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

K>>А с чего это она должна быть?

L>А. Я так Влада понял, что у тебя это определяется.

А как вообще может нормальный генератор такого не определять?

K>>А с помощью чего ещё?

L>Комбинаторов, которые можешь задавать сам.

А смысл? Можно пример, когда это удобно?

... << RSDN@Home 1.2.0 alpha rev. 672>>

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

K>А как вообще может нормальный генератор такого не определять?

В смысле? Не понял, так ты на стадии компиляции это бракуешь?

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

Modifiers      := "public" | "private" | "protected";
Method         := Modifiers ident "(" [ ident (", " ident)* ] ")" "{" ... "}"
AbstractMethod := Modifiers ident "(" [ ident (", " ident)* ] ")" ";"

Или у тебя парсер всегда LL(k)? Если да, то это вроде как неэффективно.

L>>Комбинаторов, которые можешь задавать сам.

K>А смысл? Можно пример, когда это удобно?

Ну как же. Сокращение дублирования, как всегда. В моём примере, например, есть комбинатор commaSep, применяемый к правилу и означающий, что это правило повторяется N раз, разделяясь запятыми, простые комбинаторы типа brackets, означающее, что правило, к которому оно применяется ищется между скобками и т.д.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

L>В смысле? Не понял, так ты на стадии компиляции это бракуешь?

Имеется в виду Error handling?

L>Вот пример Влада. Я так понял, что парсер должен здесь обеспечивать "внятную диагностику грамматических ошибок".

L>

L>Modifiers      := "public" | "private" | "protected";
L>Method         := Modifiers ident "(" [ ident (", " ident)* ] ")" "{" ... "}"
L>AbstractMethod := Modifiers ident "(" [ ident (", " ident)* ] ")" ";"
L>

L>Или у тебя парсер всегда LL(k)? Если да, то это вроде как неэффективно.

Конечно, нет. Парсер — всегда LALR(1). Но на вход ему поступают лексемы а не символы.

K>>А смысл? Можно пример, когда это удобно?

L>Ну как же. Сокращение дублирования, как всегда. В моём примере, например, есть комбинатор commaSep, применяемый к правилу и означающий, что это правило повторяется N раз, разделяясь запятыми, простые комбинаторы типа brackets, означающее, что правило, к которому оно применяется ищется между скобками и т.д.

Возможно, это будет реализовано в будущем.

... << RSDN@Home 1.2.0 alpha rev. 672>>

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

K>Имеется в виду Error handling?

Да нет, я тоже сначала про это думал. В общем, то имелось в виду именно LL(k)
Проехали.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

G>Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...

Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

G>>Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...

IT>Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.

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

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

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

VD>>>>Тебе не кажется, что "очень близок" на практике означет "непохож"?

L>>>Нет.

VD>>Ну, тогда я тебе отрою тайну — это так.

L>Ложь.

VD>>И... не надо использовать для решения задач плохо подходящие для них средства. Нужен новый синтаксис? Так и нефига заниматься пуританством. Макросы видите ли бяка... надо найти другой способ. Макрос — это самый прямой способ. Другие дают сложные, неуклюжие и медленные решения.

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

L>С кем ты разговариваешь?

Со множественным лицом, которое ненавидит макросы, конечно

. Он думает, ты из клана "makroz haters"

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

IT>>Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.

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

Перформанс, конечно, тоже. Как же без этого? В частности для обхода тормозов рефлекшина. Но это действительно не самое интересное.

Гораздо более интересный пример можно найти здесь. Общая идея состоит в том, что для выполнения наиболее "интеллектуальной" работы достаточно описать сигнатуру метода:

public List<Customer> GetCustomerListByName(string @firstName, string @lastName);

Далее начинается в чистом виде monkey's job. В моём случае в качестве обезъянки выступает генератор, которому это с одной стороны не надоедает, с другой он не ошибается.

В дополнение к этому, я могу одним движением закешировать вызов этого метода:

[Cache(MaxMinutes = 10)]
public List<Customer> GetCustomerListByName(string @firstName, string @lastName);

и залогировать:

[Log, Cache(MaxMinutes = 10)]
public List<Customer> GetCustomerListByName(string @firstName, string @lastName);

Аспекты тоже будут догенертрованы в метод.

Ещё одно частое применение:

public abstract class Customer : EditableObject
{
    public abstract string FirstName { get; set; }
    public abstract string LastName  { get; set; }
}

Подробности здесь. Этот вопрос я задавал немерлистам, гыгыгы, миллион сообщений назад. Кстати, похожая проблема возникает при использовании WPF.

Есть и другие случаи применения кодогенерации, но они скорее относятся к экзотическим. Здесь я перечислил лишь то, что используется повседневно.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

G>Действительно странно. Вроде как все языки программирования у нас тьюринг-полные. Я вот ни разу такой задаси не встречал. Может, поделишься задачкой, наконец? А то все говорите, говорите...
Да запросто.
Если раскажешь как решить без кодогенерации будет очень интересно послушать.
Долбить генерируемый код ручками не предлогать.

G>У тебя сложность кодогенератора О(N^4)? Ужас какой.
Алгоритм Флойда — Уоршела О(N^3) если нужны только растояния. Мне же нужны сами пути. И если я не разучился считать то изменения которые запоминают пути делают алгоритм О(N^4).

G>Ну так давай пример в студию, посмотрим на этого зверя

. В смысле — задачу опиши.
Есть библиотека обработки изображений (данная область представляет собой весьма мутную и плохо изученую магию).
По ходу изучения и эксперементов выяснилось что разные фильтры нужно делать в разных цветовых пространствах.
На данный момент у меня получилось 19. Откуда они взялись не спрашивай. Очень долго объяснять. Просто поверь что надо. Я долго пытался обойтись одним но у меня не получилось.
Так вот для каждого пространства нужно описать свой тип. Описание занимает строк 40-50 при том что они все шаблонные и их разлячия легко укладываются в одну строку.
Писать это руками мне очень быстро надоело. Сейчас данное описание у меня генерируется.
Не смотря на то что структура у некоторых из них одинаковая их необходимо различать на этапе компиляции ибо если не дай бог их перепутать то потом будешь очень долго искать почему картинки получаются с кучей малозаметных артефактов.
Но это не главная засада.
Проблема в том что мне в любой момент может понадобится преобразовать из одного цветового пространства в другое.
И писать N^2 преобразований мне мягко говоря не хочется.
Тем болие что большинство из них сводятся к преобразованию через цепочку пространств.
Вот я и задал основные преобразования, назначил им веса и остальное сгенерил.
Дописывать преобразования по мере необходимости не вариант. Ибо не смотря на то что битмап у меня шаблон таскаю я его через полиморфную базу иначе будет несколько усиливающих друг друга комбинатроных взрыва, а мне и одного хватает... Хотя благодоря кодогенератору он меня не сильно парит.

... << RSDN@Home 1.2.0 alpha rev. 673>>

WH>Так вот для каждого пространства нужно описать свой тип. Описание занимает строк 40-50 при том что они все шаблонные и их разлячия легко укладываются в одну строку.
WH>Писать это руками мне очень быстро надоело. Сейчас данное описание у меня генерируется.
WH>Не смотря на то что структура у некоторых из них одинаковая их необходимо различать на этапе компиляции ибо если не дай бог их перепутать то потом будешь очень долго искать почему картинки получаются с кучей малозаметных артефактов.
WH>Но это не главная засада.
WH>Проблема в том что мне в любой момент может понадобится преобразовать из одного цветового пространства в другое.
WH>И писать N^2 преобразований мне мягко говоря не хочется.
WH>Тем болие что большинство из них сводятся к преобразованию через цепочку пространств.
WH>Вот я и задал основные преобразования, назначил им веса и остальное сгенерил.

а темплейты не подойдут? язык-то хоть C++?

у меня в одной программе 48 вариантов кода генерятся именно на шаблонах. вот небольшой кусочек кодогенератора:

// tor_compress template parameterized by MatchFinder and Coder
template <class MatchFinder, class Coder>
int tor_compress4 (PackMethod m, INOUT_FUNC *read_f, INOUT_FUNC *write_f)
{
    switch (m.match_parser) {
    case GREEDY: return tor_compress <             MatchFinder,  Coder> (m, read_f, write_f);
    case LAZY:   return tor_compress <LazyMatching<MatchFinder>, Coder> (m, read_f, write_f);
    }
}

// tor_compress template parameterized by MatchFinder and Coder
template <class MatchFinder, class Coder>
int tor_compress3 (PackMethod m, INOUT_FUNC *read_f, INOUT_FUNC *write_f)
{
    switch (m.hash3log) {
    case 0:  return tor_compress4 <      MatchFinder,  Coder> (m, read_f, write_f);
    default: return tor_compress4 <Hash3<MatchFinder>, Coder> (m, read_f, write_f);
    }
}

// tor_compress template parameterized by Coder
template <class Coder>
int tor_compress2 (PackMethod m, INOUT_FUNC *read_f, INOUT_FUNC *write_f)
{
    switch (m.hash_row_width) {
    case 1:    return tor_compress3 <MatchFinder1, Coder> (m, read_f, write_f);
    case 2:    return tor_compress3 <MatchFinder2, Coder> (m, read_f, write_f);
    default:   return tor_compress3 <MatchFinderN, Coder> (m, read_f, write_f);
    }
}

BZ>у меня в одной программе 48 вариантов кода генерятся именно на шаблонах. вот небольшой кусочек кодогенератора:

наверно, я не совсем ясно написал: приведённый кусок генерит 2*2*3=12 вариантов кода, плюс ещё одна функция с 4-мя вариантами выбора Coder — вот и выходят 48 вариантов. при этом MatchFinder в приведённом примере определяется многократным применением шаблонов, трансформирующих один из базовых MatchFinder — вот и получается, что комбинаторная сложность достигается линейным размером кода

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

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

BZ>язык-то хоть C++?
Да.

BZ>у меня в одной программе 48 вариантов кода генерятся именно на шаблонах. вот небольшой кусочек кодогенератора:
Я так тоже умею.
Но в данной задаче не получилось.
Ибо O(N^4) для шаблонов С++ смерть.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

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

IT>>>Хочешь я поделюсь? Последние года четыре у меня без кодогенерации не обходится ни одни проект. А ты оценишь и скажешь нужно это или нет.

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

IT>Перформанс, конечно, тоже. Как же без этого? В частности для обхода тормозов рефлекшина. Но это действительно не самое интересное.

IT>Гораздо более интересный пример можно найти здесь. Общая идея состоит в том, что для выполнения наиболее "интеллектуальной" работы достаточно описать сигнатуру метода:

IT>Есть и другие случаи применения кодогенерации, но они скорее относятся к экзотическим. Здесь я перечислил лишь то, что используется повседневно.

Ок, случай генерации связующего кода с БД — это хороший пример. Однако, хочу дать пару комментариев.

1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций. Применение их изолировано, и локализовано. Поэтому, моя аргументация к атрибутам не относится — кастомные атрибуты являются доброй, хорошей магией. От нее вреда практически нет. По своим свойствам, влияющим на процесс разработки и поддержки — это совсем не то же самое, что злые макросы. Это безопасная штука, и мы всеми руками голосуем за кастомные атрибуты. Впрочем, добавлять их кому попало все равно надо запретить, и любую модификацию прогонять через процесс формальных инспекций с привлечением тимлидов и ведущих спецов как инспекторов, как в той ветке в управлении проектами написано — ты ее читал. Плюс, требовать адекватной документации по атрибутам — и ее тоже инспектировать.

2) Удобный биндинг к БД — это даже более ходовая и популярная задача, чем создание парсеров. И для ее решения, так же как ex/yacc, вполне оправдано сделать внешний макропроцессор, совсем не обязательно иметь поддержку макросов в языке. Насколько я понимаю, в твоем тулките, на который ты ссылаешься, так и сделано — макросисиема там не применяется. Этой же цели, кажется, служит явский hybernate? Опять, обошлись без макросистемы. Что имеем в сухом остатке? Индустрия подверждает мой тезис о макросах, не так ли?

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

WH>Но это не главная засада.
WH>Проблема в том что мне в любой момент может понадобится преобразовать из одного цветового пространства в другое.
WH>И писать N^2 преобразований мне мягко говоря не хочется.
WH>Тем болие что большинство из них сводятся к преобразованию через цепочку пространств.
WH>Вот я и задал основные преобразования, назначил им веса и остальное сгенерил.

Насколько я не разбираюсь в обработке изображений, преобразование из одного цветового пространства в другое сводится к простому линейному преобразованию в 3 или 4-х мерном пространстве. у = Ах. По крайней мере для RGB <-> YCrCb это так.

Если все преобразования являются линейными операторами, их композиция делается тривиально. Надо матрицы перемножить. Нет?

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

G>Если все преобразования являются линейными операторами, их композиция делается тривиально. Надо матрицы перемножить. Нет?
Нет. Есть не линейные преобразования. Например возведение в степень 2.2 и обратно.

... << RSDN@Home 1.2.0 alpha rev. 673>>

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

G>1) У тебя там применяются атрибуты. Добавление кастомных атрибутов никак не меняет синтаксис языка, и не увеличивает indirection level языковых конструкций.

В этом смысле да. Но в том же немерле синтаксис атрибутов является лишь одним из форм макросов.

Что касается синтаксических конструкций... честно говоря, я пытаюсь понять почему вы считаете это плохой практикой и пока никак не могу понять

Почему, например, расширение linq захардкоженное, прибитое гвоздями к C# и VB это хорошо, а набор макросов, делающий тоже самое — это плохо. Почему printf("%d %s", a), убивающий программу или string.Format("{0} {1}", a), приводящий к run-time exception — это хорошо, а $"$a", где просто нет шансов на ошибку — это плохо.

G>2) Удобный биндинг к БД — это даже более ходовая и популярная задача, чем создание парсеров. И для ее решения, так же как ex/yacc, вполне оправдано сделать внешний макропроцессор, совсем не обязательно иметь поддержку макросов в языке. Насколько я понимаю, в твоем тулките, на который ты ссылаешься, так и сделано — макросисиема там не применяется. Этой же цели, кажется, служит явский hybernate? Опять, обошлись без макросистемы. Что имеем в сухом остатке? Индустрия подверждает мой тезис о макросах, не так ли?

Индустрия банально не имеет макросов, поэтому извращается как может. Проблемы pre-compile и run-time кодогенерации хорошо известны и, к сожалению, неразрешимы. Я, например, в своё время поимел много гемороя с pre-compile-time генерацей код. Народ по незнаю правил такой код вручную и когда это всплывало через несколько месяцев, то наступал полный паралич. Перегенерация отменит исправления, а что сломает такое исправление никто уже не помнит. Хорошо, если компилятор матюгнётся, а так можно вообще пропустить отмену и словить потом проблемы где-нибудь у заказчика.

У run-time кодогенерации тоже есть свои козявки. Приходится использовать абстрактные классы, которые к тому же всегда должны быть публичные. Классы, которые не генерируются, но для которых что-то генерируется тоже должны обязательно быть публичными. Мелочь, а неприятно.

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

От:	lomeo	http://lomeo.livejournal.com/
Дата:	31.07.07 05:10
Оценка:

От:	konsoletyper	https://github.com/konsoletyper
Дата:	31.07.07 05:37
Оценка:

От:	lomeo	http://lomeo.livejournal.com/
Дата:	31.07.07 08:26
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	31.07.07 09:14
Оценка:	+3

От:	konsoletyper	https://github.com/konsoletyper
Дата:	31.07.07 12:06
Оценка:

От:	IT	linq2db.com
Дата:	01.08.07 16:06
Оценка:	33 (1) +2