Здравствуйте, Аноним, Вы писали:
А>В одной библиотеке Петя добавил exp ^^ exp А>В другой библиотеке Костя добавил exp ^^ exp А>и как это будет все работать?
Если оба будут подключены одновременно, то будет ошибка времени выполнения. Компилятор сообщит о неоднозначности.
Неоднозначными считаются два правила которые спарсили оду и ту же конструкцию.
Мы думали о некотором механизме разрешения чистого конфликта, но пока просто забили на это. Не думаю, что на практике это будет проблемой. Ну, а будет — добавим механизм приоритетов.
Тут еще надо учитывать, что два правила могут быть размещены в разных пространствах имен, так что открывая (в конкретном месте) одно из них можно будет выбирать какое из них использовать.
А>У тебя орфографическая ошибка в статье. Я ее подчеркнул.
А... Спасибо. Это будет отдельным проходом правиться.
А>Не понятно тогда почему не сделать унификацию полностью? Что мешает? Чему мешает?
Унификация — это довольно ресурсоемкий алгоритм. Мы же не Пролог делаем. Там где от него будет польза — он будет доступен. Для дополнительных же полей он не нужен. Их цель просто "распространять" данные по дереву разбора и защищать от ошибок. Тут не приемлем императивный подход, так как мы не можем гарантировать определенного порядка исполнения. Вот нам и нужна семантика которая для программиста будет очевидной, но уберет зависимость от последовательности операций.
VD>>Ох, опять приходится телепатировать. Типы Expr1.ConstValue? VD>>Будет. Смотри реализацию функции TrySumLiterals. Она проверяет реальные типы и в случае их несовпадения возвращает ConstValue.Nine(). Тут уже нужно быть знакомым с алгебраическими типами, чтобы понять суть происходящего. А>Извиняюсь, там я не заметил А>
Вообще слово abstract сбивает с толку но это дело привычки
Мы прилепили "abstract", чтобы защитить от ошибки (тело ведь можно забыть написать).
Суть тут в том, что расширяющие правила они как бы наследники расширяемого. По этому если объявлять поле в расширяемых правилах, то их не будет видно когда работа идет с "базовым классом" (т.е. расширяемым правилом). А объявив поле в расширяемом классе оно автоматом становится видимым во всех его расширениях (наследниках).
Постараюсь это дело осветить в статье, чтобы не возникало вопросов.
VD>>Об областях видимости, ваш КО А>Не понятно зачем они тут нужны и как и когда их использовать.
Там ниже же есть пример. Я расширил его описание. Погляди, плиз. Так понятнее?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
А>>В одной библиотеке Петя добавил exp ^^ exp А>>В другой библиотеке Костя добавил exp ^^ exp А>>и как это будет все работать?
VD>Если оба будут подключены одновременно, то будет ошибка времени выполнения. Компилятор сообщит о неоднозначности.
очень хотелось бы, чтобы этим можно было управлять. например перегрузить стандартный оператор, но из его перегруженного обработчика чтобы можно вызвать и стандартный.
Здравствуйте, _Claus_, Вы писали:
_C_>очень хотелось бы, чтобы этим можно было управлять. например перегрузить стандартный оператор, но из его перегруженного обработчика чтобы можно вызвать и стандартный.
Перегружать стандартные операторы (как и любые другие конструкции) будет можно. Но на основе типов.
Я планирую посвятить этому отдельный раздел.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, nikov, Вы писали:
N>Как обстоят (будут обстоять) дела с инкрементальным парсингом? Имеется в виду локальное обновление AST при редактировании кода в большом файле.
Пока что полагаемся на скорость парсинга. Она обещает быть очень высокой (скорости PegGrammar в релизе) хватало для перепарсивания C#-файла размером в мегабайт в GUI-потоке (без заметных на глаз томозов).
Есть мысли на счет сохранения "стека" парсера, чтобы можно было продолжить разбор с того же места.
Правда, мысли эти приходили не по поводу работы в GUI, а по поводу восстановления после ошибок. При использовании откатов оптимальным вариантом определения ошибки является откат до стартового правила с запоминанием места сбоя. При этом правило где произошла ошибка определить очень легко (самое вложенное сбойнувше правило). Вот только продолжить разбор после этого уже невозможно. Вот и появилась мысль сохранять значение стека, чтобы после отката до старта можно было бы продолжить с места сбоя и попытаться восстановиться путем подстановки фальшивых токенов или пропуска неверных.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, nikov, Вы писали:
N>>Как обстоят (будут обстоять) дела с инкрементальным парсингом? Имеется в виду локальное обновление AST при редактировании кода в большом файле.
Видел как пример как инкрементальная компиляция была сделана на рефале. В шоке. Фактически затрагивался только минимально измененый кусок. Правда там не было восстановления после ошибок. Эффект достигался с помощью суперкомпиляции.
Как предложение. Добавить секции файла. Например разделеные спецстрокой. При компиляции проверяется не изменость секции. И соотвенно не надо ее разбирать типизировать. Ошибки не переходят в другие секции. Скорость работы сильно возрастет. Т.е. Каждая секция разбирается и частично типизируется. При изменении разбирается только одна секция и дотипизируется весь файл.
Здравствуйте, Аноним, Вы писали:
А>Видел как пример как инкрементальная компиляция была сделана на рефале. В шоке. Фактически затрагивался только минимально измененый кусок. Правда там не было восстановления после ошибок. Эффект достигался с помощью суперкомпиляции.
Все зависит от сложности языка. Для детсадовских примеров — это не сложно. Если же язык имеет препроцессор, то инкрементальный разбор чреват проблемами.
А>Как предложение. Добавить секции файла. Например разделеные спецстрокой.
Это будет какая то лаж в стиле MFC. К тому же от препроцессора это никак не спасет.
У меня другой вопрос. Зачем это все надо, если скорости парсера будет хватать на мегабайт файл? Файлы большего объема — это 100% автогенеренные файлы изменять которые смысла нет. Для них можно производить обработку в бэкграунд-потоке. Будет еле заметная задержка обновления подсветки. Не думаю, что это кого-то напряжет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
В общем, выглядит довольно интересно. Обычно для написания и отладки грамматик я использую Intellipad из Microsoft Oslo (который, к сожалению, так пока и не зарелизился). Там есть режим с тремя окнами: в середине — описание грамматики, слева — код, который должен быть разобран согласно этой грамматике, а справа — получаемое AST. При редактировании в левом или среднем окнах результат тут же обновляется и показываются возможные ошибки и неоднозначности.
Если бы вы сделали подобный инструмент для N2, да ещё в вебе (наподобие Kotlin Web Demo) и добавили отладчик грамматики (как в ANTLRWorks), навигацию к определению правила и Rename/Extract/Inline рефакторинги для грамматики, с возможностью скачать полученный парсер в виде DLL, и всё это сделано с помощью N2 и можно посмотреть исходники — то это наверняка привлекло бы внимание к проекту. По крайней мере я, наверное, пересел бы на это с Intellipad'а.
.
N>В общем, выглядит довольно интересно. Обычно для написания и отладки грамматик я использую Intellipad из Microsoft Oslo (который, к сожалению, так пока и не зарелизился). Там есть режим с тремя окнами: в середине — описание грамматики, слева — код, который должен быть разобран согласно этой грамматике, а справа — получаемое AST. При редактировании в левом или среднем окнах результат тут же обновляется и показываются возможные ошибки и неоднозначности.
N>Если бы вы сделали подобный инструмент для N2, да ещё в вебе (наподобие Kotlin Web Demo) и добавили отладчик грамматики (как в ANTLRWorks), навигацию к определению правила и Rename/Extract/Inline рефакторинги для грамматики, с возможностью скачать полученный парсер в виде DLL, и всё это сделано с помощью N2 и можно посмотреть исходники — то это наверняка привлекло бы внимание к проекту. По крайней мере я, наверное, пересел бы на это с Intellipad'а.
Здравствуйте, VladD2, Вы писали:
VD>У меня другой вопрос. Зачем это все надо, если скорости парсера будет хватать на мегабайт файл? Файлы большего объема — это 100% автогенеренные файлы изменять которые смысла нет. Для них можно производить обработку в бэкграунд-потоке. Будет еле заметная задержка обновления подсветки. Не думаю, что это кого-то напряжет.
Не всегда так, есть рукописные файлы такого объемы неоднократно видел такие в UI библиотеках от Infragistics и Cronwood. У лично пару раз были в проектах рукописные файлы около 1Mb
N>Если бы вы сделали подобный инструмент для N2, да ещё в вебе (наподобие Kotlin Web Demo) и добавили отладчик грамматики (как в ANTLRWorks), навигацию к определению правила и Rename/Extract/Inline рефакторинги для грамматики, с возможностью скачать полученный парсер в виде DLL, и всё это сделано с помощью N2 и можно посмотреть исходники — то это наверняка привлекло бы внимание к проекту. По крайней мере я, наверное, пересел бы на это с Intellipad'а.
Еще кто-то буду спорить, что нужно создавать свою студию, с Web-возможностями?
N>>Если бы вы сделали подобный инструмент для N2, да ещё в вебе (наподобие Kotlin Web Demo) и добавили отладчик грамматики (как в ANTLRWorks), навигацию к определению правила и Rename/Extract/Inline рефакторинги для грамматики, с возможностью скачать полученный парсер в виде DLL, и всё это сделано с помощью N2 и можно посмотреть исходники — то это наверняка привлекло бы внимание к проекту. По крайней мере я, наверное, пересел бы на это с Intellipad'а.
_C_>Еще кто-то буду спорить, что нужно создавать свою студию, с Web-возможностями?
начни
_C_>>Еще кто-то буду спорить, что нужно создавать свою студию, с Web-возможностями? А>начни
если берусь за что-то, имею план. здесь дело непростое. требует и взаимодействия, и ясного конечного применения. и финансовой отдачи.
так вот на мой взгляд, организовывать на это должен формальный лидер. и контролировать процесс. а мы снизу поддерживать делами и одобрямсами.
чтобы обозные телеги двигались согласованно в одном направлении. и люди в обозе были сытые и довольные.
нужно хотя бы попытаться перейти из любительской лиги в профессиональную.
Здравствуйте, nikov, Вы писали:
N>В общем, выглядит довольно интересно. Обычно для написания и отладки грамматик я использую Intellipad из Microsoft Oslo (который, к сожалению, так пока и не зарелизился). Там есть режим с тремя окнами: в середине — описание грамматики, слева — код, который должен быть разобран согласно этой грамматике, а справа — получаемое AST. При редактировании в левом или среднем окнах результат тут же обновляется и показываются возможные ошибки и неоднозначности.
Идея не плохая. Не ясно только как быть с модулями. У нас же грамматики могут быть разбиты на множество модулей.
Еще одна проблема — у нас же модули будут компилироваться перед использованием. Так что полного реалтайма не будет. Будет небольшая задержка.
Но, думаю, это все мелочи. Попробуем сделать как ты говоришь.
N>Если бы вы сделали подобный инструмент для N2, да ещё в вебе (наподобие Kotlin Web Demo)
Я вот у них попытался получить комплешон и все зависло. Думаю, сделать качественный интерфейс в броузере будет не очень просто. Лучше сделать мод
N>и добавили отладчик грамматики (как в ANTLRWorks),
В ANTLRWorks там все шибко визуальное. Это не просто. У нас будет обычная отладка в отладчике. Собственно она и сейчас есть. Только много лишнего показывает. Надо будет подумать как упростить отладку, чтобы она прямо по правилам бежала.
N>навигацию к определению правила
Это уже есть.
N> и Rename/Extract/Inline рефакторинги для грамматики,
Extract/Inline к нам вряд ли будет применим. У нас в правилах нельзя использовать оператор альтернативы "|" или приоритетного доступа "/". Так что экстрактить и инлайнить особо буде не чего.
Учитывая, что имена правил не могут быть перегруженными их замету легко и простой контекстной заменой сделать. Ну, да переименование конечно можно будет сделать в будущем.
N> с возможностью скачать полученный парсер в виде DLL, и всё это сделано с помощью N2 и можно посмотреть исходники — то это наверняка привлекло бы внимание к проекту. По крайней мере я, наверное, пересел бы на это с Intellipad'а.
ОК. Постараемся сделать такой интерфейс. Только учти, что наши грамматики — это не BNF. Другие парсеры их могут попросту не смочь спарсить.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Visor2004, Вы писали:
V>Не всегда так, есть рукописные файлы такого объемы неоднократно видел такие в UI библиотеках от Infragistics и Cronwood. У лично пару раз были в проектах рукописные файлы около 1Mb
Мегабайт — это все еще приемлемо для риалтаймного перепарсивания всего исходника. На дворе не 90-ы прошлого века, а 2012-й год. Процессоры все как один перевалили за 1 Ггц. Память, даже на телефонах, измеряется сотнями метров. А на десктопе гигами.
Короче по умолчанию выбираем стратегию грубой силы. Если не прокатит, то будем выкручиваться.
Полное перепарсивание резко упрощает реализацию. Не надо возиться с потярянными скобками, с препроцессорами и т.п.
Если бы мы делали парсер для одного языка, может быть извращения и были бы просты. Но делая универсальное решение вероятность нарваться на грабли слишком высока.
Здравствуйте, nikov, Вы писали:
N>Как обстоят (будут обстоять) дела с инкрементальным парсингом? Имеется в виду локальное обновление AST при редактировании кода в большом файле.
Кстати, если не секрет. В Рослике инкрементальный парсинг планируется? Или вам хватает скорости и так?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Все такие просьба добавить возможность в одном модуле определять и синтаксис и его использование. А>Для начинающих так на много удобнее.
В общем, постараемся сделать удобные интерактивные средства отладки грамматик. Но реально расширения будут по прежнему компилироваться в отдельные сборки, и в больших проектах (языках и ДСЛ-я) они будут четко отделены.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _Claus_, Вы писали:
_C_>Еще кто-то буду спорить, что нужно создавать свою студию, с Web-возможностями?
Я буду спорить. Реализовать качественный интеллисенс в вебе не простая задача. К тому же это все рано будет игрушечная реализация. Ведь не будет поддержки проектов.
То что сделано в котлине сделано за счет Явы. Чисто вебный интерфейс там совсем убогий (нет интелисенса).
Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _Claus_, Вы писали:
_C_>>Еще кто-то буду спорить, что нужно создавать свою студию, с Web-возможностями?
VD>Я буду спорить. Реализовать качественный интеллисенс в вебе не простая задача. К тому же это все рано будет игрушечная реализация. Ведь не будет поддержки проектов.
чего не будет? если удаленный интерфейс будет 1 в 1 или близко повторять локальный..
VD>То что сделано в котлине сделано за счет Явы. Чисто вебный интерфейс там совсем убогий (нет интелисенса).
пока дойдет до добавления интеллисенса что-то наверняка придумается. это по любому не космическая сложность.
VD>Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее.
а зачем его встраивать? фреймворк должен транслировать вызовы и принимать прозрачно для .Net кода (см ссылку)
вопрос в том, подходит что готовое для этого, или все таки надо делать.
Здравствуйте, VladD2, Вы писали:
VD>То что сделано в котлине сделано за счет Явы. Чисто вебный интерфейс там совсем убогий (нет интелисенса)
Есть. У меня работал и довольно шустро. VD>Как не парадоксально, но дотнет встраивается в браузеры с большим скрипом нежели Ява. Так что нам будет сложнее.
У меня нет выпилен из браузеров. Ие не пользуюсь и на работе удалил со всех компов ибо достали порнобанеры у пользователей. С хромом и лисицей проблем нет. Ие 9 это кошмар админа.