Здравствуйте, WolfHound, Вы писали:

WH>Ибо чуть менее чем все случаи возникновения левой рекурсии это описание операторов.

Так уж и операторов?

А фигня вида namespace.class.method(bebebe)[index].method(...).method(...)?

WH> А им одной левой рекурсии маловато. Им еще ассоциативность с приоритетами подавай.

Ну с такой чушью даже банальный recursive descent на ура справляется.

WH> А тут уже рулит Pratt со страшной силой.

Уболтали. Пойду на Пратта смотреть внимательнее.

А>> Откуда там тормоза?
WH>От того что запоминание требует вычислительных ресурсов и обращий к памяти, а это уже пошли промахи кеша и тому подобные радости.

Семантика все равно гораздо больше радостей предоставляет, рядом с этим тормоза парсера несущественны.

А>>Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?
WH>Если запоминать не все, то это уже не пакрат.

Почему не пакрат? Очень даже пакрат, только ленивый. Сожрали top level declaration, GC все запомненное и прибрал, а парсер лениво дальше хреначит, до следующего declaration.

А>> Ну и что не так с Packrat?
WH>Тормоза и дикий жор памяти.

На практике особых проблем не наблюдается.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:

I>>А нельзя ли вместо Pratt заюзать другое слово ? А то сильно созвучно с Prat
WH>Нельзя. Ибо автора завут: Vaughan Pratt
WH>http://en.wikipedia.org/wiki/Pratt_parser

Можно. Например Vaughan.

Здравствуйте, Аноним, Вы писали:

VD>>Пакрата бояться в лес не ходить. Левую рекурсию он не поддерживает.

А> Чо, правда? http://www.cs.ucla.edu/~todd/research/pepm08.html

Правда. То на что ты дал ссылку — это не Пакрат. Если ты почитаешь эту работу, то поймешь, что от простоты пакрата там камня на камне не остается. Остаются только минусы.

VD>> И сам по себе он на практике не применим в следствии дичайших тормозов.

А> Откуда там тормоза? Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?

От туда. Чтобы жрать память тоже надо время. Это очередной бесплатный сыр.
Единственный способ оптимизации Пакрата который дает реальный выигрышь — это устранение мемоицации (сокращение).
Об этом уже куча работ понаписана. И в реальных проектах та же фигня. Кури работу по Rats!

VD>> Мы же херной не занимаемся. У нас четкий ценз для алгорита — он должен быть применим для построения парсеров реальных ЯП. И его должно быть можно использовать в IDE.

А> Ну и что не так с Packrat?

Алгоритм подразумевающий тотальную мемоизацию.
Второй проблемой является то, что по сути это комбинаторый парсер, т.е. парсер состоящий из вызова кучи других парсеров.
Это здорово с точки зрения расширяемости, но фигово с точки зрения оптимизации.

Вольфхаунд сделал несколько оптимизаций которые в итоге повысили скорость парсинга где-то в 10 раз (включая компиляцию в релиз).
Самое прикольное, что использование TDOP дает не только бесплатное избавление от левой рекурсии, но и такие приятные плюшки как: а) декларативное объявление приоритетов операторов, б) ускорение разбора, в) внятный механизм расширяемости.

Самое смешное, что в процессе эволюции PEG-а Вольфхаунд пришел к мысли, что от его главной фишки — оператора приоритетного выбора нужно отказаться. Он предложил выбирать не первое спарсившееся вхождение, а самое длинное из спарсившихся. Я не уверен, то это не приведет к замедлению, так как это приведет к разбору большего числа правил. Но возможно это позволит ввести другие оптимизации. А то что большая часть правил будет обламываться на первых символах может нивелировать отставание.

Здравствуйте, VladD2, Вы писали:

VD>Правда. То на что ты дал ссылку — это не Пакрат. Если ты почитаешь эту работу, то поймешь, что от простоты пакрата там камня на камне не остается. Остаются только минусы.

Я делал реализацию этого алгоритма. Поверх банального пакрата. Всей разницы — надо уметь правильно распознавать рекурсию, и подставлять нужную макру вызова. Одна макра простая, вторая чуть посложнее. Код генерится почти одинаковый.

VD>От туда. Чтобы жрать память тоже надо время. Это очередной бесплатный сыр.
VD>Единственный способ оптимизации Пакрата который дает реальный выигрышь — это устранение мемоицации (сокращение).

До того, как я сделал оптимизацию операции выбора по первому символу (простые термы не мемоизируются) было до 300 проходов по одному символу. Теперь — максимум 3. Скорость работы увеличилась пропорционально. Так что полно там возможностей для оптимизации.

VD>Об этом уже куча работ понаписана. И в реальных проектах та же фигня. Кури работу по Rats!

Rats! слаб, там и половины возможных оптимизаций нет.

VD>Алгоритм подразумевающий тотальную мемоизацию.

Не обязательно. Достаточно только составные термы запоминать.

VD>Второй проблемой является то, что по сути это комбинаторый парсер, т.е. парсер состоящий из вызова кучи других парсеров.

Не обязательно. Можно легко генерить монолитный код (что я и делаю).

VD>Это здорово с точки зрения расширяемости, но фигово с точки зрения оптимизации.

Одно другому не мешает.

VD>Самое прикольное, что использование TDOP дает не только бесплатное избавление от левой рекурсии, но и такие приятные плюшки как: а) декларативное объявление приоритетов операторов, б) ускорение разбора, в) внятный механизм расширяемости.

Уже понял, что надо на это смотреть внимательнее, спасибо.

VD>Самое смешное, что в процессе эволюции PEG-а Вольфхаунд пришел к мысли, что от его главной фишки — оператора приоритетного выбора нужно отказаться.

Боюсь, что это очень зря.

Здравствуйте, Аноним, Вы писали:

А> Так уж и операторов?
А> А фигня вида namespace.class.method(bebebe)[index].method(...).method(...)?

А это и есть операторы. Инфиксный оператор "." (или точнее мебер-эксес). Оператор вызов функции или индексера — вполне себе постфиксные операторы.

WH>> А им одной левой рекурсии маловато. Им еще ассоциативность с приоритетами подавай.

А> Ну с такой чушью даже банальный recursive descent на ура справляется.

А Пратт и есть банальный рекурсивный парсер. Ты его название то хорошо прочел?
Top Down Operator Precedence

Пакрат — это тоже TopDown-парсер. Вот только Pratt (TDOP) специализированный алгоритм для разбора именно операторов с приоритетами. За счет приоритетов он и левую рекурсию щелкает как орешки.

При этом TDOP — это очень простой алгоритм.

WH>> А тут уже рулит Pratt со страшной силой.

А> Уболтали. Пойду на Пратта смотреть внимательнее.

Давно поря. Тем более, что это ну очень простой алгоритм.

А>>> Откуда там тормоза?
WH>>От того что запоминание требует вычислительных ресурсов и обращий к памяти, а это уже пошли промахи кеша и тому подобные радости.

А> Семантика все равно гораздо больше радостей предоставляет, рядом с этим тормоза парсера несущественны.

Какая к черту семантика? Как алгоритм может семантику предоставлять?
Семантика она может быть у формата — PEG-а. Ну, так она воспроизводится 1 в 1.

А>>>Память жрет, да, ну так на кой надо жрать больше чем на один top level declaration?
WH>>Если запоминать не все, то это уже не пакрат.

А> Почему не пакрат?

Потому что Пакрат — это конкретный алгоритм. Если в нем убрать тотальную мемоизацию, то это уже будет другой алгоритм (тупой рекурсивный парсер с откатами и экспонентой в неосторожно написанных правилах).

А>Очень даже пакрат, только ленивый. Сожрали top level declaration, GC все запомненное и прибрал, а парсер лениво дальше хреначит, до следующего declaration.

Ой, ты достал. Сделай на своем чуде природы парсер более менее серьезного языка и сравни с PegGrammar. Только приготовься расстроиться.

К тому же твой алгоритм никак не пакрат, так как он просто встанет или дико замедлится если в не топ-декларэшон у тебя окажутся какие-то не лево-факторизованные правила. Экспонента есть экспонента. Ее не обойти без предсказания или мемоизации.

А>>> Ну и что не так с Packrat?
WH>>Тормоза и дикий жор памяти.
А> На практике особых проблем не наблюдается.

У тебя явно невнятная практика. Да и пакрата у тебя тоже нет, по твоим же словам.

Здравствуйте, <Аноним>, Вы писали:

А> Так уж и операторов?
А> А фигня вида namespace.class.method(bebebe)[index].method(...).method(...)?
Точка это инфиксный оператор. () и [] суффиксные.
Точке нужна ассоциативность с приоритетами. () и [] нужны только приоритеты.

А> Ну с такой чушью даже банальный recursive descent на ура справляется.
Горой мутного кода и только с приоритетами.
С ассоциативностью не справляется.
Приходится химичить руками.

А> Семантика все равно гораздо больше радостей предоставляет, рядом с этим тормоза парсера несущественны.
Ошибаешься.
Особенно в свете поддержки интелисенса. Это когда парсить нужно на каждое нажатие клавиши пользователем.

А> На практике особых проблем не наблюдается.
Я не знаю что у тебя там за практика но мои и не только мои измерения показывают что мемоизация тормозит.
Самые сильные оптимизации в парсере Rats! занимаются убиванием мемоизации...

Здравствуйте, Ikemefula, Вы писали:

>>Если у вас нет сборки продукта в один клик, то вы уже накосячили. Если вам мешает ТФС, то выкиньте его на фиг. Есть много других решений.

I>Кто тебе сказал что у нас чего то нет ?

Ты. Ты же сам сказал, что у вас при сборке периодически приходится ТФС ручками снимать, так как он что-то там блокирует.

Здравствуйте, VladD2, Вы писали:

VD>Это имя автора алгоритма. Алгоритм называется Top Down Operator Precedence (TDOP).

TDOP более понятно. А то устроили какую то вакханалию с именами из детских книг и слов созвучный ругательствам

P.S. Чел, который дал имя Nemerle вероятно прочитал только одну книгуУрсулы Ле Гуин. Прочитай он все, наверняка дал бы другое имя. Как корабль назовете, как говорится. Если Немерле повторит путь своего героя, то мелькнёт на арене всего разок, по крупному и про него забудут уже к началу второй книги, а их целых 4 !

Здравствуйте, VladD2, Вы писали:

>>>Если у вас нет сборки продукта в один клик, то вы уже накосячили. Если вам мешает ТФС, то выкиньте его на фиг. Есть много других решений.
I>>Кто тебе сказал что у нас чего то нет ?

VD>Ты. Ты же сам сказал, что у вас при сборке периодически приходится ТФС ручками снимать, так как он что-то там блокирует.

Глюки ТФС и сборка в один клик это разные вещи. ТФС иногда глючит только в одной из конфигураций ВПН, отваливающиеся тесты, релизноты занимают куда больше времени.

Шас ты вероятно скажешь, что релизноты у тебя генерятся автоматом, впн никогда не падает, а тесты всегда зелёные, правильно ? Ну может добавишь, что все это благодаря немерлу

Здравствуйте, Ikemefula, Вы писали:

I>Вот и в тебе заговорил ВладД2 Стать, презентации — это все пройденый этап. Я уже говорил, что против Немерле_без_макросов ничего против не имею.

Ви так говорите, что можно подумать, что ВладД2 — это что-то плохое! (с)

I>Т.е. меня интересует именно легаси код Немерла взрослого проекта, а не компилятора/демки/куркулятора. Интересует с целью выяснить, во что превращается проект через год-два скажем.

I>Наверняка у тебя в проекте есть куча классов общего назначения, которые делают чтото полезное и правятся месяцами а то и годами, правильно ? Вот на них и интересно взглянуть. Желательно без макросов и что бы PM проявился по-взрослому.

I>Например проекты на С++ после смены состава команды часто скатываются в какую то вакханалию в коде. С питоном например такого не происходит. Мне важно знать, что будет с Немерле.

То во что превращается проект зависит не от языка, от людей его поддерживающих.

Здравствуйте, Ikemefula, Вы писали:

I>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

I>Вне энтерпрайза свобода выбора технических решений шире, нет всякой бюрократии и потому часто люди могут себе позволить пользовать даже беты для продуктовых проектов.

Чушь. Это зависит не от энтерпрайза, а от элементарной забюракратизованности конторы и/или ссыкливости энтерпрайз манагеров. А энтерпрайз сюда как опровдание приплели сами же бюрократы и их пособники.

ЗЫ. Если что, я сам работаю в большом-большом энтерпрайзе, человек на тыши три одних только дотнетчиков. Тем не менееи у нас в команде с успехом используется git, так что не надо.

Здравствуйте, Ikemefula, Вы писали:

I>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

Вы сами кузнецы вашего горя. И этерпрайз тут не причем. Вот у IT тоже энтерпрайз (крупнейший банк в штатах), но они таки рассматривают применение git-а.

I>Вне энтерпрайза свобода выбора технических решений шире, нет всякой бюрократии и потому часто люди могут себе позволить пользовать даже беты для продуктовых проектов.

I>По этой причине очень странно слышать "А ты слышал, что есть люди что живут вообще без продуктов от MS?" при чем от человека, который пользует офис, вижлу, винду, .Net и прочую дрянь от того же Микрософта.

Человек не пеняет на энтерпрайзы. Если у МС нет приличного решения проблемы, то берет другое, приличное. Только и всего.
Офис, вижлу, винду и .Net удовлетворяют потребностям. А вот C# перестал. Вот человек и нашел другой язык. Даже пришлось взяться за его разработку.

Здравствуйте, Ikemefula, Вы писали:

I>Можно. Например Vaughan.

Ой, не надо. Я это даже произнести то не могу .

Здравствуйте, VladD2, Вы писали:

I>>Наверняка у тебя в проекте есть куча классов общего назначения, которые делают чтото полезное и правятся месяцами а то и годами, правильно ? Вот на них и интересно взглянуть. Желательно без макросов и что бы PM проявился по-взрослому.

I>>Например проекты на С++ после смены состава команды часто скатываются в какую то вакханалию в коде. С питоном например такого не происходит. Мне важно знать, что будет с Немерле.

VD>То во что превращается проект зависит не от языка, от людей его поддерживающих.

То есть, в с++ вдруг появится рефакторинг, быстрая сборка, толковые исключения, лямбды и паттерн матчинг ? Вот так чудеса.

У меня как то все проще — если вдруг приходится лезть в С++, то ничего из перечисленного я там не обнаруживаю и код тухнет со страшной силой.

Здравствуйте, Ikemefula, Вы писали:

I>Глюки ТФС и сборка в один клик это разные вещи.

Это как, если надо что-то руками снимать?

I>ТФС иногда глючит только в одной из конфигураций ВПН, отваливающиеся тесты, релизноты занимают куда больше времени.

Ню-ню. Я бы еще понял, если бы ТФС-у заменя не было. Но, блин, есть Гит, есть Меркури. Они ведь в разы удобнее, быстрее и надежнее.

Ладно. Тешти себя "релизнотами".

I>Шас ты вероятно скажешь, что релизноты у тебя генерятся автоматом, впн никогда не падает, а тесты всегда зелёные, правильно ? Ну может добавишь, что все это благодаря немерлу

Ну, тесты у меня дейсвительно всегда зеленые. Не зеленые не комитястся. Перед комитом всегда проходит полная сборка с тестированием. А релизноты пока руками собираются, по коментам к комитам. Но их надо крайне редко собирать. А вот прогонять сборку нужно постоянно. И если там нет полной автоматики, то кридык. Даже два нажатия уже напрягают.

Кстати, сейчас думаем и над тем как релиз-ноты автоматизированно формировать. Оно тоже очень даже полезно.

В общем, одна зеленая факсовая кнопка для сборки релиза — это идеал к которому нужно стремиться. А вот одна зеленая факсовая кнопка для сборки рабочей конфигурации — это обязательная вещь. И если у вас это не так, то это первое что нужно сделать. А валить на энтерпрай не надо. Это качество организации работы. Любой энтерпрайз в этом заинтересован в первую очередь.

Здравствуйте, IT, Вы писали:

I>>Вне энтерпрайза свобода выбора технических решений шире, нет всякой бюрократии и потому часто люди могут себе позволить пользовать даже беты для продуктовых проектов.

IT>Чушь. Это зависит не от энтерпрайза, а от элементарной забюракратизованности конторы и/или ссыкливости энтерпрайз манагеров. А энтерпрайз сюда как опровдание приплели сами же бюрократы и их пособники.

Энтерпрайз как правило забюрократизирован. Свобода и гибкость в решениях гарантируется только в определенном направлении. Например VCS на команду. А вот VCS на направление — уже другой расклад. А если к кодовой базе имеют доступ различные организации, то дело вообще тухлое.

IT>ЗЫ. Если что, я сам работаю в большом-большом энтерпрайзе, человек на тыши три одних только дотнетчиков. Тем не менееи у нас в команде с успехом используется git, так что не надо.

А не ты ли рассказывал, что нельзя ничего протащить толкового, вроде Немерле ? Опаньки !

Проекты вы сами делаете или вместе с другим N-коммандами ? Переведи все три тыщи дотнетчиков на Git, поговорим про CVS и ТФС, идёт ?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Ikemefula, Вы писали:

I>>Можно. Например Vaughan.

VD>Ой, не надо. Я это даже произнести то не могу .

Произносится как Ван.

Здравствуйте, VladD2, Вы писали:

I>>В энтерпрайзе свобода выбора технических решений как правило сильно ограничена. Мне лично, например, нравится Mercurial, а не TFS. Но все наши проекты за малым исключением на TFS и я точно знаю что Меркуриала в обозримом будущем точно не будет.

VD>Вы сами кузнецы вашего горя. И этерпрайз тут не причем. Вот у IT тоже энтерпрайз (крупнейший банк в штатах), но они таки рассматривают применение git-а.

В том банке целая куча бюрократических проволочек на каждый чих. Если одной команде, которая почти не завязана на остальных, дали Git, ничего не значит.

I>>Вне энтерпрайза свобода выбора технических решений шире, нет всякой бюрократии и потому часто люди могут себе позволить пользовать даже беты для продуктовых проектов.

I>>По этой причине очень странно слышать "А ты слышал, что есть люди что живут вообще без продуктов от MS?" при чем от человека, который пользует офис, вижлу, винду, .Net и прочую дрянь от того же Микрософта.

VD>Человек не пеняет на энтерпрайзы. Если у МС нет приличного решения проблемы, то берет другое, приличное. Только и всего.
VD>Офис, вижлу, винду и .Net удовлетворяют потребностям. А вот C# перестал. Вот человек и нашел другой язык. Даже пришлось взяться за его разработку.

Для 10 человек это очень просто. А вот для 10 команд это совсем не просто, наверняка найдутся сторонники и противники разных версий. Многим нарпример Git не нравится

Если к коду имеет доступ целая куча людей в разных конторах, государствах то даже от CVS избавиться крайне тяжело.

Здравствуйте, Ikemefula, Вы писали:

I>То есть, в с++ вдруг появится рефакторинг,
Штука полезная но не критичная.

I>быстрая сборка,
Разбей проект на кучу маленьких dll/so/или что там под той платформой под которую ты пишешь.

I>толковые исключения,
Исключения как исключения. В чем проблема?

I>лямбды и паттерн матчинг ? Вот так чудеса.
Можно и без них писать.
Кода получается конечно больше но это не повод превращать его в говнокод.

I>У меня как то все проще — если вдруг приходится лезть в С++, то ничего из перечисленного я там не обнаруживаю и код тухнет со страшной силой.
А у меня не тухнет.

Здравствуйте, VladD2, Вы писали:

I>>Глюки ТФС и сборка в один клик это разные вещи.

VD>Это как, если надо что-то руками снимать?

Это значит, что глючит только одна конфигурация из примерно десятка.

I>>ТФС иногда глючит только в одной из конфигураций ВПН, отваливающиеся тесты, релизноты занимают куда больше времени.

VD>Ню-ню. Я бы еще понял, если бы ТФС-у заменя не было. Но, блин, есть Гит, есть Меркури. Они ведь в разы удобнее, быстрее и надежнее.

Зато у ТФС абслютно адская интеграция в вижлу. Ничего подобного у гита и меркури нет и вскорости не предвидится.

VD>Ну, тесты у меня дейсвительно всегда зеленые. Не зеленые не комитястся.

То есть, зелёные, но не зелёные ? Или ты тяжелые тесты против деплоймента на каждый коммит запускаешь ?

>Перед комитом всегда проходит полная сборка с тестированием.

А тесты против деплоймента куда деть ?

VD>Кстати, сейчас думаем и над тем как релиз-ноты автоматизированно формировать. Оно тоже очень даже полезно.

Возню с трекером все равно не отменить. А это времени больше релизноты подготовить.

VD>В общем, одна зеленая факсовая кнопка для сборки релиза — это идеал к которому нужно стремиться. А вот одна зеленая факсовая кнопка для сборки рабочей конфигурации — это обязательная вещь. И если у вас это не так, то это первое что нужно сделать. А валить на энтерпрай не надо. Это качество организации работы. Любой энтерпрайз в этом заинтересован в первую очередь.

Качество организации напрямую зависит от количества людей вовлеченных в процесс. Многие конторы даже планку в 30 человек переступить не могут. А когда счет идёт на тысячи крайне странно утверждать что все де легко.