Здравствуйте, s22, Вы писали:
s22>собственно -- определение оператора и одновременное использование в этом же модуле?
В Nemerle так можно. Определение оператора не есть введение нового синтаксиса. Готов поспорить Nim разбирает любые последовательно идущие операторные символы как единый оператор.
И код вида
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, s22, Вы писали:
s22>>собственно -- определение оператора и одновременное использование в этом же модуле?
H>В Nemerle так можно. Определение оператора не есть введение нового синтаксиса. Готов поспорить Nim разбирает любые последовательно идущие операторные символы как единый оператор. H>И код вида
a*-2
выдаст ошибку: не знаем что делать с *-
Про немерли вопросов нет.....
как это будет на нитре?
нитра разбирает такой код и определяет новый оператор, какого приоритета?
как это будет выглядеть?
Здравствуйте, s22, Вы писали:
s22>как это будет на нитре?
s22>нитра разбирает такой код и определяет новый оператор, какого приоритета? s22>как это будет выглядеть?
Нитра позволяет расширять любую грамматику новыми правилами в рантайме. Операторы не исключение.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, s22, Вы писали:
s22>>как это будет на нитре?
s22>>нитра разбирает такой код и определяет новый оператор, какого приоритета? s22>>как это будет выглядеть?
VD>Нитра позволяет расширять любую грамматику новыми правилами в рантайме. Операторы не исключение.
Здравствуйте, s22, Вы писали:
VD>>Нитра позволяет расширять любую грамматику новыми правилами в рантайме. Операторы не исключение.
s22>не понимаю как....
extend syntax NamespaceMember
{
| TypeAliasDeclaration = "type" sm Identifier sm "=" sm QualifiedIdentifier ";"nl;
}
extend syntax Modifier
{
| Test = "!test test!" sm;
}
Основная грамматика (которую расширяют расширения). Правило NamespaceMember помечено атрибутом DynamicSyntaxExtentionPoint, а его подправило UsingImportDeclaration атрибутом DynamicSyntaxExtender:
[DynamicSyntaxExtentionPoint]
syntax NamespaceMember
{
| [DynamicSyntaxExtender] UsingImportDeclaration = "using" sm QualifiedIdentifier ";"nl;
| UsingAliasDeclaration = "using" sm Alias=Identifier sm "=" sm NsOrTypeName ";"nl;
| NamespaceDeclaration = "namespace" sm QualifiedName nl "{" inl Body=NamespaceBody d "}" nl;
| Class = Attributes Modifiers "class" sm Name nl "{" inl d "}" nl;
}
который с помощью класса-обходчика (UsingImportDeclarationWalker) добывает имя синтаксического модуля. Это имя используется для динамической загрузки синтаксического модуля содержащего правила. Эти правила динамически добавляются к текущему парсеру и парсер становится способным разобрать новый синтаксис.
Другими словами этот код использует директиву using для загрузки синтаксических расширений из внешней сборки с грамматиками. Там же есть тесты показывающие как это работает:
namespace Ns1
{
using N2ParserExtension1;
type X = // OK: Грамматика для type грузится динамически.
A.
B;
namespace Ns2
{
-
}
}
Другой пример:
namespace Ns2
{
using N2ParserExtension1;
[Asd]
!test test! // ОК: синтаксическое расширение загружено из N2ParserExtension1.class Asd
{
}
} // Здесь синтаксические расширения загруженные из N2ParserExtension1 выгружаются.
[Asd]
!test test! // Error: Здесь синтаксического расширения уже нет (оно выгружено).class Asd
{
}
Операторы тут ничем не отличаются. Просто надо расширять операторное правило. При этом ему можно будет задать приоритеты и ассоциативность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, s22, Вы писали:
VD>>>Нитра позволяет расширять любую грамматику новыми правилами в рантайме. Операторы не исключение. D>Операторы тут ничем не отличаются. Просто надо расширять операторное правило. При этом ему можно будет задать приоритеты и ассоциативность.
тут оператор определен в том же файле, что и его использование, это не помешает?
можно надеяться, что будет возможность в немерле в одном файле определять макрос и там же его использовать?
Здравствуйте, s22, Вы писали:
s22>тут оператор определен в том же файле, что и его использование, это не помешает? s22>можно надеяться, что будет возможность в немерле в одном файле определять макрос и там же его использовать?
Nitra (как и макры Nemerle) предполагает размещение расширений в отдельных сборках.
Но реализовать расширение операторов функциями можно, при определенных ограничениях. Немерл, например, это делать умеет.
Проблема только в том, что при этом нельзя задать приоритет и ассоциативность оператора. В Немерел, так же, есть проблема выделения оператора. Они выделяются по принципу идущих подряд операторных символов.
In Nim one can define his own operators. An operator is any combination of the following characters:
= + - * / < >
@ $ ~ & % |
! ? ^ . : \
These keywords are also operators: and or not xor shl shr div mod in notin is isnot of.
=, :, :: are not available as general operators; they are used for other notational purposes.
*: is as a special case the two tokens * and : (to support var v*: T).
В общем, это аналогичный немерловому подход.
С приоритетом и ассоциативностью там просто мрак (магия). Реализовать это на Найтре можно. Но сам дизайн мне катигорически не нравится. А уж приоритет зависящий от количества пробелов — это нечно!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.