Re[2]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 12:07
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Теперь есть хороший бэкенд, ответом должен быть хороший фронтэнд. N2 можно стартовать.


Я вчера смотрел рослин на этот предмет. Выводы не совсем утешительные. Типизированный апи (который там называется SemanticModel) полностью закрыт. Сгенерировать свое типизированное дерево (а, скорее всего, именно с него генерируется код) извне невозможно. Не уверен, но возможно, что SemanticModel плотно привязан к парс-три и без него просо не будет работаь. А это вообще ошибка дизайна, на мой взгляд.

Остается только генерировать дерево разбора шарпа (у них оно называется SyntaxTree, далее для простоты, буду называть его АСТ). Но тут тоже вылезут свои проблемы. Основная — это то, что рослин будет повтрно, и о своим правилам производить типизацию сгенерированного АСТ. А это означает, что АСТ должно быть однозначным. Но описать однозначное в рслин нельзя.

Например, вот как у них выглядит АСТ вызова функции/метода:
    //     Class which represents the syntax node for invocation expression.
    public sealed class InvocationExpressionSyntax : ExpressionSyntax
    {
        //     ArgumentListSyntax node representing the list of arguments of the invocation
        //     expression.
        public ArgumentListSyntax ArgumentList { get; }

        //     ExpressionSyntax node representing the expression part of the invocation.
        public ExpressionSyntax Expression { get; }

        public InvocationExpressionSyntax Update(ExpressionSyntax expression, ArgumentListSyntax argumentList);
    }

Очевидно, что Expression не позволяет задать вызываемую функцию однозначно. Ведь в шарпе даже нет возможности указать тип (сигнатуру) функции (нет даже такого понятия).

Вот если бы в МС помогли бы нам и ввели еще одну ветку АСТ (или расширили InvocationExpressionSyntax), так чтобы кроме выражения можно было бы так же четко задать сигнатуру функции которую нужно вызвать, то нам было бы проще.

А так остается только попытаться помочь рослину поставив перед каждым выражением аргумента по явному приведению типов (и надеяться на то что в таких условиях его вывод типов будет работать как надо).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 12:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>И ее потом придется, каким то образом засунуть обратно в дерево.

WH>Вот это выглядит весьма сомнительно. Особенно если дерево глубокое и нужно поменять несколько методов.
WH>
WH>root = root.ReplaceNode(method, newMethod);
WH>


КО>>Вот. Будет интересно послушать любые соображения. Повторюсь, я от функциональных паттернов не отнекиваюсь. За первые 10 минут я не разобрался, как zipper применить для нашей проблемы. Буду разбираться дальше, но любая дополнительная помощь очень приветствуется. На первый взгляд кажется что нам хранить "текущий элемент" (дырку, или как они говорят, фокус) не нужно. Т.к. заранее неизвестно какое свойство узла пользователь будет менять.

WH>Фокус нужно хранить на тот элемент свойства, которого хочешь поменять.
WH>А у этого фокуса уже сделать методы типа SetModifiers.

Как я понял они реализовали что-то вроде зипера (внутри). Реально все свойства АСТ выглядят так:
public sealed class MemberAccessExpressionSyntax : ExpressionSyntax
{
  // Fields
  private ExpressionSyntax expression;
  private SimpleNameSyntax name;

  // Methods
  internal MemberAccessExpressionSyntax(SyntaxNode parent, SyntaxNode green, int position) : base(parent, green, position)
  {
  }

  internal override void Accept(SyntaxVisitor visitor)
  {
    visitor.VisitMemberAccessExpression(this);
  }

  internal override TResult Accept<TResult>(SyntaxVisitor<TResult> visitor)
  {
    return visitor.VisitMemberAccessExpression(this);
  }

  internal override SyntaxNode GetCachedSlot(int index)
  {
    switch (index)
    {
      case 0:
        return this.expression;

      case 2:
        return this.name;
    }
    return null;
  }

  internal override SyntaxNode GetNodeSlot(int index)
  {
    switch (index)
    {
      case 0:
        return base.GetRed<ExpressionSyntax>(ref this.expression, 0);

      case 2:
        return base.GetRed<SimpleNameSyntax>(ref this.name, 2);
    }
    return null;
  }

  public MemberAccessExpressionSyntax Update(ExpressionSyntax expression, SyntaxToken operatorToken, SimpleNameSyntax name)
  {
    if (((expression == this.Expression) && !(operatorToken != this.OperatorToken)) && (name == this.Name))
    {
      return this;
    }
    MemberAccessExpressionSyntax node = Syntax.MemberAccessExpression(base.Kind, expression, operatorToken, name);
    SyntaxAnnotation[] annotations = base.GetAnnotations();
    if ((annotations != null) && (annotations.Length > 0))
    {
      return node.WithAnnotations<MemberAccessExpressionSyntax>(annotations);
    }
    return node;
  }

  // Properties
  public ExpressionSyntax Expression
  {
    get
    {
      return base.GetRed<ExpressionSyntax>(ref this.expression, 0);
    }
  }

  public SimpleNameSyntax Name
  {
    get
    {
      return base.GetRed<SimpleNameSyntax>(ref this.name, 2);
    }
  }

  public SyntaxToken OperatorToken
  {
    get
    {
      return new SyntaxToken(this, (SyntaxToken) base.Green.GetSlot(1), this.GetChildPosition(1), base.GetChildIndex(1));
    }
  }
}
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[6]: [API] Наш ответ рослину?
От: Kpoxa http://kuklaora.blogspot.com
Дата: 20.10.11 14:10
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Еще одна проблема — они полностью закрыли АПИ типизации. Создать объекты семантической модели можно только изнутри компилятора (они все интерналом помечены). А было бы куда лучше, если бы это апи так же было доступно для прямого конструирования. Тогда мы бы без труда навернули немрл (точнее уже свой язык) поверх рослина.


Так тож ctp.
Может попробовать пообщаться с авторами?
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 14:18
Оценка:
Здравствуйте, Kpoxa, Вы писали:

VD>>Еще одна проблема — они полностью закрыли АПИ типизации. Создать объекты семантической модели можно только изнутри компилятора (они все интерналом помечены). А было бы куда лучше, если бы это апи так же было доступно для прямого конструирования. Тогда мы бы без труда навернули немрл (точнее уже свой язык) поверх рослина.


K>Так тож ctp.


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

По сему в МС будут с нехотой делать типы публичными. Ведь если тип не публичный, то они не должны его поддерживать (могут изменить без объявления войны).

K>Может попробовать пообщаться с авторами?


Гы. А мы тут что делаем? Кирил Осенков и есть человек из команды Рослина.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: catbert  
Дата: 20.10.11 14:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>От перегрузок будет рябить в глазах. Лучше чуть расширить язык.


Не думаю, что будет страшнее, чем System.Windows.Forms.Form.

А язык расширить — да, лучше
Re[6]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 15:01
Оценка:
Здравствуйте, catbert, Вы писали:

C>Не думаю, что будет страшнее, чем System.Windows.Forms.Form.


На код генерируемый дизайнером форм смотреть обычно не приходится. Да и не так уж он страшен (хотя сам дизайнер еще то прикол).

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

В прочем всяко лучше чем сейчас.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 15:16
Оценка:
Здравствуйте, dotneter, Вы писали:

Z>>А какие проблемы? Код переписывать можно. Берем обычные атрибуты, ищем их в коде и меняем дерево так как нужно.

D>Вот я не увидел, где можно взять код допустим метода и переписать, везде работают со строками.

Ну как же, прямо по ссылке в исходном посте есть пример:

[TestMethod]
public void TransformTreeUsingSyntaxRewriter()
{
    string text = "class C { void M() { } int field; }";
    SyntaxTree tree = SyntaxTree.ParseCompilationUnit(text);
    SyntaxNode newRoot = new RemoveMethodsRewriter().Visit(tree.Root);
    Assert.AreEqual("class C { int field; }", newRoot.GetFullText());
}


Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.
Re[6]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 15:51
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

Это и есть работа со строкой.
Вопрос, можно ли сделать
class Foo { void M() { } int field; }
SyntaxTree.Parse(typeof(Foo));
И что бы потом еще все изменения залить опять в Foo
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[7]: [API] Наш ответ рослину?
От: hardcase Пират http://nemerle.org
Дата: 20.10.11 15:56
Оценка:
Здравствуйте, dotneter, Вы писали:

D>И что бы потом еще все изменения залить опять в Foo


Это всетаки не JavaScript
/* иЗвиНите зА неРовнЫй поЧерК */
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 16:03
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Это и есть работа со строкой.

D>Вопрос, можно ли сделать
D>class Foo { void M() { } int field; }
D>SyntaxTree.Parse(typeof(Foo));
D>И что бы потом еще все изменения залить опять в Foo

Нет.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 16:05
Оценка:
Здравствуйте, dotneter, Вы писали:

Z>>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

D>Это и есть работа со строкой.

Строка там парсится и дальнешая работа ведется с АСТ. Ты выидимо хочешь что-то вроде квази-цитат. Этого нет и не предвидится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 17:03
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Z>>>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

D>>Это и есть работа со строкой.

VD>Строка там парсится и дальнешая работа ведется с АСТ. Ты выидимо хочешь что-то вроде квази-цитат. Этого нет и не предвидится.

Квази цитирование для конструирования аст, меня же интересует собственно возможность реализовать того же механизм что и у немерла, в момент копляции как то получить аст объекта что бы его трансформировать.
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[9]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 17:19
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Квази цитирование для конструирования аст, меня же интересует собственно возможность реализовать того же механизм что и у немерла, в момент копляции как то получить аст объекта что бы его трансформировать.


Ну, вот я и говорю — нет и (видмо) не предвидится.

Вот давайте вместе просить тех кто делает Рослин хотя бы о том, чтобы их АПИ позволило без траха встроить нужную функциональность самостоятельно.

Мы подумываем об использовании рослика как бэкэнда для немерла.

Ну, а если бы дали точки входа, то (с большой вероятностью) можно было бы и к шарпу удобную метасистему прикрутить (но бещ расширения синтаксиса).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: [API] Наш ответ рослину?
От: dotneter  
Дата: 20.10.11 17:38
Оценка:
Здравствуйте, VladD2, Вы писали:

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


D>>Квази цитирование для конструирования аст, меня же интересует собственно возможность реализовать того же механизм что и у немерла, в момент копляции как то получить аст объекта что бы его трансформировать.


VD>Ну, вот я и говорю — нет и (видмо) не предвидится.


VD>Вот давайте вместе просить тех кто делает Рослин хотя бы о том, чтобы их АПИ позволило без траха встроить нужную функциональность самостоятельно.


Если они за пять лет разработки сами не додумались, я сомневаюсь что там может что то поменяться.
... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>
Talk is cheap. Show me the code.
Re[11]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 18:07
Оценка:
Здравствуйте, dotneter, Вы писали:

D>Если они за пять лет разработки сами не додумались, я сомневаюсь что там может что то поменяться.


У них цели такой не было. Им был дан приказ сделать компилятор. Сейчас еще не поздно что-то поменять. Не так много надо сделать, чтобы предоставить нужные возможнсоте.

Где-то событие добавить. Где-то чуть расширить структуры данных. Где-то типы пабличными (вместо интернал) следать. А в результате компайлер-эс-сервисес превратится из пиара в реальность.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 18:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Я вчера смотрел рослин на этот предмет. Выводы не совсем утешительные. Типизированный апи (который там называется SemanticModel) полностью закрыт. Сгенерировать свое типизированное дерево (а, скорее всего, именно с него генерируется код) извне невозможно. Не уверен, но возможно, что SemanticModel плотно привязан к парс-три и без него просо не будет работаь. А это вообще ошибка дизайна, на мой взгляд.


Это семантическая модель C#. Думаю вообще не стоит использовать Roslyn.Compilers.CSharp, а только Roslyn.Compilers. Там бэкэнды по генерации кода и чтению метаданных (в том числе и CCI). Ну и всякие интересные для парсера/компилятора типы данных.

Правда там тоже:
[assembly: InternalsVisibleTo("Roslyn.Compilers.CSharp")]



Что может помешать ее использовать в самых неожиданных местах.

VD>Остается только генерировать дерево разбора шарпа (у них оно называется SyntaxTree, далее для простоты, буду называть его АСТ). Но тут тоже вылезут свои проблемы. Основная — это то, что рослин будет повтрно, и о своим правилам производить типизацию сгенерированного АСТ. А это означает, что АСТ должно быть однозначным. Но описать однозначное в рслин нельзя.


VD>Очевидно, что Expression не позволяет задать вызываемую функцию однозначно. Ведь в шарпе даже нет возможности указать тип (сигнатуру) функции (нет даже такого понятия).


VD>А так остается только попытаться помочь рослину поставив перед каждым выражением аргумента по явному приведению типов (и надеяться на то что в таких условиях его вывод типов будет работать как надо).


Видимо ты имел ввиду разрешение перегрузок, а не вывод типов? Если есть сигнатура полностью подходящая под типы параметров — она и будет выбрана, без вариантов. То есть да, для реализации перегрузок немерла аргументы должны быть типизированы им же.

Обидно другое, скорость компиляции упадет еще сильнее. Так что генерация AST шарпа вариант интересный (в том числе и тем, что можно компилировать прямо в исходный код, этого многие хотели), но надо очень хорошо подумать перед выбором этого направления.
Re[10]: [API] Наш ответ рослину?
От: WolfHound  
Дата: 20.10.11 18:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мы подумываем об использовании рослика как бэкэнда для немерла.

Тут не все так просто.
Нужно еще будет выяснить под какой это все лицензией.
Ибо если нельзя будет использовать немерле под моно на линухе то оно того не стоит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 18:36
Оценка:
Здравствуйте, dotneter, Вы писали:

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


Z>>Я еще не копался, но RemoveMethodsRewriter визитор по дереву выражений, удаляющий некий метод.

D>Это и есть работа со строкой.
D>Вопрос, можно ли сделать
D>class Foo { void M() { } int field; }
D>SyntaxTree.Parse(typeof(Foo));
D>И что бы потом еще все изменения залить опять в Foo

Ничего не понял. Какой typeof(Foo) на этапе компиляции Foo.cs?

Код парсится в АСТ, АСТ скармливается компилятору. Между парсером и компилятором можно вклиниться, но стандартных механизмов для этого нет, надо писать свою обертку к компилятору. Чем больше я смотрю на сборки рослина, тем больше вижу, что все возможности расширения закрыты в очень многих местах и это не радует .
Re[5]: [API] Наш ответ рослину?
От: Ziaw Россия  
Дата: 20.10.11 18:41
Оценка:
Здравствуйте, VladD2, Вы писали:

Z>>Надо просто сделать Roslyn.Nemerle, который предоставит нормальный DSL для всего этого (квазицитаты и PM).


VD>Это будет другой язык. Для него опять же нужно от печки клепать всю инфраструктуру.


Ну конечно, это будет N2. Для него и так надо все клепать почти от печки.

VD>Было бы куда лучше, если бы они сразу заложили нужные точки входа. Например, в виде событий.


Куда заложили, в комиплятор C#? Если добавим туда МП, то похерим nemerle. Только вот, когда я пишу на шарпе, я не только по МП скучаю.
Re[11]: [API] Наш ответ рослину?
От: VladD2 Российская Империя www.nemerle.org
Дата: 20.10.11 20:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Мы подумываем об использовании рослика как бэкэнда для немерла.

WH>Тут не все так просто.
WH>Нужно еще будет выяснить под какой это все лицензией.

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

WH>Ибо если нельзя будет использовать немерле под моно на линухе то оно того не стоит.


Речь не идет о полном переходе на это дело. Но как один из бэкэндов его использоать будте можно. Причем это нам гарантирует, что код скомплированный на немерле можно будет запустить на любой платформе где будет работать код скомпилированный на шарпе.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.