Здравствуйте, VladD2, Вы писали:
VD>>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
ANS>>Белая гарячка
VD>у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.
Влад, если вышеотквоченный текст это был вопрос и тебе интересно узнать мнение других людей, то попробуй поставить в нужном месте знак вопроса. Если это был сарказм или шутка, то поставь смайлик. Если же то было утверждение, то таки смотри мой коммент строчкой ниже твоего спича.
Здравствуйте, FR, Вы писали:
FR>Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров.
Аргументируй, не вижу там ничего ленивого, или наличие ф-ции, которая вызывает/выполняет DSL и есть такая ленивость? FR>Лямбды конечно тоже.
Тогда макросы — тоже ленивость? Ониж генерируют код, который сразу не выполняется.
Плюс паттерны стратегия/комманда тоже туда пойдут.
Т.е. теоретически, конечно, это есть некая ленивость, но вот с термином ленивых вычислений, аля как в хаскеле это не очень соотносится имхо.
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
FR>>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
VD>Решение конечно на шаблонах с применением Буста?
Принципиальная схема реализации отложенных вычислений в C++ изложена у Страуструпа в 3-м издании "Язык программирования C++" (Б.Страуструп, Язык программирования C++, спец. изд./Пер.с англ. — М.;СПб.:"Издательство БИНОМ" — "Невский Диалект", 2001г. — 1099с., ил.) Раздел 22.4.7 "Временные массивы, копирование и циклы", стр.743.
Без шаблонов и Буста.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров. К>Аргументируй, не вижу там ничего ленивого, или наличие ф-ции, которая вызывает/выполняет DSL и есть такая ленивость?
Я не совсем понял как там передаются те же условия в запрос, ведь они не должны вычислятся сразу, раньше тут на RSDN был пример реализации своих управляющих конструкции на Scala и аналогов на D, там использовались именно ленивые параметры (http://www.digitalmars.com/d/lazy-evaluation.html) так что я подумал что здесь тоже самое.
FR>>Лямбды конечно тоже. К>Тогда макросы — тоже ленивость? Ониж генерируют код, который сразу не выполняется. К>Плюс паттерны стратегия/комманда тоже туда пойдут. К>Т.е. теоретически, конечно, это есть некая ленивость, но вот с термином ленивых вычислений, аля как в хаскеле это не очень соотносится имхо.
Теоретически оно конечно Но я хотел сказать только следующее достаточно блоков кода (или аналогов из функциональщины в виде лямбд и фвп) чтобы язык был настолько гибким чтобы практически не нуждатся в макросах (например http://www.rebol.com который и без макросов в гибкости не уступает лиспу)
Re[20]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Я к тому, что в ФП функция рассматривает несколько по другому нежели в "обычных языках". Это первоклассная сущность.
VD>Сори, а на кого направлен этот балшит? Может еще разведем балшит по повоту продвинутости структурного программирования в сравнении с ассемблерами?
Ты о чём вообще? Мы говорили о конкретной задаче и как она решается.
konsoletyper сказал, что не понимает устройство Parsec, я попытался дать основное, что в нём есть.
При чём тут ассемблер и структурное программирование?
VD>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?
И?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[18]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Без проблем! Меняем названия на EBNF-ные.
VD>На EBNF есть ISO-стандарт. Вот кода вы на Хаскеле его повторить сможете (ну, процентов так на 99 хотя бы), тогда можено будет поговорить. А пока тебе прийдется признать, что решение на Хаскеле не полноценно.
А в чём проблема? Я же сказал, что вплоть до переименования там подходит практически всё. (Практически, потому что цитировать стандарт не смогу, а лезть для сверки не хочу.) Мало того, есть дополнительные расширения.
В коде konsoletyper я заметил, что он тоже не пользуется ISO-шным стандартом. И правильно делает, нафиг делать ненужную работу. И пусть ты считаешь его решение неполноценным, по мне там всё ок.
L>>Нужны мозги, готовые писать декларативно.
VD>Хм. Решение на макросах получается короче и понятнее, но оно не декларативно? Забавные выводы.
Влад, с твоей логикой я уже знаком. Демонстрировать мне её ещё раз бесполезно.
Во первых, я не видел решения на макросах, поэтому сказать короче оно или понятнее не могу. Точно также не могу сказать декларативно оно или нет. Речь шла о том, что человек не понимает как написан Parsec, наверное он смотрел его код. Наверное, его что то смутило. Ничего сложного там нет, возможно человека всего лишь отпугнул синтаксис Хаскеля. Я попытался выяснить, что именно. Остальное додумала твоя безудержная фантазия.
VD>Ну, так не бери для сравнения Лисп. Старичку все же уже 50 лет! Возми Немерле. Он в большинстве случаев не уступает Хаскелю в выразительности сам по себе и при этом еще содержит макросы. В прочем все эти ТемлэйтХаскели и РеврайтРулезы ни что иное как маросы. Так что ты лучше обясни как решить конфликт между наличием этих фич и утверждением о том, что макросы не нужны. Это будет куда интереснее.
Я утверждал, что макросы не нужны??
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Тебе не кажется, что "очень близок" на практике означет "непохож"?
Нет.
VD>Понимаеш ли в чем дело?... На макросах можно получить как раз тот синтаксис что тебе требуется. И делается это проще.
Да, для создания синтаксиса макросы практически незаменимы. Я это уже говорил. И?
L>>Вместо "|" здесь "<|>", вместо +/* — many1/many, вместо '(' — char '(', "abc" — string "abc".
VD>Да, да... Вот только в лексере konsoletyper-а вместо "|" используется (ты не поверишь) "|" и т.д.
Да ты что? Ну, тогда я должен убегать — мне ещё надо переименовать <|> на |. Это ведь так сложно и займёт у меня целую неделю!
VD>Как раз в нашем случае это главный аргумент. Макросы гнобят за сложность. И за то что далеко не каждый их может использовать без вреда для здоровья. Но монады намного сложнее макросов. Они не очевидны. И резльтат получаемый с их помощью далеко не всегда тот что требуется програмисту. Тут тебе и ограничения, и низкая скорость. А вот макрос он тупо переписывает один код в другой. Причем этот другой код всегда будет таким как ты захочешь его видеть.
При чём тут монады?
L>>Поверь, для этого не надо вкуривать монады. Достаточно понять, что парсер это функция, дальше всё просто.
VD>Мне показалось он говорит о реализации.
Тебе правильно показалось.
L>>Так в том то и дело, что макросы не надо эмулировать, если язык позволяет обойтись без них.
VD>Макросы не надо эмулировать. Это правда. Они мощьнее чем вырктасы шаблонного МП в С++ и куда монад в Хаскеле. Они прямое средство переписывания кода так как надо программисту. И нихрена в этой области с ними не сравнится.
В области переписывания кода, не сравнится, да. И что? Как это относится к лексеру?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>> Даже для 2001. Очень-очень сомневаюсь, что это связано с тем, что реализация не на макросах. Надо с Happy сравнить. Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.
VD>Предлагаю запенисометрировать.
Не я. Времени катастрофически нет — сижу на твои посты отвечаю
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Для лексера необходимости в макросах нет. Погляди Parsec.
VD>Кстати, хорошее предложение. Предлагаю пенисомерию. Сравниваем Parsec с лексером konsoletyper-а. VD>На входе небольшой проект C#, на выходе количество токенов каждого типа в его файлах. VD>Как предложение?
Неинтересно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[20]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Сори, а на кого направлен этот балшит? Может еще разведем балшит по повоту продвинутости структурного программирования в сравнении с ассемблерами?
VD>Насколько я помню на свете есть очень мало языков в которых макросы достигли своего апогея. Все эти языки, как один, являются фунциональными (Лисп, Темлэйт Хаскель, Немерле). Так зачем нас грузить ФП?
Не все, есть еще Forth.
Re[10]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Что касается встраивания в язык DSL, то на Haskell это получается замечательно.
VD>Ну, вот мы уже видили убогие ивороты в Парсеке. Не уверен, но что-то мне подсказывает, что и скорость у Парсека тоже ни ахти какая.
Почему убогие?
L>> Просто там другой подход, и, разумеется, есть отличия от подхода с макросами.
VD>Дык о том и речь. Но МП оно и в африке МП и все претензии, что можно предявить к нему применимы как к макрам, так и к любым другим его видам. А вот результат... Он 100%-но более качественен у макр, да и понять решения на макросах, на мой взгляд, проще. В прочем, последнее утверждение конечно спорно. Но и первого хватет.
Тут не поспоришь. Непонятно одно. Почему ты всё не пишешь на макросах?
VD>Дык если что-то не умеет, начи уже менее мощьный. При этом еще и более сложный.
Нет. Перечитай. В Хаскеле надобность в макросах низкая за счёт того, что некоторые из проблем, решаемые макросами, решаются средствами самого языка. Решаются проще, а не сложнее.
VD>Что имеем в итоге? VD>1. Большую сложность реализации. VD>2. Меньшие возможности. VD>3. Меньшую скорость результирующего кода. VD>4. Все (гипотетические, так как на мой взгляд это домыслы) недостатки МП.
1. Почему большую сложность реализации? Инструмент использовать надо для того, для чего он предназначен.
Надо тебе нагенерить тучу кода — нагенерь макросами. Если же ты знаешь как избежать дублирования без макров, то зачем их использовать?
2. Почему меньшие возможности? Ровно те, что достаточны для решения задачи.
3. Проблема производительности решается не только макросами, честное пионерское.
4. Э? Какие недостатки ты имеешь в виду?
VD>Ну, и где здесь приемущества? Отсутсвие слова "макросы"? Ахринеть (с)!
Ты не знаешь, что у макросов есть недостатки, которых нет у штатных конструкций языка?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
D>>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez
VD>А в чем разница между ними и макросами? И почему тогда "макросы сакс", а "Rewrite Rules rulez", а?
Макросы генерят код по поименованному определению макроса. Это имя используется в коде для вызова макроса компилером.
Рулесы делают трансформацию без поименований с уже имеющимися функциями. Компилер находит шаблоны и меняет их.
Допустим, x $ y z => x (y z) можно сделать макросом.
А вот как сделать трансформацию map f . map g => map (f . g) макросом я не представляю.
Таким образом, с помощью рулесов можно писать обычный "красиво выглядящий" код с обычными функциями, которые трансформируется в оптимизированный.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
L>>Подозреваю, ... За исключением...По идее...Не знаю, сработает ли здесь.
VD>Что я могу скзать? Может в этом и состоит разница? Вот я, например, не сомневаюсь, что все тоже самое с соблюдением синтаксиса можно залудить средствами макросов Немерла и при этом плучить настолько оптимальный код насколько его вообще можно получить на Немерле (т.е. не отличающийся от оптимального рукописного кода). А ты сомневашся. И сомнения твои вызваны неполноценностью средства, сложностю и тормознутостью самого языка.
Слава макросам Немерле!
Я не сомневаюсь. Я просто не знаю, как работает оптимизатор. Предполагаю, что он может это сделать. Ручаться не могу, т.к. в этом вопросе не компетентен. А не потому что язык неполноценный, сложный или тормознутый.
Будет время — проверю. Моя же мысль такая — и это можно сделать без макросов и без изворотов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, deniok, Вы писали:
D>>Кстати здорово — задача оптимизации решается прямым указанием оптимизатору! Rewrite Rules rulez
VD>А в чем разница между ними и макросами? И почему тогда "макросы сакс", а "Rewrite Rules rulez", а?
Rewrite Rules это способ явно записать указания компилятору для оптимизаций. Это — открытый интерфейс оптимизатора конкретного компилятора, GHC, а не часть языка. При этом, правда, правила записываются фактически на том же языке.
Про "макросы сакс" я не говорил, я говорил, что DSLи, в принципе, можно строить и без макросов. Вообще термин DSL, по-моему, не очень хорошо определён.
DSL встроенный в язык — это одно. Здесь мы не можем определять синтаксических конструкций, конфликтующих с синтаксисом исходного языка. Если какое-то ключевое слово основного языка необходимо в DSL'е и должно в нём использоваться по-другому — придётся извращаться (скажем, вместо if писать ifMy).
А отдельный DSL c отдельным интерпретатором — это немножко другая история, мы ведь не о них говорим?
Re[7]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, VladD2, Вы писали:
L>>Вон konsoletyper написал код для парсинга JSON-а. Повтори на Парсеке — будет практически один в один.
VD>Повтори — сравним. Как по выразительности, так и по скорости. А там видно бдет. ОК?
Да блин замени <|> на |.
Тебя, я так понимаю, это больше всего смущает?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, FR, Вы писали:
FR>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
С проблемами.
Например такой вот пример из Blitz++ (прямо из мануала)
Array<float,1> x(4), y(4);
Array<float,2> A(4,4);
A = cos(x(tensor::i)) * sin(y(tensor::j));
Посчитает и sin и cos по 16 раз, хотя нужно по 4. Писать библиотеку с такими оптимизациями на C++ не очень весело. С макросами такая задача все-таки более реальна.
... << 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[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>В доке от 2001 года говорится, что L>
L>Speed. Most combinator libraries lack the speed necessary to be competetive with bottom-up parser generators. Parsec uses some novel techniques to improve its performance. The library is fast, parsing thousands of lines a second on today's machines
L>Но тысячи в секунду, это как то маловато, если честно. Даже для 2001.
Я это и сам читал в свое время. Конечно, утверждение про thousands of lines отбивает охоту смотреть сравнения, но мне все равно интересно.
L>Полагаю, проблема всё таки в строках Haskell-а, которые как известно, медленные. Можно попробовать подключить binary string и померить.
PackedString что-ли? Это возможно? К ним же стандартные списковые функции применять нельзя. (Ну почему в Haskell нет класса типов List?!) И придется слишком многое переписывать, нет? Это более чем сомнительное удовольствие.
К тому же лично мне не понятно, почему Parsec так написан? Вообще-то производительность лексера и парсера имеет значение. Это же вроде бы не просто proof-of-concept, он позиционируется как построитель парсеров пригодный для реального использования. Кроме того, он еще и объявлен быстрым. Слово "fast" — даже в заголовок описания вынесено. Это шутка?
... << 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]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, FR, Вы писали:
FR>>Разве обошлись, вроде в тех же запросах используются именно ленивое вычисление параметров. К>Аргументируй, не вижу там ничего ленивого, или наличие ф-ции, которая вызывает/выполняет DSL и есть такая ленивость?
Просто без ленивости (или макросов) такие DSL не сделать. Помните упражнение из SICP про самописный if и вечный цикл?
Вот и в Scala используется ленивость, а точнее non strict. Об этом и здесь
