> token Digit > token Number > Два из них, «Digit» и «Digits»
Так Number или Digits? Ниже ещё раз Number упоминается.
> Правило «s» также является специальным видом правила – void-правилом.
Предложение построено так, словно мы об этом правиле уже успели что-то прочитать.
> В лексерных правилах (помеченные ключевым словом token)
помеченныХ
> Например, если в приведенном выше правиле Number удалить использование правила «s»
А его там и нет. И без него многое в "предупреждении" на тему s и S непонятно (например: "оно все равно будет подставлено автоматически" — куда именно?). Хотя в общем это не настолько тонкий и важный для понимания идеи момент, чтобы в него вгрызаться в процессе чтения обзорной статьи.
Синтаксический модуль
> Если в правиле появилось явное использование предопределенного правила «s» (или «S»), N2 не будет ожидать явного указания пробельных символов (не будет вставлять правило «s» самостоятельно).
N2 не будет ожидать
> Правило Number является обычным (не лексерным) правилом.
NumberLiteral
> Такие правила вводят новое дерево разбора – ParseTree.
Содержащее, в том числе, значение NumberLiteral.Value, я так понимаю?
Импорт синтаксических модулей
> В ней используется правило «Number», объявленное в модуле «Literal».
NumberLiteral
Расширяемые правила
> Так как синтаксические модули являются независимыми единицами правила между ними не видны автоматически
Запятая после "единицами"
> using ExpressionPlusesExtentsion
опечатка
> using cp = Expression; // псевдоним для синтаксического модуля CalcParserExpression
опечатка
Re[2]: замечания, часть 1 (раздел "Синтаксический модуль")
Здравствуйте, dimgel, Вы писали:
>> token Digit >> token Number >> Два из них, «Digit» и «Digits» D>Так Number или Digits? Ниже ещё раз Number упоминается.
Это результаты ручного рефакторинга без тестов . Спасибо, поправлю.
Digits там было не по делу, так как это описание числа с плавающей точкой.
>> Правило «s» также является специальным видом правила – void-правилом. D>Предложение построено так, словно мы об этом правиле уже успели что-то прочитать.
Я его тоже из примера удалил. Видимо зря. Сейчас восстановлю. Просто в процессе эволюции синтаксиса исчезла декларация типов для правил. Она осталась только для void-правил. Я решил его просто спрятать, но уши остались .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
> Для токена объявленного отдельным правилом класс
две запятых вокруг причастного оборота (или как оно там называется)
> LiteralTokenClass – описывает класс токена автоматически задаваемый всем литеральным токенам (за исключением токенам описывающим скобки). > BracketsTokenClass — описывает класс токена автоматически задаваемый всем токенам описывающим скобки.
запятые перед "автоматически" и перед "описывающим"
гаммар наци негодуэ
> Действия этих настроек распространяются на текущий синтаксический модуль и все модули в которые он импортирован. Таким образом для расширений
запятые после "все модули" и "таким образом"
> переоределить ее в текущем модуле или будет выдано сообщение
запятая перед "или"
> используется ключевое слово «brackets» за которым сделет
запятая после «brackets»
> Ниже приведен пример демонстрирующий использование
запятая после "пример"
> Подсветка кода зависит от классов токенов заданных при определении языковых конструкций.
запятая после "токенов"
> Автор этих конструкций может, как использовать предопределенные классы токенов описанные выше, так и ввести свои.
запятая после "может" — лишняя
> Для задания типа подсветки, при этом, так же используются классы токенов.
При этом, для задания типа подсветки так же используются классы токенов. (впрочем, не настаиваю)
> Конкретные цвета используемые при подсветке токенов задаются в настройках IDE.
запятые вокруг причастного оборота (или как оно там называется)
Здравствуйте, dimgel, Вы писали:
>> BracketsTokenClass — описывает класс токена автоматически задаваемый всем токенам описывающим скобки. D>запятые перед "автоматически" и перед "описывающим" D>гаммар наци негодуэ
Арфаграфия и пуктуация в новых разделах не проверялись пока . Сори.
Не надо пока на них обращать внимание. Завтра выверим, вот тогда можно будет пройтись не замыленным взглядом.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Собственно опечатки — это очень хорошо. Но хотелось бы услышать критику по существу вопроса. Насколько понятно получилось? VD>Какие вопросы остаются после прочтения?
Ну я ещё не дочитал, а уже как минимум один вопрос, разжёванный ниже, успел задать.
Вопросы в основном проистекают из-за незнакомого синтаксиса. Если пытаться мотать на ус, а не просматривать типа фельетончик в общих чертах, то вот тут, например:
syntax NumberLiteral = number
{
where number : Number;
Value : decimal = decimal.Parse(GetText(number));
}
Я так и не понял сакральный смысл того, что "number" тут дублируется в первой строке и в where. В where, как я понял, объявляется тип подправила и типы полей. Но чем именно является "number"? Ты пишешь: "будет создан тип NumberLiteral с полем number типа Number и Value типа decimal". Следовательно, number — это поле. А что тогда оно делает в первой строке после "NumberLiteral = "?
Здравствуйте, dimgel, Вы писали:
>> Такие правила вводят новое дерево разбора – ParseTree. D>Содержащее, в том числе, значение NumberLiteral.Value, я так понимаю?
Да об этом говорится позже. ОК, добавил это для ясности.
D>Импорт синтаксических модулей
>> В ней используется правило «Number», объявленное в модуле «Literal». D>NumberLiteral
Сенкс.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
D> syntax NumberLiteral = number
D> {
D> where number : Number;
D> Value : decimal = decimal.Parse(GetText(number));
D> }
D>
D>Я так и не понял сакральный смысл того, что "number" тут дублируется в первой строке и в where. В where, как я понял, объявляется тип подправила и типы полей.
Не совсем так. В "where" указывается подправило грамматики ассоциируемое с параметром. А уже сама грамматика определяет тип поля.
Это описывается ниже. Мне кажется, для чистоты эксперимента надо дочитать до конца.
D>Но чем именно является "number"?
Именем поля.
У нас две задачи.
1. Описать подправило грамматики.
2. Дать ему имя.
Сейчас, кстати, это делается по другому. В теле правила всегда описывается чистая грамматика, а имена задаются в атрибуте Ast().
Проблема этого подхода заключается в том, что имена приходится задавать позиционно. Это довольно неудобно и приводит к массе ошибок. Особенно при рефакторинге.
D>Ты пишешь: "будет создан тип NumberLiteral с полем number типа Number и Value типа decimal". Следовательно, number — это поле. А что тогда оно делает в первой строке после "NumberLiteral = "?
Определяет грамматику. С полем ассоциируется не тип, а подправило грамматики. Тип поля автоматически выводится из описания подправила. Например, если подправило это ссылка на другое именованное правило, то типом поля будет тип этого правила (совпадает с именем правила). Если же это цикл "SomeRule*", то тип будет list[SomeRule].
Если не ошибаюсь — это тоже описано ниже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://stdray.livejournal.com/65441.html?thread=292513#t292513:
>Есть вопросы.
> 1) В гайде ты упоминал, что инструкции, написанные внутри блока scope {}, прозрачно применяются, когда мы входим в блок, и отменяются, когда мы из него выходим. Прозрачно отменяются? Это как?
При выходе из внешнего скопа закрывается и вложенный. При закрытии скопа все его настройки автоматически теряются и начинают действовать настройки внешнего скопа.
> 2) Можно ли механизмом публикации символов реализовать области видимости для параметров по умолчанию, а именно что-то типа: > def foo(x: Int, y: Int = x * x) = ??? // компилируется > def bar(x: Int, y: Int = z * z, z: Int = 42) = ??? // ошибка
Такой порядок будет по умолчанию. Вот если не хочется, чтобы параметры были доступны при описании других параметров, то нужно будет указать, что их скопы распространяются только на тело функции.
> 3) Можно ли в текущей модели символов сделать имплиситы, а именно: > class Foo > class Bar { def bar = ??? } > implicit def foo2bar(foo: Foo) = new Bar > new Foo().<...> > ><...> должен увидеть bar
Можно. Но это уже будет действовать механизм типизации куда интегрируется механизм разрешения перегрузки.
>4) Можно ли в текущей модели типов реализовать higher-kinded полиморфизм?
Систему типов ты описываешь сам (если не используешь предопределенную). Типизацию — тоже. Так что что опишешь то и будет.
Вопрос только на фиг оно надо? Ну, второго порядка еще куда не шло. А н-ного — перебор, по-моему. В прочем, если есть нужда...
>Экзистенциальные типы? Зависимые типы? Пересечения и объединения? null-safety цейлоновской мощности?
Да нам что? Вы определяете как типы будут унифицироваться. Если в результате унификации два типа дадут пересечение, то будете с ним возиться. Вопрос только во что вы его в последствии преобразуете (когда будете код генерировать).
И вообще, наша задача подогнать модель под реальные потребности, а не заставить всех натягивать свои потребности на имеющиеся возможности. По сему если даже мы что-то не учтем по первой, то поправим потом.
>5) Можно ли реализовать erasure, например, для юзкейса, описанного в треде выше?
Если я правильно понял что ты хочешь, то в N2 этого просто не нужно. В исходном языке типы такие какие они есть и не нужно их удалять/стерать. А вот кода ты пишешь преобразование в язык более низкого уровня, то ты вполне можешь опустить подробности и сгенерировать более простой тип или более общий.
>6) Аналогичный вопрос про специализацию полиморфных типов для ситуаций, когда рантайм-специализация неприемлема или недоступна.
Мы просто не оперируем такими понятиями. Мы предоставляем общий механизм типизации который можно настраивать под язык. Правила описания типов в своем языке ты задаешь сам. То во что этот код потом развернется тоже задаешь ты сам.
>7) Как планируется реализовывать интеграцию в IDE? Есть ли на эту тему информация?
Есть. И если читать внимательно, то не трудно ее заметить .
>Особенно интересует скорость отклика.
Ну, мы постараемся чтобы было по шустрее. Можете нам помочь в этом плане исследованиями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Про систему типов понятно. Я думал, что-то опущено в тексте статьи, но теперь вроде ясно — просто есть максимально общий фреймворк. Отлично.
Насчет IDE я потому и спросил, что в статье только конспективно. Интересно было бы узнать подробности. Скажем, нажимаю я ctrl+space. Что происходит дальше?
Здравствуйте, xeno.by, Вы писали:
XB>Насчет IDE я потому и спросил, что в статье только конспективно. Интересно было бы узнать подробности. Скажем, нажимаю я ctrl+space. Что происходит дальше?
Получаешь дополнение текущего символа.
Технически проходит парсинг в специальном режиме. В нем отслеживается позиция курсора и если в ней находится некий символ, то он обрабатывается специальным образом. Если в обычном режиме мы пытаемся найти полное соответствие символа, то в этом мы ищем префикс, подстроку (определяется функцией фильтрации) или некий другой символ (например, точку в ООЯ). Далее, если найден ровно один символ, то мы его молча комплитим. Если найдено несколько символов, мы создаем список комплита как сумму всех возможных значений символа.
Возможно в грамматике придется описать места возможного комплита. Это уже детали которые надо будет продумать по глубже.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Если в обычном режиме мы пытаемся найти полное соответствие символа, то в этом мы ищем префикс, подстроку
То есть, получается, мы ищем по таблице символов? А что если автокомплит включает в себя тайпчек (как с имплиситами)?
Еще вот сегодня Женя Кирпичев запостил свои впечатления об ADD: http://antilamer.livejournal.com/431555.html, где упомянул, что в чем-то N2 и MPS похожи. Я про MPS знаю только понаслышке, поэтому было бы интересно услышать подробности — где похожи, где отличия.
Здравствуйте, xeno.by, Вы писали:
VD>>Если в обычном режиме мы пытаемся найти полное соответствие символа, то в этом мы ищем префикс, подстроку XB>То есть, получается, мы ищем по таблице символов?
Не только. Разрешение типов тоже нужно производить. Это на всех стадиях работает. Фактически в стандартную процедуру вводятся "закладки" которые перехватывают обработку в нужный момент.
XB>А что если автокомплит включает в себя тайпчек (как с имплиситами)?
Он по любому включает. Скажем если мы комплитим
x.y.z|
то перед тем как закомплитить z нам нужно вычислить что такое y.
Но тут проблема в том, что и x и y могут сами по себе быть перегруженными, так что для них нужно вычислять все перегрузки, а z искать внутри них (всех).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, xeno.by, Вы писали:
XB>Еще вот сегодня Женя Кирпичев запостил свои впечатления об ADD: http://antilamer.livejournal.com/431555.html, где упомянул, что в чем-то N2 и MPS похожи. Я про MPS знаю только понаслышке, поэтому было бы интересно услышать подробности — где похожи, где отличия.
Если честно, я тоже об МПС знаю только понаслышке. Я вообще не Явский человек.
Надо будет поставить посмотреть.
Судя по этому ролику. Похожего действительно много. Ну, а главное различие — это то что в МПС отказались от текста и предлагают писать программы в формах ввода. Мы же на против считаем, что код — это в первую очередь текст. Я должен иметь право работать с ним как хочу.
Ну, и конечно же в МПС нет понятия макроса. Они не дают манипулировать АСТ программы (если я все правильно понял). Мы же, как немерловые люди, хотим получить систему которая это предоставляет. Соответственно продумываем эти возможности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
XB>>Еще вот сегодня Женя Кирпичев запостил свои впечатления об ADD: http://antilamer.livejournal.com/431555.html, где упомянул, что в чем-то N2 и MPS похожи. Я про MPS знаю только понаслышке, поэтому было бы интересно услышать подробности — где похожи, где отличия.
VD>Ну, и конечно же в МПС нет понятия макроса. Они не дают манипулировать АСТ программы (если я все правильно понял). Мы же, как немерловые люди, хотим получить систему которая это предоставляет. Соответственно продумываем эти возможности.
Не совсем так. Скорее уж весь MPS это один сплошной макрос. Мы определяем типы синтаксических узлов и для них определяем: форму отображения в редакторе, правила типизации, правила dataflow, правила scoping, правила трансформации в другой AST или прямо в конечный текст, правила для отладчика... Например, джавские узлы трансформируются прямо в текстовый исходник на джаве. А надстройки (например, лямбда-литералы и пр.; я вот делал монаду асинхронности тоже) трансформируются в джавские узлы или в другие надстройки.
Притом MPS "метациклический", т.е. все эти правила также описываются в MPS-овских редакторах и их синтаксис и семантика описаны на MPS.
Если есть еще какие-то вопросы, могу Вас связать с людьми из команды MPS.
Здравствуйте, jkff, Вы писали:
VD>>Ну, и конечно же в МПС нет понятия макроса. Они не дают манипулировать АСТ программы (если я все правильно понял). Мы же, как немерловые люди, хотим получить систему которая это предоставляет. Соответственно продумываем эти возможности.
J>Не совсем так. Скорее уж весь MPS это один сплошной макрос.
Этак можно про любой язык сказать.
J>Мы определяем типы синтаксических узлов и для них определяем: форму отображения в редакторе, правила типизации, правила dataflow, правила scoping, правила трансформации в другой AST или прямо в конечный текст, правила для отладчика...
Да я как бы и так это все понял. Но это все совершенно не то. МПС средство для создания нерасширяемых языков.
Понимаю, что звучит это странно, но похоже это так. МПС не предполагает трансформацию программ. И тем более не предполагает трансформацию программ в самих в себя.
Попробую объяснить смысл сказанного мной выше. Возьмем к примеру макро-атрибуты. Классическим примером, пожалуй, является макрос Record.
1. Этот макрос не имеет какого-то своего синтаксиса. Он имеет синтаксис пользовательского атрибута применяемого к типам. Если в области видимости открыто пространство имен в котором объявлен макрос, то выбирается макрос. Иначе производится поиск аналогичного атрибута.
2. Этот макрос формирует конструкцию (конструктор) того же самого языка. Причем делает это на основании списка полей класса и других макро-атрибутов примененных к ним (атрибутов RecordIgnore).
3. Конструкторы генерированные макросом влияют на процесс типизации выражений.
4. Макросы действуют не по одиночке, а зависят друг от друга. Другие макросы могут генерировать поля, что может влиять на работу макросов генерирующих конструкторы по полям и так далее.
Я ночью поглядел МПС. Заметил там какое-то наличие ручного манипулирования АСТ, но мне кажется, что это вряд ли моно рассматривать как штатное средство. Да и почти уверен, что геморрой с зависимостями в МПС не разрулить.
J>Например, джавские узлы трансформируются прямо в текстовый исходник на джаве. А надстройки (например, лямбда-литералы и пр.; я вот делал монаду асинхронности тоже) трансформируются в джавские узлы или в другие надстройки.
Это я и так понимал, но это не то. Этого мало.
J>Притом MPS "метациклический", т.е. все эти правила также описываются в MPS-овских редакторах и их синтаксис и семантика описаны на MPS.
Это все тоже понятно.
Я покапал МПС этой ночью. Многие идеи похожи. Много общего. Но недостатков в их подходе не мало. Я потратил 4 часа на воспроизведение банального if-а. На Nemerle 1.х или на N2 у меня на это ушло бы менее минут.
Понятно, что у меня не было опыта использования МПС. Но все же я знаком со всеми необходимыми концепциями и просмотрел множество материала. Так что по идее за пол часа я должен был бы справиться.
Кроме того редактор на основе форм переодически просто бесит. Если неудобство еще можно терпеть, то исчезновении информации при редактировании — это пипец! Возникает желание швырнуть ноут в стену .
J>Если есть еще какие-то вопросы, могу Вас связать с людьми из команды MPS.
Спасибо. Я думаю, что мы с ними по любому свяжемся. С кое-кем из ДжетБрэйнса я знаком. Но не с теми кто работает над МПС.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
. Спасибо, поправлю.
