Здравствуйте, IT, Вы писали:
C>>Добавь к "компилятору" еще и "инспектор" (который можно запускать отдельно от IDE, кстати). IT>А почему к компилятору просто не добавить нормальную систему расширения? Ведь твой инспектор как раз и занимается тем, что пытается расширяет возможности компилятора на свой лад, делает за него какие-то дополнительные проверки и т.п.
Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется.
IT>Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор.
А ты не забываешь запустить компиляцию перед запуском приложения?
IT>А кто будет инспектировать инспектора?
Инспектор
Sapienti sat!
Re[55]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Cyberax, Вы писали:
C>Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется.
Так просто не используй макрос, написанный индусами
IT>>Но по сути это же просто обыкновенная затычка. Теперь оказывается нужно не только компилятор запускать, но ещё перед ним не забыть запустить инспектор. C>А ты не забываешь запустить компиляцию перед запуском приложения?
Нет, это необходимый минимум, чтобы получить запускаемый код. Компилятор + инспектор не минимальный набор, следовательно всегда существует возможность использовать минимальный, чем твои индусы обязательно воспользуются.
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, Cyberax, Вы писали:
C>Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется.
А в чём принципиальная разница с индусской библиотекой?
Кстати, ты себе представляешь сколько в стандартной явовской библиотеке индусского кода?
Здравствуйте, cl-user, Вы писали:
CU>>>Гибкость — да, скорость — нет.
FR>>Скорость и близость к железу не всегда совпадают
CU>А нафиг "близость к железу", если она не даёт скорость? Для самоудовлетворения?
Здравствуйте, mkizub, Вы писали:
C>>Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется. M>А в чём принципиальная разница с индусской библиотекой?
В ее влиянии на приложение. Влияние библиотеки более-менее ограничено (особенно в Java, где нет проблем С++) — так что ее не так страшно использовать.
Естественно, есть исключения типа AOP-подобных библиотек, занимающихся креативным творчеством с байт-кодом. Но я их стараюсь использовать по минимуму.
M>Кстати, ты себе представляешь сколько в стандартной явовской библиотеке индусского кода?
На JRE мне пофиг — ее используют миллионы человек и большая часть багов находится и исправляется быстро. Если это не баги в дизайне.
Sapienti sat!
Re[56]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, IT, Вы писали:
C>>Потому как я не хочу разбираться с тем, что наделали индусы, дорвавшиеся до макросов. Если им захочется написать свою инспекцию — пожалуйста, нет проблем. Я ее просто у себя отключу, если мне захочется. IT>Так просто не используй макрос, написанный индусами
А ты просто не используй Windows. Какие проблемы-то?
Нам (я, как начальник, спихнул это ) приходится поддерживать код клиентов для интеграции наших систем. Так что индусокода я вижу тонны.
C>>А ты не забываешь запустить компиляцию перед запуском приложения? IT>Нет, это необходимый минимум, чтобы получить запускаемый код. Компилятор + инспектор не минимальный набор, следовательно всегда существует возможность использовать минимальный, чем твои индусы обязательно воспользуются.
Пусть. Ошибки в запросах обнаружаться в виде исключений при тестировании. Да, это не приятно, но прекрасно локализуемо и легкоисправимо. Кроме того, Я САМ буду запускать инспекции — и найду эти ошибки (у нас в процедуре релиза, кстати, предусмотрена автоматическая проверка).
А вот индусские макросы — это намного хуже. Они мне затрудняют поддержку кода и поиск ошибок (которые будут).
Sapienti sat!
Re[57]: Являются ли макросы свидетельством недостаточной выр
Для начала одни небольшой офтоповый вопрос. Зачем так тщательно выписывать большие буквы в абривиатурах плюя на них в начале предложений? Ведь если влом писать большие буквы в начале предложений, то надо быть последовательным и не писать их в абриваитарах. Да и я зык перекючать... тоже задача нелегкая. И уж если ты это все делаешь, то почему бы все же не делать первые буквы предложений заглавными? Ей богу будет проще читать.
BZ>вопрос был в том, почему опыт в реализации "стандарный и универсальный скриптовый язык" делает ошибочными утверждения относящиеся к DSL.
Ну, это совсем просто. Это зачатки логического мышления. Ведь тебе не кажется нормальным доказателство, скажем, того что уж колюч на том основании, что ёж колчю, а и тот и другой являются жувотными? Ну, вот и мне странно слышать подобное о GPL и DSL.
BZ> кроме того, по-моему, DSL вовсе не обязан быть узким языком.
Не скажем. Лучше скажем, что Lua является типичнейшим представителем GPL.
BZ> имхо их отличает только то, что реализация языка является только частью общей решаемой задачи, тогда как для колмпилятора это единственная решаемая задача. с этой точки зрения компилятор delphi, встроенный в среду разработки — это тоже DSL
Ты просто невладеешь терминалогией.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[27]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Нет, компилятор неоднозначности не найдёт. Ты же о компиляторе Хаскеля? Не думаю, что он умеет определять, что в строках "public", "private" и "protected" все слова начинаются на одну букву
L>Сам же парсер выдаёт либо сообщение о несработавшем комбинаторе (если поставить явный <?>). Либо говорит о том, что ожидается то-то, а найдено то-то.
Меня и интересует что увидит конечный пользователь и/или создатель парсера. В идеале (который как раз обеспечивается макросами) создатель парсера должен получить предупреждение о том, что грамматика не удовлетворяет ограничениям своейственным для выбранного метода разбора и ее нужно изменить.
Как я понял в случае с Парсеком мы просто получим некорректный парсер. Так?
L>Так у С# грамматика должна быть не маленькая верно?
Дык она уже есть. Если задача просто ко контексту символы заменить, то это работа на 10-20 минут.
L>Ясно. Я думал, тебя производительность интересовала в первую очередь.
Она мне нитересна, конечно. Но это только один вопрос. А их несколько. Вот в начале этого собщения мы говорим о логике постраителя парсера. Это мне тоже очень интересно. Потом интересна отладка. Да и просто поглядеть на то во что выльется грамматика интересно.
А то абстрано у всех все здорово и красиво. А вот на прктике что-то проблемы вылезают.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, BulatZiganshin, Вы писали:
VD>>"Byte" означает то о чем я подумал, и Юникод Хаскелю незнаком?
BZ>не хаскелю, а байтовым строкам. интересно, ты вообще хоть что-нибудь читаешь из всех ссылок, что тебе приводят?
А что встренные строки Хаскеля поддерживают Юникод?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
VD>>Ты бы попробовал, а потом обсудили бы. А то как-то не смешно. Я вот попробовал и готов потратить время на изучение, чтобы не испытывать тех проблем, что есть с тулзами вроде flex-а.
G>Я пробовал. И могу сказать, что реальная необходимость писать сложные лексеры-парсеры до такой степени редка в моей работе, что я не буду выбирать язык по критерию чтобы он круто позволял такие задачи решать.
Выделим тут суть "в моей работе". Надеюсь, ты понимашь, что в чужой работе это может быть не так. Да и в втоей работеЮ, возможно, это так именно именно потому что это сложно. Бло бы легко, может быть ты как раз по чаще пытался бы делать новые языки.
Вон в том же С++ пока Александреску не придумал как приспособить систему типов для нужд метапрограммирования тоже мало кто внешние мета-решения городил. Но после того как эти идеи оформили в Бусте многие стали применять их на право и на лево.
G> Это глупость. Я лучше в том редком случае, когда надо что-то сложное разобрать, воспользуюсь flex/byson или подобными.
Дык и убьёшь море времени. Плюс сузишь количество случаев когда ты решишся на разработку нового языка. Ну, и последним гвоздем в крышку гроба водруженной над этой идей будет, то что ты не сможешь легко интегрировать этот язык в свой основной ЯП. А без этого многие ДСЛ будут неудобны. В итоге для тебя DSL как дизайнерское решение является исключительной экзотикой. А я вот на сегодя рассматриваю его как вполне себе реальное решение. Легко создать. Легко воспользоваться. Легко отладить. Легко внердить...
G>А вот если я провожу масштабные исследования в области языков и компиляторов, то тогда да.
Эта другая область. Довольн узкая. Мы все же говорил о ДСЛ-ях, а не о полноценных языках.
G> Тогда я воспользуюсь каким-нибудь OCaml — он позволяет клево с языковыми расширениями играться, в том числе и на чужой, не окамловкой грамматике.
Вообще-то он довольно гораничен в этом лане. Там толко лексический препроцессор. По крайней мере особых преимущество по срвнению с макросам, и темболее по сравнению с файтически встренным flex-ом (да еще и с человеческим лицом) нет. В прочем, это все равно будет проще чем возня с flex-ом.
G> Это свойство мне существенно съекономит время. Тем более, что есть замечательная книга — Compilers Construction with ML с примерами, которую можно почитать и новичкам потом дать.
О, да. Книга несомненно позволит скоротать вечерок другой .
В общем, не о том речь.
G>Только я в своей работе не провожу исследований в области языков и компиляторов.
Я, как не странно, тоже. Я просто хочу сделать свою среду разработку более высокоуровневой.
G> Поэтому я в крайней и редкой ситуации — когда припрет — воспользуюсь flex и bison. Чем офигенно обрадую тех людей, кто будет потом разбираться в моем коде — они его поймут.
Тем самым ты понизишь уровень разработки и накажешь тех самых людей.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, Gaperton, Вы писали:
G>Приведи мне пример паттерна, который будет строиться на базе ФВП и паттернматчинга, и покажи, как ты его макросом обернешь.
Возможно неплохим примером будет оператор foreach из Nemerle. О его возможностях можно прочесть тут
Здравствуйте, BulatZiganshin, Вы писали:
VD>>Оба недостатка будут у любого средства ДСЛ-естроения.
BZ>похоже, ты путаешь DSL и eDSL. DSL — это просто любой язык, интерепретатор/компилятор которого ты реализуешь. embedded DSL — это DSL, реализованный как расширение твоего ЯП.
Нет. DSL — это ограниченный язык решающий узкий список проблем предметной области.
BZ> через доп. функции, классы, макросы и т.д. т.е. библиотека матричных операций — это уже eDSL. а скажем, любой язык, реализуемый с помощью ParseC — это DSL, но при этом сам ParseC реализует eDSL для описания грамматик
Нет. Не любой. Думаю, что Парсек может справиться и с С++ (скажем). От этого С++ DSL-ем не становится. Он по прежнему останется GPL.
BZ>ещё примеры: всякие boost::lambda — это eDSL функционального программирования внутри C++, а byson или regexps — это средства создания DSL
"eDSL функционального программирования" — это оксюморон. ФП — это уже General Purpose...
boost::lambda — это пример эмуляции полезной фичи на базе бесполезной. В прочем, если я не ошибаюсь, то boost::lambda даже примером метапрограммирования не является. Это чистый пример обобщенного программирования.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Являются ли макросы свидетельством недостаточной выр
Да, пожалуй, пойдет.
VD>>Грамматика была в виде глобального метаатрибута. Что-то типа:
L>Прикольное решение. А в виде чего тогда приходит на макрос BNF параметр после lexer/parser внутри фигурных скобок?
Это главная фича. "Кода в скобках" попросту нет! На выходе мы получаем список/поток вариантов описывающих грамматические конструкции. Ну, а далее мы прсото анализируем их средствами паттерн-матчинга. В итоге получаем полное отделение описания грамматики от действий предпринимаемых при распозновании тех или иных конструкций.
Минус только один — нельзя императивно вмешаться в ход работы парсера, а значит если парсер неспособен распознать некий класс крамматик, то черного хода для объода этого ограничения не будет. Плюсы — все остальное. Полна развязка грамматики и реакции дает нам небывалую простоту правки грамматики и при этом мы все же получаем контроль компилятора за кодом обработки.
VD>>При этом изменение грамматики автоматически перестраивает генерируемые алгеброические типы, так что сразу доступен комплит-ворд и диагностика ошибок (без какой либо добполниетльной роботы по этому поводу).
L>Не понял, как он ловит ambiguity?
Выдает сообщения об ошибках — вестимо. Это же настоящий генератор парсеров завуалированный под DSEL.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: Являются ли макросы свидетельством недостаточной выра
Здравствуйте, lomeo, Вы писали:
L>Разумеется, gmap проходит по всем узлам, поэтому он медленный. Для ускорения можно и исключить ветки из просмотра (правда, чисто это будет, насколько я знаю, только для определённых случаев — для этого варианта не делаем, а для этого делаем), можно решить и циклы. У тебя разве по другому?
У меня универсальный механизм компайл-тайм рефлексии и средсва прмого генерирования кода. С их помощью создание частных, всокопопроизводительных случаев дело времени и техники.
Собственно мне и хочетс увидить такие же гибкие механизмы без макросов.
L>Э-э-э... А зачем Хаскелю интеграция с VS?
А зачем вообще сам Хаскель? Вопрос из той же серии.
У меня на твой вопрос два ответа.
1. Это нельзя объяснить тем кто работает каменным молотком. Без обид. IDE с хорошим редактором, интергрированной отладкой, навигацией по коду, автодополнению при вводе, визардами, рефакторингом и т.п. давно стали стандартами дефактов в промышленной разработке ПО. И без них самые крутые языки дают просто черепашю производительность.
2. Спрос это у тех кто делает эту интеграцию.
VD>>Согласен. Конечно наличие чудо gmap — это несоменно полезно. Вот только ты прав и в том, что на все случи жизни не напасешся. И тот же gmap отлично можно было бы реализовать на макросах.
L>Зачем, если он реализуется средствами языка?... L>... L>
L>data X = X (Maybe Int) deriving (Typeable, Data, Show)
>> everywhere (mkT (\x -> x + 1 :: Int)) (X (Just 1))
L>X (Just 2)
L>
ОК. То есть мы ведем речь по сути о полиморфном решении проблемы и пользуемся тем фактом, что полиморфизм в Хаскеле определяется классами типами которые являются эдакими аналогами внешних интерфейсов Явы.
Сразу пояляется две вароса.
1. Это только мне кажется все слишком запутанным, а всем мало-мальски знакомым с Хаскелем все очевидно? Например, я так и не понял как этот волшебный deriving объясняет компилятору как отображать поля некой записи (или как там составные типы в Хаскеле обзывают?). Что при этом происходит со встроенными типами вроде кортежа? В общем, откровенно говоря я так и не вкурил тонкостей. Мне все это кажется магией (т.е. содержит много необъясненных моментов).
2. Что делать если в каких-то частных случаях нужно сделать частный алгоритм обхода? Ну, как с тем же зацикливаением бороться?
VD>>В общем, gmap — это ХОРОШО! Но лучше если он создан в виде макроса. Чтобы можно было бы создать на его основе специализированную версию. Да и вообще, чтобы на языке можно было создавать подобные вещию.
L>Не понимаю, чем лучше, если он создан в виде макроса.
Не, ну, если он делается штатными средствами языка и без магии, то это тоже неплохо. Просто пока что я так и не понял как генерируются специализации для этого Typeable.
L> Тут вроде речь о том, что если язык достаточно мощный и имеет средства, заменяющие макросы (например те же derivable type classes), то зачем нужны макросы (для решения этих задач, разумеется)?
Дык маросы это и есть такие средства. Точнее не сами макросы, а их реализация. Просто в случае с макросами для меня все намного очевиднее. Я просто имею API статической рефлексии (т.е. API позволяющий читать описание типов в компилируемом проекте). С его помощью я могу сгенерировать специализированный код любой сложности (от gmap, до частных случаев вроде описанного мной).
У этого подхода есть как приемущества так и недостатки. Приемущетсва: гибкость, наивысшая скорость получаемого кода, прямолянейность реализации. Недостатки... пожалуй он один, но глобальный — это компайлатайм-решение. И оно не может применяться для типов о которых неизвестно во время компиляции (например, о типах из динамически подключаемых библиотек).
L>Тут в чём прикол. В Хаскеле рефлексия сделана интересно. Ты сам определяешь для каких типов она есть, а для каких нет. Рефлексия конкретного типа -- это просто экземпляр класса Typeable, в котором ты наопределял (или Хаскель сам вывел) нужные тебе комбинаторы.
Можно об этом по продробнее? И особенно о том как можно совместить генерируемые компилятором сущности (ну, там Typeable и т.п.) с custom-кодом который нужен прикладному программисту.
Ну, скажем простейшая задача. Хочу сгенерировать некий код для Х типов меня в нем код функции в зависимости от тех или иных условий. Ну, скажем если в типе есть строки, то вывести их на консоль, а если нет, то ничего не делать.
VD>>Работать будет на ура, но медленно, а значит не всегда приемлемо.
L>Медленно рефлексия работает из-за рефлексивного вызова функции? Так в SYB этого нет.
Ктр такрй SYB?
L>Ты погляди -- это же тупой визитор.
Может быть, может быть... Но хотелось бы глянуть на реальном тесте. Да и объяснения "природы" более подробнрые не помешали бы.
VD>>Возможно в каких-то языках его аналог можно будет создат не базе компайлтайм-рефлексии. Но без подобных средств создать gmap мне не представляется возможным.
L>Проверяем — наш ли тип — нет, спускаемся к его полям, да — выполняем функцию.
Хм... Одно "но". Не выполняем (это уже динамическая рефлексия), а генерируем. Чувствуещь разницу? Выполнение по условию в рантайме это немного не то. И гибкость не та, и скрость фиговая.
L>Проход всё равно будет по всем узлам (пока мы руками не ограничим, разумеется) — но в этом смысл gmap.
Еще раз...
1. Когда производится анализ содержимого типа? В рантайме или в компайлатайме? Т.е. генерируется ли компилятором код вроде:
x = X(y.a, y.b) // в терминах явы
или происходит какая-то магия в рантайме?
2. Как можно вмешаться "руками"?
VD>>А многие нуждаются в создании подобных магических фунций. И не телько. Кому-то просто хочется сделать синтаксис именно таким как он видит. А кто-то хочет интегрировать в свои программы некий фрэймворк. В общем, бесспорно, что если имеется отлично подходящие средства встроенные в язык, то лучше выбирать их, а не заниматься самодеятельностью и клепать макросы. Но макросы иметь тоже нужно. Иначе рано или поздно прийдется идти на компромисы и довольствоваться огрызками с барского стола.
L>С этим спорить не буду.
Дык, а эта тема о чем тогда?
Лично я, со своей стороны, так же не буду спорить, что если в языке есть встроенные и при этом достаточно выразительные средтсва решающие задачу без "но", то лучше использовать их. Ну, глупо ведь создавать альтернативные фунции или операторы если они имеют ту же фунциональность, что и аналоги из языка. Но ведь не всегда они есть.
BZ>>>то же самое относится и к немерле или хаскелю — случаи, когда приходится применять макросы, высвечивают недостатки языка.
VD>>Согласен.
L>О! Тема топика, кстати.
А ты не выдирай цитаты из контекста .
L>Эх! Если бы это всегда было возможно. Как на макросах в Хаскеле тот же cast сделаешь (быстрый)? Никак, базовых средств недостаточно.
Значит такие макросы.
VD>>DSL-и — это отдельная область. И для их строителсьтва макросы вседа будут идеальным решением.
L>Ну слишком категорично. Вот на руби обходятся без макросов (мы же про DSEL?)
Руби, Питон и ЯваСкрипт — это скрипыт. Скрпты до мозга костей. Их методы метапрограммирования на прочь убивают любые потуги в лпане повышения производительности (компиляции), надежности (статические проверки) и поддерживаемости.
Хаскель все же является типичным представителем статически типизированных, компилируемых языков. И в этом плане его подходы к метапрограммированию интересно сравнить с макросами.
L>gmap может создать любой смертный. Средствами по мне более простыми нежели макросы.
На счет просты — вопрос спорный. Я вот так и не понял мноих аспектов реализации. Хотя похоже на счет gmap я ошибся. Но что-то мне кажется, что в описанинии gmap приведенном тут содержатся "чудесные" средства. То есть нечто, что нельзя сделать если ты не создатель компиляора. Макрсоы же это четко детерминированные средства развития компилятора. Минимальный АПИ который позволяет создавать "чудесные вещи" вроде gmap. Причем, что немаловажно, позволяют любому смертному.
VD>>Я не очень понял что значит "управляющие стурктуры". Посему не могу об этом рассуждать. С точки зрения манипуляции функциями Хаскель мало чем отличается от Немерле.
L>Да и вообще все языки Тьюринг-полные
Лучше бы объяснил термин.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Являются ли макросы свидетельством недостаточной выр
Здравствуйте, lomeo, Вы писали:
L>Так! Парсер написал.
Здорво!
L>Думал дольше времени уйдёт, наверное, рука набита
Вот и я о том же. Больше споров...
L>Если у тебя есть установленный Haskell, то это сообщение можешь просто скопировать в файл, обозвать его, дав ему расширение lhs, и запустить.
К сожалению, нет. Но готов поставить если будут четки инструкции "чего и скока?". За одно многие другие смогут приобщиться.
L>...
А можно увидить все это в целом? Ну, чтобы с оригиналом сравнить?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[59]: Являются ли макросы свидетельством недостаточной выр
Если нам не помогут, то мы тоже никого не пощадим.
В виде списка... в текстовом файле
Кто-нибудь там поближе, киньте в этого маньяка чем-нибудь тяжёлым!
