Здравствуйте, Cyberax, Вы писали:
C>Если для парсинга придется руками писать автоматы, то я заранее уже не хочу это использовать
Там делов то
C>Это я знаю. С другой стороны, если можно будет обойтись вообще вместо ручного написания парсера — то мне будет примерно пофиг что там у него внутри за неонка будет.
Парсинг — это не самое страшное.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[44]: Как скрестить ужа и ежа или статическую и утиные тип
FR>>Конечно, и в этой сути ничего ни говорится о том что нельзя делать статическую (времени комиляции) фабрику, которую я и сделал на D. FR>>Нормальную динамическую попробую позже сделать.
IT>А какой смысл от такой фабрики? Кроме пенисометрии, конечно.
Для меня смысл простой изучение D
Re[35]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, VladD2, Вы писали:
VD>Это не так. С заглядываниями вперед LL(k)-парсеры могут распознавать такие же грамматки если не больше.
При k стремящемся к бесконечности, да. А вот при конечном k выразительная мощность всегда будет ниже, чем у LR(1). Причем у LR(k), при увеличении k, мощность не увеличивается.
VD>Кстати, интересной идеей является реализация парсера со сменными алгоритмами. Представляете? Задаешь тип алгоритма и смотришь что получилось. Красота!
Что то вроде JFLAP?
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[48]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, IT, Вы писали:
E>>D совсем другого поля ягода. И туже самую AbstractFactory для него можно без проблем получить путем precompile time генерации из какого-нибудь DSL (а описание AbstractFactory в анотации есть не что иное как DSL).
IT>А комбинацию AbstractFactory и, например, синглетона?
А какой в этом смысл? Зачем фабрике создавать то, что должно быть в единственном экземпляре?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[33]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, IT, Вы писали:
IT>Есть одна проблема. Пишем мы один раз, а читаем несчётное количество. Вручную написанный код сэкономит потом гораздо больше чем inf раз.
А зачем разбираться в сгенерированном коде? Разве что, нужно разбираться в спецификации, править её и заново прогонять через генератор.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[34]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, Kisloid, Вы писали:
K>Хочу лишь добавить, что зато LL(k) парсеры распознают более узкий класс КС грамматик, в то время как LR(1) распознает весь класс КС грамматик. Таким образом выразительная мощность LR(1) выше, чем у LL(k).
LR(1)-парсеры не распознают не то что весь класс КС-грамматик, они распознают даже далеко не весь класс однозначных КС-грамматик. Кстати, LR(1) — это роскошь, т.к. очень долго генерятся. На парктике используются LALR(1)-парсеры. Теоретически они распознают более узкий класс, чем LR(1), но на практике они справляются с теми же грамматиками, при этом выдавая болеее запутанные сообщения об ошибках.
Ну и конечно, LL(1)-парсеры распознают более узкий класс, чем LR(1). Как уже отметил Влад, у LL(1) меньше граблей с ошибками. Однако, не каждый LL(1) можно написать рекурсивным спуском. Иногда проблема решается преобразованием грамматики (кстати, генераторы LL(*)-парсеров это делают автоматически), что долго и нудно. Потому опять же проще сгенерить LL(*)-парсер, чем писать его же ручками.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[30]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, VladD2, Вы писали:
VD>Зависит от того что за макрос будет. В общем, то я бы предпочел хороший макрос. Так чтобы был чистый EBNF. И чтобы семантические действия были отделены и не заграмождали грамматику.
Ну, в чистом виде это не получается. Я вот частично сематические действия описывают при помощи тэгов (иденетификаторов в фигурных скобках рядом с названиями символов). Так грамматика немного загромождается, однако это позволяет почти автоматически генерить AST. Собственно семантические действия (которые в большинстве случаев будут создаваться автоматически) выносятся в отдельный класс или функцию.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[29]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, eao197, Вы писали:
E>Т.е., если в наличии есть оба варианта реализации, не могли бы вы озвучить количественные оценки -- объем кода в C# и в Nemerle?
Пока не могу, т.к. проект на Немерле далеко от завершения. Насчёт многих вещей я заранее могу сказать, какими они будут на Nemerle.
Сейчас готов парсер для языка, на котором опиывается грамматика, семантический анализатор, некоторые вспомогательные структуры данных и кое-что из работы с грамматикой. Кстати, язык описания грамматики в Nemerle-версии генератора на порядок сложнее, чем в случае с C#-версией, так что сравнение будет неуместно. Но несмотря на этот факт, объём кода проекта на Nemerle даже меньше объёма кода аналогичного проекта C# (52.9К vs 74.9К соотвественно). Но по парсеру судить, опять же, неуместно, так что посмотрим, когда я напишу ещё что-то, во сколько раз получится экономия.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[49]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, eao197, Вы писали:
IT>>А комбинацию AbstractFactory и, например, синглетона?
E>А какой в этом смысл? Зачем фабрике создавать то, что должно быть в единственном экземпляре?
Наоборот, единственный экземпляр фабрики.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[48]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, VladD2, Вы писали:
VD>+1 Так и есть. Метапрограммирование — это поле Немерла и Лиспа, но не Ди или С++.
Тогда какой смысл выяснять как делается на языке то, что на нем в принципе не должно делаться?
E>>D совсем другого поля ягода. И туже самую AbstractFactory для него можно без проблем получить путем precompile time генерации из какого-нибудь DSL (а описание AbstractFactory в анотации есть не что иное как DSL). При этом, по моему мнению, такой подход очень универсален,
VD>Какую фигню только не придумешь чтобы защитить явного аутсайдера.
Разговоры об аутсайдерах предлагаю отложить лет на пять.
VD>Создание внешиних ДСЛ-ей задача на порядок более сложная и не применимая в тех случаях когда этому ДСЛ-ю требуется информация о типах. Именно таков данный случй. Чтобы описание фабрики было кратким и декларативным ему нужно читать описание классов для которых создается фабрика. А именно это внешний ДСЛ и не может.
О сложности создания внешних DSL -- это ты кому-нибудь другому расскажи. Если голова на месте, а в руках подходящий инструмент, DSL-и пишутся за часок-другой без каких-либо усилий. А остальные могут подождать манны небесной от M$ с полной интеграцией в VS.
А вот информация о типах... Обрати внимание что в вашей фабрике ее и так не мало приходится передавать в анотациях. Если во внешний DSL вручную передать еще и описания доступных для фабрики конструкторов, то объем сильно не увеличится и лишняя работа будет не большой. Зато можно скрывать от фабрики часть конструкторов. И иметь готовый код фабрики, доступный для любых анализаторов исходников, документаторов и прочих инструментов.
Не говоря уже о том, что внешние DSL могут делать гораздо больше, чем генерировать один класс. Например, генерировать код для нескольких языков. Или управлять составом проекта при компиляции в зависимости от описанных в нем условий.
VD>Еще забавно, что такую крамолу несет челевек который совсем недавно с пулом защищал метапрограмирование в Руби. В этом языке почему-то метапрограммирвоание и создание красивых встроенных ДСЛ-е не является проблемой, и даже напротив является приемуществом.
Сечас речь не о Ruby.
Кроме того, там все DSL-и это не что и иное, как вызовы обычных методов -- т.е. не более, чем API. Так что Ruby-новое метапрограммирование имеет мало общего с Nemerle.
VD>Как это называется? Однозначно — двойные стандарты и притягивание за уши.
Здравствуйте, konsoletyper, Вы писали:
E>>А какой в этом смысл? Зачем фабрике создавать то, что должно быть в единственном экземпляре?
K>Наоборот, единственный экземпляр фабрики.
Теперь понял.
Так же, как и в случае Nemerl-овского макроса -- написать еще один DSL.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[51]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, IT, Вы писали:
VD>>Да и генераторы парсеров коенчно могут многое. Все же это метапрограммы.
IT>Я говорю как бы о компактности ручного написания.
Ну, вот konsoletyper обещает в ближайшем будущем сделать встроенный генератор для Немерла. Глядишь с его помощью будет вообще круть.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[52]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, IT, Вы писали:
E>>Так же, как и в случае Nemerl-овского макроса -- написать еще один DSL.
IT>И что он тебе сгенертрует? Ещё один файл или догенертрует существующий?
Это от постановки задачи зависит.
А как ту же задачу с помощью упомнавшегося здесь Nemerl-овского макроса сделать?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[53]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, eao197, Вы писали:
IT>>И что он тебе сгенертрует? Ещё один файл или догенертрует существующий?
E>Это от постановки задачи зависит.
Постановка такая — класс, реализующий абстрактную фабрику должен быть синглтоном.
E>А как ту же задачу с помощью упомнавшегося здесь Nemerl-овского макроса сделать?
[Singleton, AbstractFactory(X[int])]
class Factory { }
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[36]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, Kisloid, Вы писали:
K>При k стремящемся к бесконечности, да. А вот при конечном k выразительная мощность всегда будет ниже, чем у LR(1). Причем у LR(k), при увеличении k, мощность не увеличивается.
Назови мне хотя бы дин язык программирования для которого нельзя было бы построить LL(k)-парсер.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[49]: Как скрестить ужа и ежа или статическую и утиные тип
Здравствуйте, eao197, Вы писали:
E>Тогда какой смысл выяснять как делается на языке то, что на нем в принципе не должно делаться?
Вопрос сформулирован не верно. Вреный вопрос будет звучать так: Какой смысл создавайть языки в нет полноценных возможностей, но есть механизмы позволяющие кое-как воспроизводить нечто отдаленно похожее на полноценные возможнсоти других языков?
Заметь, я сразу сказал, что лучше или иметь чистое решение, или вообще его не иметь. А мне начала доказывать, что и этого достаточно. Ну, может и правда достаточно?
E>Разговоры об аутсайдерах предлагаю отложить лет на пять.
Не вижу на то оснований. Но мне то что? Хоть на 10.
E>О сложности создания внешних DSL -- это ты кому-нибудь другому расскажи. Если голова на месте, а в руках подходящий инструмент, DSL-и пишутся за часок-другой без каких-либо усилий. А остальные могут подождать манны небесной от M$ с полной интеграцией в VS.
ОК. Расскажу другим. Тем кто не будет спорить с очевидным и трепаться по чем зря.
Ты же можешь просто попробовть написать внешний ДСЛ для создания абстрактных фабрик. Будет очень весело на это поглядеть.
E>А вот информация о типах... Обрати внимание что в вашей фабрике ее и так не мало приходится передавать в анотациях.
Не вижу в упор. Там передается только имя типа. Причем относительное (с учетом открытых пространств имен). А вся информация получается от компилятора.
E> Если во внешний DSL вручную передать еще и описания доступных для фабрики конструкторов, то объем сильно не увеличится и лишняя работа будет не большой.
Абсурдность того что ты говоришь вызвает смешанное чувство офигения, смеха и возмущения от откровенной лжи.
Если мне прийдется передовать всю эту информацию в внешинй ДСЛ, то смысла в таком ДСЛ-е не будет во все. Точнее от этого будет прямой ущерб. Намного проще будет просто создать фабрику врунчную. Ведь объем вводимой информации будет точно таким же.
E> Зато можно скрывать от фабрики часть конструкторов. И иметь готовый код фабрики, доступный для любых анализаторов исходников, документаторов и прочих инструментов.
Исходник можно сгенерировать и по макросу. Только смысла в это нет вовсе. Декларативная природа макроса убирает в этом необходимость. Анализ сгенерированного кода нужен только в отладочных целях. Иначе это нонсенс.
E>Не говоря уже о том, что внешние DSL могут делать гораздо больше, чем генерировать один класс.
А болше для данного случая просто не надо. И меньше не надо. И сложнее не надо. Надо то что есть. Ни болше, ни меньше. Так что кончай притягивать за уши все что попало и будедь хоть чуточку конструктивен и объективен. А то это твои выступления уже давно перешли грань разумности.
E> Например, генерировать код для нескольких языков. Или управлять составом проекта при компиляции в зависимости от описанных в нем условий.
Да, да, про состав проекта это ты здорово заметил. Как сейчас помню как ты рассказвал как здорво на Руби создавать встроенные ДСЛ-и для этих целей. Так что сейчас ты тщетно пытаешся опровергнуть свои же утверждения.
Забавно, кстати, получается. Пытаясь принизить возможности Немерле ты не только стал полностью противоречить своим же свловам, но и принизил Руби, Питон, Лисп а так же все остальные языки обладающие продвинутыми встроенными средствами метапрограммировния.
Браво! Очередной пример к чему приводит демагогия и двойные стандарты.
E>Сечас речь не о Ruby.
Во как? Отличная демонстрация двойных стандартов. Как только ты почувствовал, что защищаемый тобой Ди сливает в этой области (надо признать правильно почувствовал), так сразу же начал искать недостатке в самом создании внутренних ДСЛ-ей. А как только тебе указали на то, что ты пиаря Руби сам описывал удобство и гибкость такого подхода, так сразу прозвучали слова, что сейчас речь не о том... Браво!
E>Кроме того, там все DSL-и это не что и иное, как вызовы обычных методов -- т.е. не более, чем API. Так что Ruby-новое метапрограммирование имеет мало общего с Nemerle.
Очердная лож! Метапрограмирование есть метапрограммирование. От того как оно работает и когда оно выполняется ничего не меняется. Руби меняет код в рантайме с помощью одного АПИ, Немеле в компайлтайме с помощью другого. Суть одна и та же. В результате получаются адаптированные синтаксические конструкции для решения конкретных прикладных задач.
E>Двойные стандарты?
Ага! Они самые.
E>А если посмотреть на то, что я здесь по поводу внешних DSL для C++ говорил:
Не, лучше посмотреть на то что ты говорил о встроенных ДСЛ-ях и Руби. встроенный DSL
E>А двойной стандарт, имхо, в том, что на повешенную мной бомбочку
о выделении спора вокруг C++ и D из данной темы, упорно никто не реагирует. Хотя обсуждение уже очень давно ушло совсем в другую сторону.
А кто ты такой чтобы по одной твоей бомбочке что-то делать? Тут половина тем уходит в некуда. Если бомбочек много, то модератор это обычно замечает. А так моло ли кто что хочет?
Хочешь чтобы кто-то среагировал? Напиши на модуратор(эт)рсдн.ру.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[54]: Как скрестить ужа и ежа или статическую и утиные тип
Если нам не помогут, то мы тоже никого не пощадим.
Там передается только имя типа. Причем относительное (с учетом открытых пространств имен). А вся информация получается от компилятора.
