Здравствуйте, WolfHound, Вы писали:
G>>А лексо-яко-подобные тулзы никак нам в этом не помогут, да? WH>На макросах в подавляющем большинстве случаев гооораздо проще. WH>Вернее даже так: Я не представляю когда лексо-яки при создании ДСЛ будут лучше.
По мне, так главный плюс макросов в том, что помимо созданного DSL у программиста остаётся "под руками" весь "исходный" язык. В случае создания DSL "самого в себе" придётся строить язык _полностью_, а с макросами достаточно реализовать недостающее.
Re[17]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Gaperton, Вы писали:
FR>>>Так что думаю на любой функциональный язык перепишется.
G>>Ну, это все-таки жесть В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.
FR>Ты сходи по ссылке, нет там императивщины.
Я знаю. Эта ссылка проходила в одной дискуссии в декларативном программировании. Мне еще тогда не понравилось, как там сделано. Мне кажется, сделать классы на схеме с императивщиной (выразить через замыкания на общих переменных) должно быть проще. Am I wrong?
Re[12]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Gaperton, Вы писали:
G>>А лексо-яко-подобные тулзы никак нам в этом не помогут, да? WH>На макросах в подавляющем большинстве случаев гооораздо проще. WH>Вернее даже так: Я не представляю когда лексо-яки при создании ДСЛ будут лучше. WH>Может приведешь пример?
Когда тебе нужен скриптовый DSL, чтобы интерпретироваться в рантайме. Например — тебе надо написать веб-браузер с поддержкой JavaScript.
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Когда тебе нужен скриптовый DSL, чтобы интерпретироваться в рантайме. Например — тебе надо написать веб-браузер с поддержкой JavaScript.
Жабаскрип имеет слишком большие возможности для ДСЛ. Ибо на нем можно писать далеко не только браузерные скрипты.
Под ДСЛ обычно понимают очень узкоспециализированный язык заточенный под одну конкретную задачу. Не больше и не меньше. Как правило ДСЛи даже не полны по Тьюрингу.
Хотя даже если мне будет нужен жабаскрипт то я скорей всего не стану связываться с лексо-яками ибо геморойно очень, а выхлоп есть только если использовать языки типа C/C++/C#/Java.
А если язык болие мощьный то проще без них.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, WolfHound, Вы писали:
G>>Когда тебе нужен скриптовый DSL, чтобы интерпретироваться в рантайме. Например — тебе надо написать веб-браузер с поддержкой JavaScript. WH>Жабаскрип имеет слишком большие возможности для ДСЛ. Ибо на нем можно писать далеко не только браузерные скрипты. WH>Под ДСЛ обычно понимают очень узкоспециализированный язык заточенный под одну конкретную задачу. Не больше и не меньше. Как правило ДСЛи даже не полны по Тьюрингу.
какая разница, тьюринг-полный он или нет. Ровным счетом никакой. Рассмотри любой пример, когда тебе надо в рантайме подцеплять и интерпретировать описание на специальном языке. Например — веб-браузер. И все — макросы — до свидания.
WH>Хотя даже если мне будет нужен жабаскрипт то я скорей всего не стану связываться с лексо-яками ибо геморойно очень, а выхлоп есть только если использовать языки типа C/C++/C#/Java. WH>А если язык болие мощьный то проще без них.
Это я вообще не понял. Что за выхлоп, почему проще без lex-yacc, почему геморройно с генераторами парсеров, чем без них. Странно как-то то все звучит.
Re[14]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Гуру из нашей С++ конфы говорят, что есть в библиотеке Blitz++, а вообще решение искать надо по словам expression templates. Сразу предупреждаю — это очень злой С++. Но если попривыкнуть — то там, в сущности, все понятно .
В общем, да, разобрался, спасибо.
Подозреваю, что такое можно сделать на GHC. За исключением того, что приведение будет явным: toVector (v1 + v2 + v3).
Т.е. строится обычный декоратор, как и в примере, функции инлайнятся до toVector включительно, чтобы получить для vs[i] обычное выражение для элементов. Удалится ли конструктор декоратора при специализации toVector — не знаю, надо проверять.
По идее в оптимизаторе была трансформация
foo = \x -> C x
bar = \C x -> f x
bar . foo => \x -> f x
Не знаю, сработает ли здесь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>какая разница, тьюринг-полный он или нет. Ровным счетом никакой. Рассмотри любой пример, когда тебе надо в рантайме подцеплять и интерпретировать описание на специальном языке. Например — веб-браузер. И все — макросы — до свидания.
А если не надо? А случаев когда не надо гораздо больше.
Так что попытка обосновать не нужнось макросов наличием жабаскрипта идет лесом.
Болие того я спокойно могу на лету скомпилить код на томже немерле... с макросами...
G>Это я вообще не понял. Что за выхлоп, почему проще без lex-yacc, почему геморройно с генераторами парсеров, чем без них. Странно как-то то все звучит.
То и значит.
Лексаяки рулят если нужно написать компилятор на тупом языке типа C/C++/C# но если в языке есть алгебраические типы, сравнение с образцом, ФВП, макросы итп то от лексаяков пользы нет.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, konsoletyper, Вы писали:
K> И подоступнее, а то там чёрт ногу сломит.
Кстати, одина из основных претензий к макросам — это как раз то, что в них черт ногу сломит. Собственно лично мне кажется, что ломать ноги, скажем в монадах, куда проще. Так что большой вопрос что является большим злом макросы или монады.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
VD>Дык, макросы и нужны для языковых расширений. 90% применения в прикладном коде для макросов, на мой взгляд, — это DSL-и. Остальные 10% — это допиливание языка напильником для применения в конкретной сфере. Это допиливание легко ложится в библиотеки и может просто пополнять язык (делая его удобнее для конкретных областей применения).
То есть, макросы нужны только для DSEL.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, thesz, Вы писали:
T>То есть, макросы нужны только для DSEL.
В большинстве случаев — да. Хотя конечно это отличное средство для развития самого языка (упрощает компилятор в разы). Кроме того макросы являются отличным средством оптимизации.
Но DSEL — это то где макры являютс просто идеальным решением и все остальные по сравнению с ними курят. В том числе и внешение DSL-и (слишком сложно их создавать).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, Andrei N.Sobchuck, Вы писали:
VD>>Ничего они не позволяют решать. В Смолтоке используется самая поганая система метапрограммирования из известных человечеству — генерация исходного текста и компиляция его на лету. Метаклассы лишь приятный бонус инкапсулирующий паттерны вроде абстракных фабрик. Свми по себе метаклассы метапрограммирования не предоставляют.
ANS>Белая гарячка
у вас, маньяков? Несомненно. Вы же даже возразить аргументированно не умеете.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, c-smile, Вы писали:
CS>Я согласен с тем что язык программирвания должен быть адекватен задаче. CS>Но в системах где язык строится под задачу мы имеем проблему обучения — освоение превращается в нетривиальную и постоянно меняющуюся задачу.
Перечисли, пожалуйста, проекты в кторых ты создавал языки под задачи и обучал этим языкам других сотрдников. Ну, а если не сможешь, то подумай о том, что рассуждаешь о том, в чем ничего не понимаешь.
DSL-и принципиально проще чем унивирсальные языки. И учить из заранее не надо. Когда человек сталкивается с новой предметной областью, то изучение специального микро-языка является самым малым, что ему требуется изучить. Причем если ему не прийдестя учить этот микро-яызык, то он будет изучать библиотеки облегчающие решение задачи (что как минимум не проще), а потом пытаться писать код которые будет совершенно точно занчительно более сложным и ниуклюжим нежели код на специализированном языке. А если он решит не использовать ни ДСЛ-и, ни библиотеки, то он будет вынжден или создать библиотеки самостоятельно, или вообще нагородить море дублирующегося кода и с вероятностью 99% завалить проект.
CS>В результате получается...
Сори, о результатх я предпочел бы говорить с теми кто пробовал это делать. Ты же ясвно в это число не входишь.
CS>Я думаю что можно говорить о том что BISON/YACC + С есть некий супер-мета-язык.
Вообще-то язык называется BNF. Наличие вставок на любм языке никак не меняют этот язык. Хорошо, что ты понимаешь, что BNF — это классический пример DSL-я. Но жаль, что ты не понимашь, что ты не понимашь, что это просто частный их случай.
CS>Такой подход в котором мухи с котлетами отдельно подчас более честный что-ли.
А что там отделено, то? Там как раз довольно глупо все намешано. Вот погляди
как тоже самое реализовал konsoletyper на Немерле. Вот это действительно отделение мух от котлет. С помощью EBNF описывается чистая грамматика. На ее базе генерируется набор алгебраических типов (вариантов), и уже они разбираются прикладной логикой, которая и делает все что нужно. Это позволяет читать чистую грамматику с одной стороны, и обрабатывать любые тонкости разобранного представления с другой. То есть, действительно, котлеты и мухи отделены по полной порограмме.
Дополнительные бенефиты такого подхода заключается в том, что при изменении грамматики автоматически перегенерируются варианты, что с одной стороны приводит к тому, что все разбираемые конструкции доступны в интелисенсе, а с другой к тому, что правильность кода контролируется в реальном времени (ошибки просто подсвечиваются в IDE).
BISON/YACC нервно курят в сторнке. Он просто прошлый век. С подобным решением может тягаться только специализированная IDE вроде той, что разрабатывается для ANTLR 3. Вот только трудозатраты тут уже несопоставимы. Если для парсинга такую IDE написать могут, то для прикладной задачи — это уже будет совершенно неподемная задача. А тут все в автомате. Да и специализированную поддержку для решения на макросах тоже можно сделать. Причем это будет значительно проще нежели создавать специализированную IDE с нуля.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Курилка, Вы писали:
VD>>Любой DSL.
К>Ммм, значит DSL на хаскеле или скале "не считаются"?
Считается. Но они получаются слишком ограниченные в сравнении с прмыми решениями. В прочем, причем тут Скала вообще не ясно. Там система типов мало чем не отличается от Ява/Шарпа.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
VD>>Любой DSL.
G>А лексо-яко-подобные тулзы никак нам в этом не помогут, да?
А это и есть вариант DSL-ей. Только внешних. Это если говорить о самом [E]BNF.
Если же ты говоришь о разработке DSL-ей с помощью "лексо-яко-подобные тулзов", то ты явно не покопался с макросами или покапался слишком мало. Это просто несопоставимые по объему и сложности работ средства. Макросы позволяют задействавать огромную инфрастуруктуру основного языка и его компилятора. Создвая язык с нуля, ты вынужден все до последнего винтика создать самостоятельно.
Здравствуйте, FR, Вы писали:
FR>На C++ шаблонах такое пишется без проблем, используются ленивые вычиления, то есть выражение собирается в operator= скорость не уступает сишной.
Решение конечно на шаблонах с применением Буста?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В схеме можно и замыкания с деструктивными присваиваниями использовать — должно быть проще.
Хочется всего и сразу.
