Здравствуйте, Gaperton, Вы писали:
G>В выражении a = b + c + d, где переменные — матрицы, надо, чтобы все это свернулось в единственный двойной цикл с этой формулой внутри. На плюсах это делается без макросов — через темплейтное метапрограммирование, и выглядит страшно. На макросах, мне думается, реализация выглядела бы проще. Хотя — честно скажу, пока на макросах реализации не видел. Все только говорят, говорят о великих и ужасных макросах — и все .
Конечно реализовывать я подобную хрень не стану (мне это на фиг не упало), но могу в кратце рассказать как оно может быть реализовано.
Вводится поератор. Оператор = использовать нельзя так как он уже прегружен для ругих целей. Но вместо него можно ввести что угодно. Скажем тот же :=. Далее все просто как неучить уроков. Макрос принимает в качестве параметров два выражения в виде АСТ. Первое выражение — это то во что будет присвоено результирующее значение. Второе — что за выражение нужно вычислить. Далее остается только разобрать выражение и переписать его оптимальным образом. С использованием паттерн-матичинга это не составит труда.
Собственно практически тоже самое делает макрос $ в Немерле. Он берет строку вида $"Просто текст $(вычисляемое + выржение) и еще просто текст." и преобразует его в вызов вида:
string.Concat("Просто текст ", (вычисляемое + выржение).ToString(), " и еще просто текст.");
что в результате дает максимально эффективный код.
Собственно — это есть отличный пример встраеваемого микро-DSL-я. И как видишь уже второй который ты можешь приводить в качестве примера .
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Подозреваю, ... За исключением...По идее...Не знаю, сработает ли здесь.
Что я могу скзать? Может в этом и состоит разница? Вот я, например, не сомневаюсь, что все тоже самое с соблюдением синтаксиса можно залудить средствами макросов Немерла и при этом плучить настолько оптимальный код насколько его вообще можно получить на Немерле (т.е. не отличающийся от оптимального рукописного кода). А ты сомневашся. И сомнения твои вызваны неполноценностью средства, сложностю и тормознутостью самого языка.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>разумеется не надо. Для того, чтобы паттерны были не нужны, их не надо встраивать в язык. Надо язык выразительный иметь.
Нет таких языков. И быть не может. В любом самом выразительном языке всегда находится место для паттернов, потому как паттерны — это стериотип решения некоторых задач не решаемых одним оператором языка. А такие задачи будут всегда.
G>валяйте, давайте сюда пример, и я покажу, как его сделать без макросов и паттернов. Мне хватит паттерн-матчинга, атомов, и первоклассных функций.
Хватит, или сможешь решать задачи компактнее, быстрее и порождая более производительный код? Если говорить о "хватит" в общем-то С для любой задачи хватит. Вот только паттерны от этого не исчезнут. Они просто будут строиться на базе ФВП и паттернматчинга.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
K>>Уже давно глядел. Не понравилось.
L> Давай не будем это считать аргументом.
Ну, почему же?
K>>Во-первых, все эти <###> смотрятся коряво, а хотелось бы человеческого EBNF-образного синтаксиса.
L>Синтаксис очень близок к EBNF вплоть до переименования.
Тебе не кажется, что "очень близок" на практике означет "непохож"?
Понимаеш ли в чем дело?... На макросах можно получить как раз тот синтаксис что тебе требуется. И делается это проще.
L>Вместо "|" здесь "<|>", вместо +/* — many1/many, вместо '(' — char '(', "abc" — string "abc".
Да, да... Вот только в лексере konsoletyper-а вместо "|" используется (ты не поверишь) "|" и т.д.
K>>Кроме того, мнее вообще непонятно, как это всё работает.
L>Это тоже вряд ли сойдёт за аргумент
Как раз в нашем случае это главный аргумент. Макросы гнобят за сложность. И за то что далеко не каждый их может использовать без вреда для здоровья. Но монады намного сложнее макросов. Они не очевидны. И резльтат получаемый с их помощью далеко не всегда тот что требуется програмисту. Тут тебе и ограничения, и низкая скорость. А вот макрос он тупо переписывает один код в другой. Причем этот другой код всегда будет таким как ты захочешь его видеть.
L>Поверь, для этого не надо вкуривать монады. Достаточно понять, что парсер это функция, дальше всё просто.
Мне показалось он говорит о реализации.
L>Да и вообще — у тебя уже есть готовый DSL. Зачем тебе знать на чём он построен — на макросах или монадах?
Очевидно, чтобы написать свои собственные DSL-и. Мы же вроде бы об этом, а не о готовых решения. Ведь на свете уже давно существуют Яки и Антлр-ы. Их можно вкурить не только без знания монад, но и без знания о существовании Хаскеля.
L>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.
Макросы не надо эмулировать. Это правда. Они мощьнее чем вырктасы шаблонного МП в С++ и куда монад в Хаскеле. Они прямое средство переписывания кода так как надо программисту. И нихрена в этой области с ними не сравнится.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Без проблем! Меняем названия на EBNF-ные.
На EBNF есть ISO-стандарт. Вот кода вы на Хаскеле его повторить сможете (ну, процентов так на 99 хотя бы), тогда можено будет поговорить. А пока тебе прийдется признать, что решение на Хаскеле не полноценно.
L>Нужны мозги, готовые писать декларативно.
Хм. Решение на макросах получается короче и понятнее, но оно не декларативно? Забавные выводы.
L>Если хочешь, я объясню на пальцах строение Parsec. Знание монад вряд ли тебе понадобится.
L>На самом деле, когда я с Лиспа перешёл на Хаскель, я тоже недоумевал, как же так? А где макросы? Поработав через некоторое время я почувствовал, что для большинства вещей они там не нужны. Макросы в Лиспе большей частью нужны были для подслащивания: реализации ленивости (эта часть выполняется только если...), более удобной записи вызовов (вместо всех этих lambda что то вроде карринга), и прочей кодогенерации (скажем куча определений вместо одного) и т.д. L>Всё это есть в Хаскель задаром. Последнее делается разве что немного по другому.
Ну, так не бери для сравнения Лисп. Старичку все же уже 50 лет! Возми Немерле. Он в большинстве случаев не уступает Хаскелю в выразительности сам по себе и при этом еще содержит макросы. В прочем все эти ТемлэйтХаскели и РеврайтРулезы ни что иное как маросы. Так что ты лучше обясни как решить конфликт между наличием этих фич и утверждением о том, что макросы не нужны. Это будет куда интереснее.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[19]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.
Сори, а на кого направлен этот балшит? Может еще разведем балшит по повоту продвинутости структурного программирования в сравнении с ассемблерами?
Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
L>The library is fast, parsing thousands of lines a second on today's machines
L>Но тысячи в секунду, это как то маловато, если честно.
Ага. Я тоже сполз под стол читая эту цитату.
L> Даже для 2001. Очень-очень сомневаюсь, что это связано с тем, что реализация не на макросах. Надо с Happy сравнить. Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.
Предлагаю запенисометрировать.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Я воспользуюсь flex, или любой подобной тулзой. По ним хотя-бы документация есть, и мой код все поймут, а в велисипеде на макросах еще рабираться надо будет стороннему программеру. Недостатка в генераторах лексеров и парсеров нет ни для какого языка. Буквально для любого языка есть выбор.
Ты бы попробовал, а потом обсудили бы. А то как-то не смешно. Я вот попробовал и готов потратить время на изучение, чтобы не испытывать тех проблем, что есть с тулзами вроде flex-а.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Константин Л., Вы писали:
K>>Я могу так же взять C#, как всем известный язык. Но начать юзать для него вместо .NET Framework библиотеки, написанные неизвестно кем (хотя бы даже свои). И знаешь, инженер, который будет править баги, будет материться не меньше.
КЛ>Зато отладка макросов это очень неприятное занятие.
Это не свойство самих макросов. Это свойство реализации. Для макросов можно сделать полноценную отладку. Это чисто техническая проблема. Хотя в том же Немерле она пока что не решена до коца. Это факт.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, lomeo, Вы писали:
L>Здравствуйте, VladD2, Вы писали:
VD>>Я вот все больше склоняюсь к тому, что простое решение — это решение описанное максимально близко к терминам предметной области (максимально высокоуронево). Ну, то есть с Виртом в корне не согласен. А макросы как раз позволяют мне встроить в язык такие прикладные решения. Системы типов этого не позволяют. Даже хаскелевская... если конечно не заниматься на ней МП.
L>Почему априори считается, что МП — это обязательно макросы?
А я так не считаю. Я просто считаю, что макросы (правильно приготовленные) — это лучшее на сегодня средство для преготовления МП.
L>Что касается встраивания в язык DSL, то на Haskell это получается замечательно.
Ну, вот мы уже видили убогие ивороты в Парсеке. Не уверен, но что-то мне подсказывает, что и скорость у Парсека тоже ни ахти какая.
L> Просто там другой подход, и, разумеется, есть отличия от подхода с макросами.
Дык о том и речь. Но МП оно и в африке МП и все претензии, что можно предявить к нему применимы как к макрам, так и к любым другим его видам. А вот результат... Он 100%-но более качественен у макр, да и понять решения на макросах, на мой взгляд, проще. В прочем, последнее утверждение конечно спорно. Но и первого хватет.
L> Вот в этой статье, например сказано, что именно Haskell не умеет делать, в отличие от макросов, а что умеет. Но делает это по своему, и не выглядит неестественным.
Дык если что-то не умеет, начи уже менее мощьный. При этом еще и более сложный.
Что имеем в итоге?
1. Большую сложность реализации.
2. Меньшие возможности.
3. Меньшую скорость результирующего кода.
4. Все (гипотетические, так как на мой взгляд это домыслы) недостатки МП.
Ну, и где здесь приемущества? Отсутсвие слова "макросы"? Ахринеть (с)!
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
ANS>>Белая гарячка
VD>у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.
Влад ты на самом деле бредишь, возражать на это бессмысленно.
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
VD>Решение конечно на шаблонах с применением Буста?
На шаблонах без буста. Я такой велосипед писал когда про буст еще не слышал.
Re[12]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Курилка, Вы писали:
VD>>>Любой DSL.
К>>Ммм, значит DSL на хаскеле или скале "не считаются"?
VD>Считается. Но они получаются слишком ограниченные в сравнении с прмыми решениями. В прочем, причем тут Скала вообще не ясно. Там система типов мало чем не отличается от Ява/Шарпа.
Т.е. DSL рассматриваются только в свете системы типов, остальные возможности языка выкидываем? Интересно...
А по поводу скалы, вот простенький пример отсюда :
val res = db.executeStatement {
select fields ("name" of characterVarying(50)) from "person"
}
Подход, принятый тут (называемый авторами “zygotictype-directed growth”), описан здесь
Re[13]: Являются ли макросы свидетельством недостаточной выр
К>Подход, принятый тут (называемый авторами “zygotictype-directed growth”), описан здесь
Кстати на D это также можно сделать.
Вообще для подобных мелких DSL вполне достаточно чтобы в языке были ленивые вычисления (тот же lazy в D или блоки кода типа Смаллтаковских).
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, FR, Вы писали:
FR>Вообще для подобных мелких DSL вполне достаточно чтобы в языке были ленивые вычисления (тот же lazy в D или блоки кода типа Смаллтаковских).
А в скале вродь как без ленивости обошлись. А блоки кода в смолтолке по сути же лямбды или лямбды мы уже за "отложенные вычисления" считаем?
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, WolfHound, Вы писали:
G>>какая разница, тьюринг-полный он или нет. Ровным счетом никакой. Рассмотри любой пример, когда тебе надо в рантайме подцеплять и интерпретировать описание на специальном языке. Например — веб-браузер. И все — макросы — до свидания. WH>А если не надо? А случаев когда не надо гораздо больше.
Вопрос — пример когда макросы сосут? Тебе я дал ответ — когда надо в рантайме подцеплять. Ты сначала сказал "а если язык не тьюринг-полный, то ведь все не так", а потом с ленинским прищуром спросил — "а если не надо?"
WH>Так что попытка обосновать не нужнось макросов наличием жабаскрипта идет лесом.
Лесом идут такие аргументы вместе с автором. То есть тобой. С пионерами в таком ключе спорь.
WH>Болие того я спокойно могу на лету скомпилить код на томже немерле... с макросами...
Компили на здоровье. Напишешь браузер на немерле — выложи, посмеемся. Зело хоцца посмотреть, как ты спокойно компилятор немерле будешь поднимать на каждую страницу, и на каждый маленький полученный по аяксу скрипт. А потом — вместе это в один вычислительный контекст текущего документа склеивать.
G>>Это я вообще не понял. Что за выхлоп, почему проще без lex-yacc, почему геморройно с генераторами парсеров, чем без них. Странно как-то то все звучит. WH>То и значит.
Слушай, когда изъясняться понятно начнешь, по-нормальному, без выхлопов, тогда и поговорим.
WH>Лексаяки рулят если нужно написать компилятор на тупом языке типа C/C++/C# но если в языке есть алгебраические типы, сравнение с образцом, ФВП, макросы итп то от лексаяков пользы нет.
Угу.
Re[3]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, VladD2, Вы писали:
G>>Я думаю, и так понятно, кто за, а кто против . Влад уже выступил, могу добавить от себя — я сторонник тезиса, что необходимость в макроподдержке при гражданской разработке является симптомом недостаточной выразительности языковых средств, в т.ч. и системы типов.
VD>Система типов не может заменить наличия метапрограммирования (МП). Она, при использовании в своем исходном предназначении, не может решать задач метапрограммирования. А когда система типов превращается в средство для нелегальной реализации МП, то мы получам те же макросы, только, как я уже упомянул, "через жопу... автогеном".
Я говорил не о замене метапрограммирования чем-то там, а о повседневной необходимости в нем. Разницу чувствуешь? Объясняю. Где-то придется для "паттерна" конечного автомата заводить макрос, чтоб красиво было. А кое-где — это совершенно обычная задача, не требующая ни выверта, ни паттерна. Смотри:
И все. Никаких "через жопу автогеном".
VD>И твой тезис о том, что макросы что-то там нехорошее высвечивают сразу же бьет по Хаскелям и С++ с вдвойной силой. Бо это уже не только макросистемы, но еще и кривые и неудобные макросистемы.
Мой тезис говорит о том, что макросистемы — темная сторона силы. Настоящий джедай управится и без них. И все. Никуда он не бьет.
G>>За исключением случая разработки языковых расширений — здесь хорошая макросистема спнаконец особна сократить трудозатраты на его создание и поддержку.
VD>Дык, макросы и нужны для языковых расширений. 90% применения в прикладном коде для макросов, на мой взгляд, — это DSL-и. Остальные 10% — это допиливание языка напильником для применения в конкретной сфере. Это допиливание легко ложится в библиотеки и может просто пополнять язык (делая его удобнее для конкретных областей применения).
Вот видишь — наступил наконец редкий случай, когда мы с тобой согласны. Ну, почти .
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>Вообще для подобных мелких DSL вполне достаточно чтобы в языке были ленивые вычисления (тот же lazy в D или блоки кода типа Смаллтаковских).
К>А в скале вродь как без ленивости обошлись. А блоки кода в смолтолке по сути же лямбды или лямбды мы уже за "отложенные вычисления" считаем?
Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров.
Лямбды конечно тоже.
Все только говорят, говорят о великих и ужасных макросах — и все 
.
