Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>>>Предлагаю запенисометрировать.


L>>Не я. Времени катастрофически нет — сижу на твои посты отвечаю


VD>Как говорят млодые и подвинутые "слив засчитан"...


Молодые и продвинутые хотят, чтобы я тратил время на совершенно неинтересные мне вещи?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1 :)
Здравствуйте, VladD2, Вы писали:

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


L>>Нет.


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


Ложь.

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


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

С кем ты разговариваешь?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Ты о чём вообще? Мы говорили о конкретной задаче и как она решается.

L>>konsoletyper сказал, что не понимает устройство Parsec, я попытался дать основное, что в нём есть.
L>>При чём тут ассемблер и структурное программирование?

VD>При том, что сегодня ФВП полноцено не поддерживаются разве что в С++. И эти тирады несколько смешны.


Ты с кем разговариваешь? Какое ФВП и С++?

VD>>>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?


L>>И?


VD>И не надо нам сотый раз про это. Лучше бы дал прямой ответ на вопрос товарища. Мне вот тоже не ясно где там простота.


В сотый раз про что? Кому "вам"? Я отвечал на вопрос konsoletyper'а. Может быть ответил не то, что он спрашивал, но это судить ему. А ты на что отвечаешь? Причём тут макросы в апогее?
Мы говорим о парсеке. Мы даже уже не говорим, почему это вдруг он не написан на таких замечательных макросах — с этого начинался разговор, но он давно уже оттуда ушёл.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 08:54
Оценка: +1
Здравствуйте, VladD2, Вы писали:

L>>Макросы генерят код по поименованному определению макроса. Это имя используется в коде для вызова макроса компилером.


VD>Это ты домысливашь. Реально же макросы довольно гибкий инструмент и могут делать все что им угодно с кодом проекта (при этом в самом коде не присуствуя).


В чём именно я не прав? Что именно я домысливаю? Можешь выражаться яснее, а не отделываться общими фразами про то, что макросы это гибкий инструмент?

Насчёт "(при этом в самом коде не присуствуя)" — как? На уровне сборки? Там можно сразу находить нужные куски причём обработанные до этого другими макросами? Или придётся парсить весь код, чтобы выделить (map f (map g) xs)?

L>>Рулесы делают трансформацию без поименований с уже имеющимися функциями. Компилер находит шаблоны и меняет их.


VD>Но по сути же делается все тоже самое... Согласись...


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

Аналогия: множественное наследование и трейты, ссылки на функции и ФВП и т.д. Первое более мощное, чем второе, да. Почему тогда многие считают МН не очень удачным решением?

VD>Мы меняем код неочевидным для прикладного программиста образом. Все зло макросов, как я понимаю, приписывается именно этому свойству.


При отключенных рулесах код будет работать. При отключённых макросах — нет. В общем случае, разумеется.
Применение рулесов — это задание эквивалентных, но более эффективных выражений.

VD>Как-то странно, что изменение названия и способа запуска сразу превращет зло во благо. А?


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

L>>Допустим, x $ y z => x (y z) можно сделать макросом.

L>>А вот как сделать трансформацию map f . map g => map (f . g) макросом я не представляю.

VD>Если есть код перебора выражений (а он есть), то достаточно найти нужный паттерн и заменить его другим.


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

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


VD>Неубедительно.


В чём именно сомнения? Конкретнее претензии плиз.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 09:05
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Твои примеры на Парсеке не совместимы с ЕБНФ.


Меня не слышат, это минус.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[21]: Являются ли макросы свидетельством недостаточной выр
От: Константин Л. Франция  
Дата: 27.07.07 09:12
Оценка:
Здравствуйте, lomeo, Вы писали:

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


VD>>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


L>Да.


А че так запущено?
Re[22]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 09:37
Оценка:
Здравствуйте, Константин Л., Вы писали:

VD>>>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?


L>>Да.


КЛ>А че так запущено?


Делают Data.CompactString.
А так — просто в самом GHC изначально было плохо с юникодом. Есть различные библиотеки для работы с ним, но это всё не то, разумеется.

В Haskell-prime (следующий шаг после Haskell98) обещали.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 27.07.07 10:20
Оценка:
Здравствуйте, VladD2, Вы писали:

E>>Принципиальная схема реализации отложенных вычислений в C++ изложена у Страуструпа в 3-м издании "Язык программирования C++" (Б.Страуструп, Язык программирования C++, спец. изд./Пер.с англ. — М.;СПб.:"Издательство БИНОМ" — "Невский Диалект", 2001г. — 1099с., ил.) Раздел 22.4.7 "Временные массивы, копирование и циклы", стр.743.


E>>Без шаблонов и Буста.


VD>Осталось без трепа изобразить решение.


Задача

x := alpha * p + omega * s;

, изложенная Klapaucius вот здесь
Автор: Klapaucius
Дата: 09.07.07
может быть решена, например, так:

#include <iostream>
#include <vector>

typedef std::vector< float > vector_t;

class delayed_scalar_by_vector_multiply_t
    {
    public :
        delayed_scalar_by_vector_multiply_t(
            float a,
            const vector_t & b )
            :    a_( a )
            ,    b_( b )
            {}

        float scalar() const { return a_; }
        const vector_t & vector() const { return b_; }

    private :
        float a_;
        const vector_t & b_;
    };

delayed_scalar_by_vector_multiply_t
operator*(
    float a,
    const vector_t & b )
    {
        return delayed_scalar_by_vector_multiply_t( a, b );
    }

class delayed_sum_of_scalar_to_vector_multiply_t
    {
    public :
        delayed_sum_of_scalar_to_vector_multiply_t(
            const delayed_scalar_by_vector_multiply_t & a,
            const delayed_scalar_by_vector_multiply_t & b )
            :    a_( a )
            ,    b_( b )
            {}

        void calc_and_store_to( vector_t & receiver ) const
            {
                if( a_.vector().size() != b_.vector().size() )
                    throw std::invalid_argument( "vectors must have the same size" );

                receiver.clear();
                receiver.reserve( a_.vector().size() );

                for( unsigned int i = 0, i_max = a_.vector().size();
                        i != i_max;
                        ++i )
                    receiver.push_back(
                            a_.vector()[ i ] * a_.scalar() +
                            b_.vector()[ i ] * b_.scalar() );
            }

    private :
        delayed_scalar_by_vector_multiply_t a_;
        delayed_scalar_by_vector_multiply_t b_;
    };

delayed_sum_of_scalar_to_vector_multiply_t
operator+(
    const delayed_scalar_by_vector_multiply_t & a,
    const delayed_scalar_by_vector_multiply_t & b )
    {
        return delayed_sum_of_scalar_to_vector_multiply_t( a, b );
    }

vector_t &
operator<<(
    vector_t & receiver,
    const delayed_sum_of_scalar_to_vector_multiply_t & sum )
    {
        sum.calc_and_store_to( receiver );
        return receiver;
    }

std::ostream &
operator<<(
    std::ostream & to,
    const vector_t & v )
    {
        for( unsigned int i = 0, i_max = v.size(); i != i_max; ++i )
            {
                if( i )
                    to << " ";
                to << v[ i ];
            }
        return to;
    }

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

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

        c << 0.0 * a + 2.0 * b;

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


Оператор << используется вместо =, поскольку operator= должен быть нестатическим методом класса, а изменять стандартный std::vector нельзя.

Это демонстрация принципиальной схемы реализации отложенных вычислений в C++, полученная за 15 минут. Более сложные схемы могут быть получены при приложении несколько больших усилий. Только Nolite mittere margaeritas ante porcas!


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 11:48
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Если серьёзно, то я не понимаю — зачем это тебе. Вроде взрослый человек, а занимается ерундой.


Просто мы подходим к жизни по разному. Я конечно тоже хочу видить нечто красивое и изящьное, но рпи этом не отдаленное от реальной жизни. Так что самое изящное решение пойдет в топку если оно не эффективно. А уж если оно будет не очень изящно... Ну, а практика — критерий истины. Если будет одинаковый код на реальной задаче, то его можно будет сравнить как по быстродействию, так и по изаществу (да и по краткости). Без этого все наши разговоры будут пстыми словами приверженцев разных подходов. Можно конечно громко заявлять все что угодно, но это не более чем демагогия. Лично я уверен, что Хаскель не победит в подобном соревновании, так как в худшем (для его конкурентов) случае объем кода будет приблизительно таким же, а вот с понятностью (простым смертным) и быстродействием будут серьезные проблемы. Но это тоже пустые слова. Так как в Хаскеле я профан, то сам сделать подобные тесты не в состоянии (точнее не имею на это морального права).

L>Ну, потратишь ты моё и konsoletyper'а время (или только моё, а? может тогда пусть на входе небольшой хаскель проект будет, чтобы вам тоже не скучать . Узнаешь, что bytestring-парсек на 14.73% медленнее или наоборот быстрее, и что?!


Мне совершенно все равно как там работает bytestring. Но мне очень интересно сравнить Хаскель с его подходом к ДСЛ-естроению с Немерле на реальной (боевой, можнос сказать) задаче. А вот наши беседы мне становятся менее и менее интересны, и не потому, что я тебя не уважаю или стопроцентно уверен в своем мнении, а потому, что не несут рационального зерна. Это не более чем наши мнения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 11:48
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Т.е. DSL рассматриваются только в свете системы типов, остальные возможности языка выкидываем? Интересно...


Нет. Ты не верно понял. Речь шла о подходе в котором система типов задействуется как средсво компайлтайм-вычислений (базовый пример — С++).

К>А по поводу скалы, вот простенький пример отсюда :


К>

К> val res = db.executeStatement {
К> select fields ("name" of characterVarying(50)) from "person"
К> }


К>Подход, принятый тут (называемый авторами “zygotictype-directed growth”), описан здесь


ОК. Теперь давай глянем на более сложные примеры (по той же ссылке).
1:
 val query = (
      select fields ("first" of characterVarying(50)) 
        from "person" where ("last" in "person")=="'D.'"
    )
    val res1 = db.executeStatement {
      query
    }

    Console.print("Whose last name is simply 'D.'?")
    for(val i <- res1;
        val f <- i.fields) {
      Console.println(f.content.sqlString);
    }

Этот запрос в рантайме порождает следующий SQL:
SELECT first FROM person WHERE person.last = 'D.'

Что мы в нем видим?
А видим мы в нем:
1. Отсуствие проверок правильности запроса во время компиляции. Например, ("last" in "person") задает доступ к полю person.last в строковом виде. Понятно, что проверка правильностии имени поля и таблицы может быть произведена только во время исполнения. Причем в случае ошибки будет выдано не вполне внятное сообщение.
2. Доступ к полученым данным полям осуществляется через универсальную объектную систему (аля ADO.NET), что опять же приводит к тому, что в случае обращения к полям их прийдется идентифицировать по текстовым именам или индексам. Это так же переносит момент обнаружения ошибки в рантайм.
3. Код хотя и лучше чем прямое использовние JDBC\ADO.NET, но все же далек от совершенства.

Ну, а теперь сравним все это с тем как тоже самое можно было бы реализовать с помощью макросов http://nemerle.org/SQL_macros.
Вот как будет выглядеть тот же пример:
ExecuteReaderLoop("SELECT first FROM person WHERE person.last = 'D.'", db);
    WritwLine(first);

Не правда ли этот код выглядит луче?
Он еще и надежнее. И SQL и контроль типов параметров/полей осуществляется во время компиляции. Это гарантирует мгновенное обнаружение ошибок.

При этом, мы можем безболезненно использовать как списки полей, так и параметров. Например, можно заменить константный фильтр на фильтр берущийся из переменной:
def filterValue = ReadLine();
ExecuteReaderLoop("SELECT first FROM person WHERE person.last = filterValue", db);
    WritwLine(first);

При этом опять же будут контролироваться типы и если, скажем, person.last имеет не строковый тип, то во время компиляции нам об этом сообщит компилятор.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>При этом, мы можем безболезненно использовать как списки полей, так и параметров. Например, можно заменить константный фильтр на фильтр берущийся из переменной:

VD>
VD>def filterValue = ReadLine();
VD>ExecuteReaderLoop("SELECT first FROM person WHERE person.last = filterValue", db);
VD>    WritwLine(first);
VD>

Тысяча извинений... Параметр нужно пометить знаком доллара:VD>
def filterValue = ReadLine();
ExecuteReaderLoop("SELECT first FROM person WHERE person.last = $filterValue", db);
    WritwLine(first);
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, lomeo, Вы писали:

L>Ты кстати на вопросы не ответил.


Какой?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Являются ли макросы свидетельством недостаточной выра
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Я говорил не о замене метапрограммирования чем-то там, а о повседневной необходимости в нем. Разницу чувствуешь? Объясняю. Где-то придется для "паттерна" конечного автомата заводить макрос, чтоб красиво было. А кое-где — это совершенно обычная задача, не требующая ни выверта, ни паттерна. Смотри:


G>switch_state( State, Message ) -> State( Message ).


G>state1( msg1 ) -> ...;

G>state1( msg2 ) -> ...;

G>И все. Никаких "через жопу автогеном".


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

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

VD>>И твой тезис о том, что макросы что-то там нехорошее высвечивают сразу же бьет по Хаскелям и С++ с вдвойной силой. Бо это уже не только макросистемы, но еще и кривые и неудобные макросистемы.


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


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

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


Сдается мне, что эти случаи не так редки, просто глупо спорить кога мнения совпадают, а без спора и не видно, что они совпадают .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, lomeo, Вы писали:

L>1. Почему большую сложность реализации?


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

L> Инструмент использовать надо для того, для чего он предназначен.

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

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

L>2. Почему меньшие возможности?


Потому что нет прямых средств манипуляции кодом. Понимаеш ли, глупо медитировать чтобы подвинуть стакан с чаем. Руками это сделать проще и быстрее. А главное гарантиованно надежнее .

L>3. Проблема производительности решается не только макросами, честное пионерское.


Вот только макросы позволяют решать ее без шаманства. Сгенерируется такой код который нужен.

L>4. Э? Какие недостатки ты имеешь в виду?


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

VD>>Ну, и где здесь приемущества? Отсутсвие слова "макросы"? Ахринеть (с)!


L>Ты не знаешь, что у макросов есть недостатки, которых нет у штатных конструкций языка?


Нет. Не знаю. У них только два недостатка:
1. Их нужно писать и отлаживать (как любой код).
2. Они меняют семантику языка.

Оба недостатка будут у любого средства ДСЛ-естроения.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 12:47
Оценка:
Здравствуйте, lomeo, Вы писали:

VD>>При том, что сегодня ФВП полноцено не поддерживаются разве что в С++. И эти тирады несколько смешны.


L>Ты с кем разговариваешь? Какое ФВП и С++?


Читай внимательнее. В прочем в С++ ФВП тоже конечно есть (или эмулируются). Просто дико неудобно с ними работать.

L>В сотый раз про что? Кому "вам"? Я отвечал на вопрос konsoletyper'а. Может быть ответил не то, что он спрашивал, но это судить ему. А ты на что отвечаешь? Причём тут макросы в апогее?

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

Говоря о Парске мы обнаружили проблемы в синтаксисе которые было предложено решать левыми средствами присутствующими только в одном компиляторе, а так же усомнились в производительности данного решения. В прочем я еще сильно сомневаюсь в том, что Парсер обеспечивает внятную диагностику грамматических ошибок (выявление неоднозначностей, например). На предложение создать реальный (простенький) пример мне было заявлено, что на это нет времени, так как иначе будет некогда отвечать на мои сообщения. Почему-то мне кажется, что время на создание теста должно было бы уйти куда меньше.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: Klapaucius  
Дата: 27.07.07 13:11
Оценка: :)
Здравствуйте, eao197, Вы писали:

E>Задача

x := alpha * p + omega * s;

, изложенная Klapaucius вот здесь
Автор: Klapaucius
Дата: 09.07.07
может быть решена, например, так:


E>
<...>
E>class delayed_sum_of_scalar_to_vector_multiply_t
E>    {
E>    public :
E>        delayed_sum_of_scalar_to_vector_multiply_t(
E>            const delayed_scalar_by_vector_multiply_t & a,
E>            const delayed_scalar_by_vector_multiply_t & b )
E>            :    a_( a )
E>            ,    b_( b )
E>            {}

E>        void calc_and_store_to( vector_t & receiver ) const
E>            {
E>                if( a_.vector().size() != b_.vector().size() )
E>                    throw std::invalid_argument( "vectors must have the same size" );

E>                receiver.clear();
E>                receiver.reserve( a_.vector().size() );

E>                for( unsigned int i = 0, i_max = a_.vector().size();
E>                        i != i_max;
E>                        ++i )
E>                    receiver.push_back(
E>                            a_.vector()[ i ] * a_.scalar() +
E>                            b_.vector()[ i ] * b_.scalar() );
E>            }

E>    private :
E>        delayed_scalar_by_vector_multiply_t a_;
E>        delayed_scalar_by_vector_multiply_t b_;
E>    };
<...>
E>


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

Правильно ли я понял, что предлагается писать вручную реализации для всех возможных выражений?
Это шутка? Если это шутка, то ее можно было бы выразить и короче:
Зачем макросы, если есть прилежание и усидчивость?

E>Это демонстрация принципиальной схемы реализации отложенных вычислений в C++, полученная за 15 минут. Более сложные схемы могут быть получены при приложении несколько больших усилий.


И, по всей видимости, всего навсего за N * 15 минут, где N — количество всех возможных в линейной алгебре выражений со скалярами, векторами и матрицами? Так ведь можно до конца геологической эпохи не поспеть.

E>Только Nolite mittere margaeritas ante porcas!


Да уж, про метание бисера перед свиньями, это к месту, после такого выступления. Боюсь, что у меня и в самом деле недостаточно широкие взгляды, для того чтобы оценить такое решение моей задачи по достоинству. Или, может быть, я вовсе не свинья, может быть это бисер у Вас какой-то сомнительный, а?
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[17]: Являются ли макросы свидетельством недостаточной выр
От: VladD2 Российская Империя www.nemerle.org
Дата: 27.07.07 13:26
Оценка:
Здравствуйте, eao197, Вы писали:

Пояснил бы суть решения...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>1. Почему большую сложность реализации?

VD>Потому что окольными путями ходить приходится. Может и не всегда, но частенько.

Нуу, это надо конкретные случаи рассматривать.

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


Ну да, чего мы опять эту тему обсасываем?

L>>3. Проблема производительности решается не только макросами, честное пионерское.

VD>Вот только макросы позволяют решать ее без шаманства.

Сильно сомневаюсь, что только.

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


Вроде тут говорили не о синтаксисе, а о DSL.

L>>Ты не знаешь, что у макросов есть недостатки, которых нет у штатных конструкций языка?


VD>Нет. Не знаю. У них только два недостатка:

VD>1. Их нужно писать и отлаживать (как любой код).
VD>2. Они меняют семантику языка.

VD>Оба недостатка будут у любого средства ДСЛ-естроения.


Штатные конструкции меняют семантику? Или ты что то другое хотел сказать?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Являются ли макросы свидетельством недостаточной выра
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

L>>Ты кстати на вопросы не ответил.


VD>Какой?


Там несколько:

1. "Изменение синтаксиса и вычисление во время компиляции — это да. Это область макросов, но при чём тут DSL?" (ну, сейчас уже можно и не отвечать)

2. "Что такое выкрутасы с системой типов Хаскеля? Вот мы тут с konsoletyper про Parsec говорили. Это выкрутасы?" (до сих пор не знаю о чём идёт речь)

3. "Где монады при использовании Парсека?" Это к вопросу о простоте.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
От: lomeo Россия http://lomeo.livejournal.com/
Дата: 27.07.07 13:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мне совершенно все равно как там работает bytestring. Но мне очень интересно сравнить Хаскель с его подходом к ДСЛ-естроению с Немерле на реальной (боевой, можнос сказать) задаче. А вот наши беседы мне становятся менее и менее интересны, и не потому, что я тебя не уважаю или стопроцентно уверен в своем мнении, а потому, что не несут рационального зерна. Это не более чем наши мнения.


ОК. Понимаю, тебе интересно. Мне не очень -- просто в силу того, что знание это никакой пользы для меня иметь не будет. Может быть очень маленькую. А вот сил я затрачу массу на написание лексера языка, с которым я не работаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.