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

_>В принципе паттерны проектирования максимально полезны именно введением некого общего языка понятий между программистами.

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

_>Однако они вполне существуют и в виде кусков готового кода или даже библиотек. И для реализации в коде очень многих паттернов никакого метапрограммирования не требуется.

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

_>А что у нас с паттернами проектирования в функциональном стиле? ) Или с инструментами типа UML для функциональной парадигмы? )

Общим языком для ФП-программистов является (обычно, популяризированная и адаптированная) математика вообще и теория категорий в частности.

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

_>С чего бы это?

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

_>Я и не сказал, что поддержка заключается в наличие ключевого слова.

А в чем еще она заключается?

_> Это был просто пример того, как можно делать упор на определённом стиле, не запрещая при этом другие.

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

_> Никто не мешает сделать полноценную поддержку и при этом не навязывать её обязательное использование.

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

_>Опять же с чего бы это? ) Тот же пример чистоты в D говорит об обратном... )

О чем же он говорит? Это как-то конкретизировать можно? Нормальной ленивости в D нет, это я знаю. А как там с оптимизациями или, к примеру, STM дела обстоят?

_>хаскель (или что-то скриптовое похожего вида, кстати а такое вообще есть?)

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

_> C++/Python. Т.е. два мультипарадигменных языка!
_> в них напихано множество различных парадигм и концепций

Где же в них мультипарадигменность? Два ООП языка. Они кроме ООП разве еще что-то поддерживают?

_> но при этом ни одна не является обязательной для использования.

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

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

_>Вообще данная задача весьма бредова на мой взгляд

Это просто достаточно компактный пример, демонстрирующий полиморфную рекурсию, а не какую-то бессмысленную "защиту".

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

_>>Ну это проблемы исключительно ASP.NET. Как видно, достаточно универсальное решение делается на C++ всего в пару десятков строчек. )))
I>Ну сколько можно — еще одна попытка контекстно-свободный язык парсить регэкспом

Любой движок "регэкспов", поддерживающий lookahead/lookbehind, backreferences и (опционально) balancing groups, по факту реализуется на стековых автоматах, способных распознавать, как минимум, все LR(k) КС-языки. Пара примеров:

using System;
using System.Text.RegularExpressions;

namespace RegexesDemo
{
    class Program
    {
        private static void Run(string regex, string[] items, string positive, string negative)
        {
            var r = new Regex(regex, RegexOptions.IgnorePatternWhitespace);
            foreach (var item in items)
            {
                Console.WriteLine("\"{0}\" - {1}", item, r.IsMatch(item) ? positive : negative);
            }
            Console.WriteLine();
        }
        private static void Main()
        {
            // Проверка баланса скобок (распознавание строк языка "S → SS | (S) | ϵ")
            Run(@"^(((?'Open'\())+((?'Close-Open'\)))+)*(?(Open)(?!))$"
                  ,
                new[] {"()", ")(", "(())", "((()", "(()())", "(()()("}, "сбалансировано", "не сбалансировано"
            );

            // Проверка палиндромности (распознавание строк языка "P → ϵ | a | b | ... | z | aPa | bPb | ... | zPz") 
            Run(
                @"(?<Character>[a-z])+[a-z]?(?<-Character>\k<Character>)+(?(Character)(?!))",
                new[] { "test", "kayak", "blablabla" },
                "палиндром", "не палиндром"
            );

            Console.ReadKey();
        }
    }
}

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

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

KV>Любой движок "регэкспов", поддерживающий lookahead/lookbehind, backreferences и (опционально) balancing groups, по факту реализуется на стековых автоматах, способных распознавать, как минимум, все LR(k) КС-языки.

Спасибо за внимание, но месяца два или три назад в этом же треде или где то рядом я объяснял это же только без примеров.

В общем случае регекспы это все-таки регулярные грамматики. Фичи которые ты перечислил это расширения, которые есть не везде и не везде одинаково реализованы.

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

I>Ну то есть библиотеки писать не надо, правильно ?

Мультиметодов? ) Ну можно конечно ещё один велосипед накидать... Но проще взять уже готовую)

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

K>Смотря что значит "для реализации в коде". Паттерн — это типовая проблема и решение для нее. Если имеется в виду решенная в соответствии с паттерном проблема — то да, конечно не требуется. То, что делает инструментарий метапрограммирования автоматически — программист сделал вручную без этого инструментария. Если имеется в виду код-решатель проблемы, который применяется к одному коду с проблемой и производит код без проблемы, с решением — то тут без метапрограммирования, как правило, не обойтись.

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

K>Общим языком для ФП-программистов является (обычно, популяризированная и адаптированная) математика вообще и теория категорий в частности.

Ага, т.е. никаких инструментов помогающих в проектирования архитектуры сложных приложений не имеем... Я так и думал.

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

Так а в чём проблема, если все эти оптимизации компилятор будет делать для ЧАСТИ кода? Т.е. если половина программы (функции с модификатором pure, работающие с данными с модификатором const) будет обработана в соответствие с одними правилами, а оставшаяся с другими (отсутствием ленивости, консервативной оптимизацией и т.п.).

_>>Опять же с чего бы это? ) Тот же пример чистоты в D говорит об обратном... )
K>О чем же он говорит? Это как-то конкретизировать можно? Нормальной ленивости в D нет, это я знаю. А как там с оптимизациями или, к примеру, STM дела обстоят?

Он говорит о том, что можно вводить подобные возможности, не вводя обязательности использования. Ленивости в языке пока нет, но не вижу никаких проблем для её введения (может будет в версии 3). А вот с оптимизацией там как раз всё великолепно. Учитываются и такие вещи и ещё есть целая отдельная сложная и крайне эффективная область с вычислениями на стадии компиляции. Зародыш подобного есть в C++, но в слабой и неудобной форме.

_>>хаскель (или что-то скриптовое похожего вида, кстати а такое вообще есть?)
K>Зависит от того, насколько похожее требуется и что под скриптовостью понимается.

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

_>> C++/Python. Т.е. два мультипарадигменных языка!
_>> в них напихано множество различных парадигм и концепций
K>Где же в них мультипарадигменность? Два ООП языка. Они кроме ООП разве еще что-то поддерживают?

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

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

K>Это просто достаточно компактный пример, демонстрирующий полиморфную рекурсию, а не какую-то бессмысленную "защиту".

Это точное решение конкретной задачки в полном соответствие с её изначальной формулировкой автором: http://www.linux.org.ru/forum/development/4300872. Причём показанное мною простейшее решение на C++ ещё и короче, эффективнее и функциональнее вариантов, предложенных на других языках.

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

I>В общем случае регекспы это все-таки регулярные грамматики. Фичи которые ты перечислил это расширения, которые есть не везде и не везде одинаково реализованы.

Ну например в стандарт языка C++ регулярные выражения входят именно в таком виде.

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

I>>Ну то есть библиотеки писать не надо, правильно ?

_>Мультиметодов? ) Ну можно конечно ещё один велосипед накидать... Но проще взять уже готовую)

Пока нет либ на все случаи жизни, то приходится писать их самому. Как то так.

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

I>>В общем случае регекспы это все-таки регулярные грамматики. Фичи которые ты перечислил это расширения, которые есть не везде и не везде одинаково реализованы.

_>Ну например в стандарт языка C++ регулярные выражения входят именно в таком виде.

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

Здравствуйте, alex_public, Вы писали:
_>Это точное решение конкретной задачки в полном соответствие с её изначальной формулировкой автором: http://www.linux.org.ru/forum/development/4300872. Причём показанное мною простейшее решение на C++ ещё и короче, эффективнее и функциональнее вариантов, предложенных на других языках.
Да, забавный трюк. Жаль, что он не подходит для задач, отклоняющихся от предложенного сценария хотя бы на один шаг.
Даже вот так уже не работает:

        int n;
        cin >> n;
        cint size1 {n};
        auto cons1 = MakeCons(size1, [](int i){return i; });
        cint size2 {n};
        auto cons2 = MakeCons(size2, [](int i){return i; });//а такое не будет компилироваться
        return ScalarProduct(cons1, cons2);

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

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

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

Ну я и говорю: тут без метапрограммирования, как правило, не обойтись.

K>>Общим языком для ФП-программистов является (обычно, популяризированная и адаптированная) математика вообще и теория категорий в частности.
_>Ага, т.е. никаких инструментов помогающих в проектирования архитектуры сложных приложений не имеем... Я так и думал.

Вы так усиленно это думали, что начисто проигнорировали мой ответ.

_>Так а в чём проблема, если все эти оптимизации компилятор будет делать для ЧАСТИ кода? Т.е. если половина программы (функции с модификатором pure, работающие с данными с модификатором const) будет обработана в соответствие с одними правилами, а оставшаяся с другими (отсутствием ленивости, консервативной оптимизацией и т.п.).

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

_>Он говорит о том, что можно вводить подобные возможности, не вводя обязательности использования.

Чем в этом смысле по вашему подход D лучше подхода хаскеля?

_>Ленивости в языке пока нет

Ну, вот видите.

_>А вот с оптимизацией там как раз всё великолепно.

Т.е. в обсуждаемом по соседству случае компилятор D лишние копирования устранит, как и ghc?

_>Учитываются и такие вещи и ещё есть целая отдельная сложная и крайне эффективная область с вычислениями на стадии компиляции.

Тут речь идет именно о применении метапрограммирования для получения эффективного кода из некоего встроенного dsl, а не оптимизации общего назначения, я правильно понял?

_>Что-нибудь с динамической типизацией, при этом чисто функциональное и ленивое.

До известной статьи Дамаса и Милнера (т.е. до начала 80-х) такие языки действительно были, тот же автор протохаскеля-Миранды Тернер в свое время пару таких сделал. Но после они сошли на нет — без типов особо не развернешься, так же, как ЯП без контроля эффектов — это вечные 90-е, так и бестиповые языки — вечные 70-е.
Самый похожий на хаскель из известных мне скриптов — Pure — ни чистым, ни ленивым (по умолчанию) не является.

K>>Где же в них мультипарадигменность? Два ООП языка. Они кроме ООП разве еще что-то поддерживают?
_>Ну это уже откровенный троллизм, который явно свидетельствует о том, что просто нечего сказать в ответ.

По-моему, вопрос совершенно нормальный. А вот ваш отказ от ответа на вопрос о том, что они еще, кроме обычного императивного программирования (ООП), поддерживают — как раз и означает, что вам сказать нечего.

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

_>Так а в чём проблема, если все эти оптимизации компилятор будет делать для ЧАСТИ кода? Т.е. если половина программы (функции с модификатором pure, работающие с данными с модификатором const) будет обработана в соответствие с одними правилами, а оставшаяся с другими (отсутствием ленивости, консервативной оптимизацией и т.п.).
Проблема — в том, что для применения оптимизаций в одном месте, нужно соблюдать ограничения в другом.
Выбрасывать проверки выхода за границы диапазона при обращении по индексу можно только в том случае, если у нас весь код ведёт себя прилично — в частности, не порождает индексы, которые могут выйти за пределы разрешённого диапазона. Устранять лишние копирования можно только в случае ссылочной прозрачности — т.е. объект гарантированно immutable или single-owned. Код-нарушитель не просто будет "менее оптимальным", он тупо сломает "благонамеренный" код, который оптимизирован из расчёта на отсутствие нарушителей.

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

I>В твоих решениях таких фич не было, решения без регекспос у тебя сводились к регулярной грамматике, а в случае с хтмл все еще хуже — даже контекстно-свободная грамматика тебе не поможет (я уверен ты тут же накидаешь опровержение в две строчки на регэкспах).

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

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

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

S>Да, забавный трюк. Жаль, что он не подходит для задач, отклоняющихся от предложенного сценария хотя бы на один шаг.
S>Даже вот так уже не работает:

Ну так а он и не должен компилироваться в таком случае — нам же необходимо гарантировать компилятором равенство длин векторов. А если бы такое собиралось, то добавление банального n++ в середину сразу же давало бы неправильную программу.

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

K>Ну я и говорю: тут без метапрограммирования, как правило, не обойтись.

Это только в случае C++, потому как у него обобщённое программирование реализовано через метапрограммирование (что мы и обсуждали здесь). А во многих других языках достаточно именно просто обобщённое программирования (да и собственно нормальное метапрограммирование вообще мало где есть).

K>Вы так усиленно это думали, что начисто проигнорировали мой ответ.

Это про математику и теорию категорий в частности? ) Ну так можно мне увидеть какой-нибудь профессиональный инструмент для проектирования архитектуры ПО, основанный на этом? )

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

Нет, это как раз добавление возможности. А ограничением будет требование иметь в коде только pure функции.

K>Чем в этом смысле по вашему подход D лучше подхода хаскеля?

Я же уже вроде несколько раз объяснял. Ну могу ещё раз, на примере той же самой чистоты:
— в C++: нет возможности, нет ограничений
— в D: есть возможность, нет ограничений
— в Haskell: есть возможность, есть ограничения (все функции должны быть такие).

K>Т.е. в обсуждаемом по соседству случае компилятор D лишние копирования устранит, как и ghc?

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

K>До известной статьи Дамаса и Милнера (т.е. до начала 80-х) такие языки действительно были, тот же автор протохаскеля-Миранды Тернер в свое время пару таких сделал. Но после они сошли на нет — без типов особо не развернешься, так же, как ЯП без контроля эффектов — это вечные 90-е, так и бестиповые языки — вечные 70-е.

Только что-то основной расцвет подобных языков наблюдается как раз сейчас, в 21-ом веке... ) Причём чем проще, тем популярнее. Мой любимый простенький Питончик на фоне остальных является ещё довольно серьёзным и сложным. ))) А если мы возьмём какой-нибудь JavaScript, который пролез уже и на серверы (node.js) и в десктоп (metro api win8)...

K>По-моему, вопрос совершенно нормальный. А вот ваш отказ от ответа на вопрос о том, что они еще, кроме обычного императивного программирования (ООП), поддерживают — как раз и означает, что вам сказать нечего.

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

http://en.wikipedia.org/wiki/C%2B%2B хотя тут забыли метапрограммирование,
http://en.wikipedia.org/wiki/Python_%28programming_language%29 а здесь забыли АОП.

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

S>Проблема — в том, что для применения оптимизаций в одном месте, нужно соблюдать ограничения в другом.
S>Выбрасывать проверки выхода за границы диапазона при обращении по индексу можно только в том случае, если у нас весь код ведёт себя прилично — в частности, не порождает индексы, которые могут выйти за пределы разрешённого диапазона. Устранять лишние копирования можно только в случае ссылочной прозрачности — т.е. объект гарантированно immutable или single-owned. Код-нарушитель не просто будет "менее оптимальным", он тупо сломает "благонамеренный" код, который оптимизирован из расчёта на отсутствие нарушителей.

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

Или имеем константные объекты с одним содержимым (хотя для языков типа C++ это не так актуально, т.к. там принято явно указывать ссылки в таких случаях). Чем может помешать компилятору не размножать этот объект, нахождение рядом с ним некого неконстантного объекта?

И никто не предлагает иметь объекты, которые в одном месте константные, а в другом нет. Предлагается иметь и такие и такие по отдельности (собственно такое уже давно есть во многих языках). И аналогично с другими фичами типа чистоты и т.п. В том же D это во многом реализовано, но ещё не до конца (грубо говоря не все фичи Хаскеля перетащили, при этом сохраняя их необязательность, как в C++).

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

_>Ну так там просто примеры были такие тривиальные, что большего и не требовалось. ) А вообще я всяческими пред/пост условиями вполне пользуюсь в регулярных выражениях.

Нетривиальные и ты сам говорил что это экзотика.

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

Да ничего, см выше, ты уже отказался от своих слов. Как то так

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

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

S>>Проблема — в том, что для применения оптимизаций в одном месте, нужно соблюдать ограничения в другом.
S>>Выбрасывать проверки выхода за границы диапазона при обращении по индексу можно только в том случае, если у нас весь код ведёт себя прилично — в частности, не порождает индексы, которые могут выйти за пределы разрешённого диапазона. Устранять лишние копирования можно только в случае ссылочной прозрачности — т.е. объект гарантированно immutable или single-owned. Код-нарушитель не просто будет "менее оптимальным", он тупо сломает "благонамеренный" код, который оптимизирован из расчёта на отсутствие нарушителей.

_>Непонятно в чём проблема. Вот имеем мы чистую функцию. Что это значит с точки зрения оптимизатора? Что результат её вызова с одними аргументами можно кэшировать и что можно произвольно передвигать точку её вызова (это кстати включает в себя ленивость). И чем может помешать оптимизатору нахождение рядом с вызовом чистой функции вызова ещё и не чистой? Да, со второй функции он не сможет ничего этого делать. Ну так мы и не требуем этого.

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


_>Или имеем константные объекты с одним содержимым (хотя для языков типа C++ это не так актуально, т.к. там принято явно указывать ссылки в таких случаях). Чем может помешать компилятору не размножать этот объект, нахождение рядом с ним некого неконстантного объекта?
Если неконстантный объект имеет общие данные с константным, то результат программы может оказаться разным при копировании и передаче ссылки. Кстати константность вообще не гарантия, поэтому компилятор не производит никаких оптимизаций на основе константности.


_>И никто не предлагает иметь объекты, которые в одном месте константные, а в другом нет. Предлагается иметь и такие и такие по отдельности (собственно такое уже давно есть во многих языках). И аналогично с другими фичами типа чистоты и т.п. В том же D это во многом реализовано, но ещё не до конца (грубо говоря не все фичи Хаскеля перетащили, при этом сохраняя их необязательность, как в C++).
А как гарантировать что нечистые функции не влияют на чистые?

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

_>>Непонятно в чём проблема. Вот имеем мы чистую функцию. Что это значит с точки зрения оптимизатора? Что результат её вызова с одними аргументами можно кэшировать и что можно произвольно передвигать точку её вызова (это кстати включает в себя ленивость). И чем может помешать оптимизатору нахождение рядом с вызовом чистой функции вызова ещё и не чистой? Да, со второй функции он не сможет ничего этого делать. Ну так мы и не требуем этого.

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

В D чистая функция "does not read or write any global or static mutable state" помимо прочего. Так что помешать ей не получится, если конечно не идти намеренно против системы типов, но тогда уже вся ответственность на нарушителе.