Можно получить сравнение этих продуктов?
Здесь можно создать парсер и добавить элемент себе в программу при это получив подсветку, подсказки и все прелести .
Что может предложить Nitra сейчас и будет ли нечто подобное в будущем ?
Здравствуйте, _NN_, Вы писали:
_NN>Здесь можно создать парсер и добавить элемент себе в программу при это получив подсветку, подсказки и все прелести .
Не верю. Чтобы получить внятные подсказки одного парсера мало.
Я эту штуку не трогал, но вот эта "фича" смущает:
На первый взгляд, какая-то хрень.
_NN>Можно получить сравнение этих продуктов?
Мне в лом смотреть на это. Даже рекламный проспект говорит, что смотреть не на что.
_NN>Здесь можно создать парсер и добавить элемент себе в программу при это получив подсветку, подсказки и все прелести .
Из чего это следует? Из того что на странице ничего такого сказать нельзя. Все что там сказано "Designed to integrate easily with SyntaxEditor".
Для подсветки вообще парсер не нужен. Достаточно лексера. Для подсказок и прочих прелестей парсера мало. Нужна еще и типизация.
_NN>Что может предложить Nitra сейчас и будет ли нечто подобное в будущем ?
Тут уже 100 раз об этом говорили. Повторяться просто не хочу.
Скачай, посмотри. За одно и это чудо скачай и сравни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
_NN>Можно получить сравнение этих продуктов? _NN>Здесь можно создать парсер и добавить элемент себе в программу при это получив подсветку, подсказки и все прелести . _NN>Что может предложить Nitra сейчас и будет ли нечто подобное в будущем ?
По опыту использования — наблюдаю одну из последних версий их редактора с парсером в связке. В проекте в одном файле смешивается C# и простенький DSL для получения извратного domain-specific C#
Сумбурно опыт использования Actipro:
1) Сделать простую подсветку чисто синтаксиса можно очень быстро. Буквально за один день. Если готов ограничиться только подсветкой — вроде грамматику можно даже в одном XML описать и всё. Никаких генераторов запускать не надо, просто указать что такое-то расширение открывать с таким xml-описанием.
2) Возможность смешения языков в одном файле у Actipro сделана отлично — ни я ни чел который собственно добивал PoC-код до релиза, не смогли даже вспомнить включилась ли оно само, или надо было что-то нажать
3) Сворачивание блоков и регионов у них в редакторе включилось также само. Причём для скобочек совсем само, для более сложных конструкций очень легко.
4) Интеллисенс — тут гораздо хуже. Код из C# не видел объявления сделанные в DSL, в самом DSL автокомплит то видел то не видел объявления из C#. Из за этих то видимостей то невидимостей автокомплит отключили вовсе, отключили также их подстветку ошибок — т.к. она подсвечивала всё подряд. Их саппорт старался помочь, но возникло ощущение что дописывать (нам у себя) прилично надо. Если чисто один C# редактировать, то там для встроенного скрипт-редактора в приложении очень прилично работает. Не студия с решарпером конечно, но самые нужные подсказки, типа там имён методов и свойств, получить вполне беспроблемно.
5) У них отличная модель подсветки любых участков кода, позволяющая навешивать собственную подсветку на что угодно, в том числе и на текст обработкой которого занимаются их парсеры. Соответственно отключив интеллисенс и их подсветку ошибок, мы включили ручками подчёркивание красным по Compile того кода в котором ошибку находил C#-компилятор, и получили работоспособное решение достаточно близкое к желаемому.
5.1) В редакторе мутят с LineEnding, стараясь игнорировать \r, из-за чего надо два раза думать, когда определяешь строку в которой хочется что-то подсветить или позиционируешься курсором на место ошибки.
6) Не уверен касается ли эта информация XML-описания, или их LL-Фреймворка, но мы столкнулись со стандартным делением токенов на виды, из-за чего возникали всякие сложности с обработкой контекстно-зависимых слов, типа from,var и т.п. Причём вроде даже в ситуациях где этих сложностей быть не должно. Так как язык для внутреннего пользования разработчиками, то забили, но если нужен скриптовый язык для широкого круга случайных нубов, то явно пришлось бы поприседать.
7) Их отладчик грамматик нам совсем никак и ни чем ни разу не помог. Но вполне может быть это была более предыдущая версия отладчика. На скриншоте выглядит почти также.
8) Как только дело доходит до дописывания каких-то штучек для более корректной работы грамматики — лучше сразу поискать обходной путь, чем день терять на фигню
9) Показательна их собственная C#-грамматика, которая идёт так сказать искаропки — когда выкатывается интеллисенс, он вываливает все возможные продолжения, неважно будут они компилироваться или нет. Наример если в классе C есть поле типа Enum E, у которого есть значение E, то C.E.E.| вывалит ещё одно E в куче с методами и ToString но без экстенешнов Студия и решарпер себе такого не позволяют. Исходя из этого я подозреваю что даже для них самих не всё так просто как описано в рекламе.
10) Автокомплит своего кода у нас работал только если код был уже скомпилирован и мы вытягивали оттуда для Actipro метаданные. Так чтобы объявить сверху класс, и строкой ниже его заиспользовать, типовой юз-кейс программиста — сходу не вышло. На детальные разборки времени просто не было — их пример C#-редактора вроде! умеет (нормально не проверял, может они просто идентификаторы регекспами вытягивают).
Всё вышеперечисленное касается именно нашего юз-кейса, когда два языка хочется смешать по типу того как сделано в MVC/Razor. Возможно если делать один язык, без смешения грамматик, будет существенно лучше. Лучше всего у них сделана C#-грамматика. Это то чего с их фреймворком можно добиться в пределе. Я часто заглядывал туда рефлектором когда делал концепт — у них рукопашного кода было чуть ли не больше чем генерённого, что добавляло грусти. У того-же JetBrains C# парсера соотношение генерённый/рукопашный по ощущениям повыше было.
Как у Nitra можно описать "А вот отсюдова и до забора мы пишем не на своём блабе а на чистом C# грамматика которого лежит там, а список уже сделанных объявлений типов вот он" — я вообще пока не знаю. Так что объективно сравнить не могу. Самому, кстати, весьма интересно.
Здравствуйте, hi_octane, Вы писали:
_>По опыту использования — наблюдаю одну из последних версий их редактора с парсером в связке. В проекте в одном файле смешивается C# и простенький DSL для получения извратного domain-specific C#
Сейчас один тут использует этот продукт для формирований улучшенного интерпретатора и подсказок языка Python .
Что-то в стиле LINQPad, очень удобно.
В дальнейшем планирует создавать простой DSL.
_>Всё вышеперечисленное касается именно нашего юз-кейса, когда два языка хочется смешать по типу того как сделано в MVC/Razor. Возможно если делать один язык, без смешения грамматик, будет существенно лучше.
Тут не знаю, но то что я видел работало вполне хорошо.
_>Как у Nitra можно описать "А вот отсюдова и до забора мы пишем не на своём блабе а на чистом C# грамматика которого лежит там, а список уже сделанных объявлений типов вот он" — я вообще пока не знаю. Так что объективно сравнить не могу. Самому, кстати, весьма интересно.
Вот это хотелось бы узнать, а не "VD> Мне в лом смотреть на это. Даже рекламный проспект говорит, что смотреть не на что.".
На данный момент есть продукт который можно использовать и который я видел что работает, а вот в Nitra (где-то месяц назад я проверял) у меня подсветка даже не работала.
Здравствуйте, _NN_, Вы писали:
_NN> www.actiprosoftware.com _NN>Можно получить сравнение этих продуктов?
Мне кажется, это несколько по-хамски просить людей сделать за тебя работу. Нужно — бери и сравнивай, кто запрещает-то? Сейчас, судя по ситуации, команде Немерли совсем не до этого — нужно писать функционал, а не заниматься маркетингом. А учитывая, что немерлисты пишут Нитру после опыта полноценного компилятора, можно смело предположить, что их инструмент будет как минимум не хуже актипрошного.
Здравствуйте, btn1, Вы писали:
B>Здравствуйте, _NN_, Вы писали:
_NN>> www.actiprosoftware.com _NN>>Можно получить сравнение этих продуктов?
B>Мне кажется, это несколько по-хамски просить людей сделать за тебя работу. Нужно — бери и сравнивай, кто запрещает-то? Сейчас, судя по ситуации, команде Немерли совсем не до этого — нужно писать функционал, а не заниматься маркетингом. А учитывая, что немерлисты пишут Нитру после опыта полноценного компилятора, можно смело предположить, что их инструмент будет как минимум не хуже актипрошного.
Ключевое слово "будет".
При таком сравнении я даже не буду смотреть на Нитру в ближайшее время пока не выйдет релиз.
Вот если нитра предлагает 90% , то остальную часть можно уже и самому приделать, а если есть всего лишь парсер без ничего то это не подходит.
Здравствуйте, hi_octane, Вы писали:
_>Как у Nitra можно описать "А вот отсюдова и до забора мы пишем не на своём блабе а на чистом C# грамматика которого лежит там, а список уже сделанных объявлений типов вот он" — я вообще пока не знаю. Так что объективно сравнить не могу. Самому, кстати, весьма интересно.
Можно.
Найтра инструмент для создания любых языков. Ты в своём блабе можешь сделать синтаксическую конструкцию, которая разбирает чистый C# и подсовывает контекст с нужными объявлениями.
Ещё можно C# расширить конструкциями для связи с твоим блабом и передать в него сущности из блаба которые будут понимать новые конструкции.
А если твой блаб не похож на C# то даже отдельных конструкций не нужно. Найтра сама поймет, что C# начался.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, _NN_, Вы писали:
_NN>При таком сравнении я даже не буду смотреть на Нитру в ближайшее время пока не выйдет релиз.
Не смотри. Но сравнивать с черт знает чем никто для тебя не будет.
_NN>Вот если нитра предлагает 90% , то остальную часть можно уже и самому приделать, а если есть всего лишь парсер без ничего то это не подходит.
Она уже предлогает не мало, а будет предлагать все что нужно для создания расширяемого изыка.
Как правильно заметил btn1 нам сейчас не до рекламы. Мы работаем над дсл–ями связывания и областей видимости.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, _NN_, Вы писали:
_>>Как у Nitra можно описать "А вот отсюдова и до забора мы пишем не на своём блабе а на чистом C# грамматика которого лежит там, а список уже сделанных объявлений типов вот он" — я вообще пока не знаю. Так что объективно сравнить не могу. Самому, кстати, весьма интересно. _NN>Вот это хотелось бы узнать, а не "VD> Мне в лом смотреть на это. Даже рекламный проспект говорит, что смотреть не на что.".
А как я тебе "это" расскажу? За тебя изучу этот продукт и использую его не пойми для каких целей?
Я могу рассказать, только то что написано в документации. Например:
The parser in our framework is LL(*), meaning it is a top-down parser that can run on a subset of context-free grammars. It parses input from left to right, traces leftmost derivation, and by default uses one symbol of look-ahead. This normally would mean LL(1), however can-match callbacks allow infinite symbol look-ahead, thus making it LL(*).
Перевожу на русский. У нас есть примитивынй интерпретируемый LL(1)-парсер который поддерживает колбеки используя которые вы можете попарсить что-то более сложное чем классический Паскаль. Вы будуте трахаться с приведением грамматики к LL(1)-форме и написанию ручных распознавателей (читай парсеров) в каждом неоднозначном месте. Восстановление после ошибок — это тоже ваша пробелма. Пишите ручные обработчики скипающие токены.
Ничего в области типизации в документации найти не удалось, так что можно предположить, что ты сам должен написать весь код типизации предварительно изучив все что с этим всязано. Встроенный типизатор шарпа при первых же тестах показал, что он неполноценный. Например, такая:
public class Program
{
int P { get { ret set; } }
}
конструкция не вызвала никаких нареканий в их C#-примере.
В общем, какой-то убогий лексерный LL(1)-парсер вокруг которого NN-решил развернуть интеллектуальную дискуссию и за одно обвинить окружающих, что они за него не разбираются с тем что он нашел. Таких паделок в интернета пруд пруди: http://en.wikipedia.org/wiki/Comparison_of_parser_generators
бери любой и изучай.
Но какой в этом смысл? И так понятно, что большая их часть не дотягивает даже до ANTLR 4.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Aleх, Вы писали:
A>В чем проблема разбиения на токены, если в грамматиках для нитры всё равно поддерживаются literal, regex, span?
У лексерных парсеров куча ограничений. У нас токены контекстные. Каждое правило может иметь свои токены. Более того это понятие довольно абстрактное. Оно нужно чтобы люди оперировали привычными им понятиями, и чтобы при восстановлении не оперировать символами. По сути Нитра парсит посимвольно.
Это дает возможность без "приседаний" парсить грамматики вроде ХМЛ-я где в разных контекстах разные лексические правила или C#-а с его контекстными ключевыми словами.
Ну, и главное — это позволяет объединять скомпилированные грамматики на лету (во время парсинга).
У продвинутых генераторов парсеров вроде ANTLR 4 лексеры поддерживают контексты, которые можно переключать в действиях лексера. Это кое как решает проблему парсинга языков вроде ХМЛ-я. Но с композицие грамматик у них все равно проблемы.
В данном же случае вообще речь идет о крайне примитивном лексерном LL(1)-парсере. Его LL(*) обеспечивается за счет рукопашного заглядывания вперед. Это было 10 лет назад в CocoR.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
