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

_>А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
Такого не будет.
Я изначально предлагаю типизировать код до того как начнутся преобразования.
Соответственно мы просто описываем связи между типами и узлами АСТ.
Далее просто запускается алгоритм вывода типов, который на основе описанных для каждого куска АСТ правил выводит все типы.
Понижение уровня языка начинается уже после того как все типы выведены.

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

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

_>>А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
WH>Такого не будет.
WH>Я изначально предлагаю типизировать код до того как начнутся преобразования.
WH>Соответственно мы просто описываем связи между типами и узлами АСТ.
WH>Далее просто запускается алгоритм вывода типов, который на основе описанных для каждого куска АСТ правил выводит все типы.
WH>Понижение уровня языка начинается уже после того как все типы выведены.

Я правильно понимаю, что ты предлагаешь типизировать результат раскрытия макроса только на основании информации о его констрейнтах (правилах), не принимая во внимание информацию из "внешней" части ast?

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

S>А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта.

Понял, что для работы макроса может понадобиться информация о типе, поэтому раскрыть его до типизаци нельзя. Например это может быть макрос, производящий маппинг датаридеров на объекты. Может на самом деле выделять в макросе участки, отрабатывающие на разных фазах компиляции? Как бонус, в режиме IDE часть фаз вообще можно будет не запускать. Что то вроде rewrite WolfHound-а, но более многоуровневый.

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

S>Я правильно понимаю, что ты предлагаешь типизировать результат раскрытия макроса только на основании информации о его констрейнтах (правилах), не принимая во внимание информацию из "внешней" части ast?
Правила могут ссылаться на "внешний" АСТ.
Без этого вообще ничего типизировать нельзя.

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

S>Понял, что для работы макроса может понадобиться информация о типе, поэтому раскрыть его до типизаци нельзя. Например это может быть макрос, производящий маппинг датаридеров на объекты. Может на самом деле выделять в макросе участки, отрабатывающие на разных фазах компиляции? Как бонус, в режиме IDE часть фаз вообще можно будет не запускать.
Так а я о чем говорю?

S>Что то вроде rewrite WolfHound-а, но более многоуровневый.
Мой rewrite многоуровневый что звездец.
Он понижает уровень языка. А дальше будут вызваны переписыватели для языка более низкого уровня, которые понизят уровень языка еще сильнее и так пока не будет получен код на целевом языке.

Здравствуйте, Аноним, Вы писали:

А>Представляю, что не выносится на публику

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

Но не надо так остро воспринимать это, так уж сложилось, что немного грубости в рсдн дискуссиях — норма.

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

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

S>>Я правильно понимаю, что ты предлагаешь типизировать результат раскрытия макроса только на основании информации о его констрейнтах (правилах), не принимая во внимание информацию из "внешней" части ast?
WH>Правила могут ссылаться на "внешний" АСТ.
WH>Без этого вообще ничего типизировать нельзя.

А можно пример ссылки на внешний AST?
И как будет типизовываться такая конструкция:

def x = macro(a);

где macro() раскрывается в
<[ another_macro(a) ]>

а another_macro() в свою очередь раскрывается в a.ToString()? ведь пока не раскроются macro и another_macro тип x не может быть определен. Тут нужно или описывать возвращаемый another_macro тип в его констрейнтах, либо раскрыать его до типизации.

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

S>а another_macro() в свою очередь раскрывается в a.ToString()? ведь пока не раскроются macro и another_macro тип x не может быть определен. Тут нужно или описывать возвращаемый another_macro тип в его констрейнтах, либо раскрыать его до типизации.
Остается выяснить, какую задачу ты решаешь.
Судя по названию макросов никакую.

Ты пойми, я не собираюсь делать систему, в которой можно делать какие угодно выкрутасы.
Я хочу сделать систему для решения практических задач.
И ты не придумаешь ни одной практический задачи, в которой нельзя описать правила типизации АСТ.

_>>А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
WH>Такого не будет.
WH>Я изначально предлагаю типизировать код до того как начнутся преобразования.

Т.е. ты предлагаешь разделить преобразования типов и преобразования кода на разные, возможно даже независимые, стадии. Значит каждый макрос должен содержать минимум две программы (декларативные или императивные — сейчас не важно): 1) это преобразование типов; 2) это реврайтинг кода с уже зафиксированными типами, так? А некий тайпер довывыводит то чего нехватает между этими стадиями?

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

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

S>>а another_macro() в свою очередь раскрывается в a.ToString()? ведь пока не раскроются macro и another_macro тип x не может быть определен. Тут нужно или описывать возвращаемый another_macro тип в его констрейнтах, либо раскрыать его до типизации.
WH>Остается выяснить, какую задачу ты решаешь.
WH>Судя по названию макросов никакую.

WH>Ты пойми, я не собираюсь делать систему, в которой можно делать какие угодно выкрутасы.
WH>Я хочу сделать систему для решения практических задач.
WH>И ты не придумаешь ни одной практический задачи, в которой нельзя описать правила типизации АСТ.

Ну ладно, пусть это будут макрос, генерирующий анонимные типы. Пока его не раскроешь, типизация испоьзующего его кода будет невозможна. Как предлагаешь ее решать? Не представляю, как можно описать декларативно тип, возвращаемый этим макросом. Тогда уж нужно вводить до реврайта еще одну фазу — вычисление возвращаемого типа.

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

S>Ну ладно, пусть это будут макрос, генерирующий анонимные типы. Пока его не раскроешь, типизация испоьзующего его кода будет невозможна. Как предлагаешь ее решать? Не представляю, как можно описать декларативно тип, возвращаемый этим макросом. Тогда уж нужно вводить до реврайта еще одну фазу — вычисление возвращаемого типа.
Не нужно.
У нас на входе макроса есть все данные, чтобы вывести тип.

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

_>Т.е. ты предлагаешь разделить преобразования типов и преобразования кода на разные, возможно даже независимые, стадии. Значит каждый макрос должен содержать минимум две программы (декларативные или императивные — сейчас не важно):
3.
Парсинг. Типизация. Понижение уровня языка.

_>1) это преобразование типов; 2) это реврайтинг кода с уже зафиксированными типами, так? А некий тайпер довывыводит то чего нехватает между этими стадиями?
Не очень понял что за "преобразование типов".
Смысл в том, что после парсинга запускается типизатор который на основе правил описанных для АСТ произведет всю типизацию всего кода.

Понижение уровня языка будет уже после того как будут выведены все типы. Причем оно будет запускаться только во время компиляции. В режиме IDE этот код никто никогда вызывать не будет. Разве что для того чтобы показать во что развернется макрос.

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

S>>Ну ладно, пусть это будут макрос, генерирующий анонимные типы. Пока его не раскроешь, типизация испоьзующего его кода будет невозможна. Как предлагаешь ее решать? Не представляю, как можно описать декларативно тип, возвращаемый этим макросом. Тогда уж нужно вводить до реврайта еще одну фазу — вычисление возвращаемого типа.
WH>Не нужно.
WH>У нас на входе макроса есть все данные, чтобы вывести тип.

С этим я не спорю. Данные есть, но где будет располагаться логика, выводящая тип по этим данным? В самом макросе? В компиляторе? Он может не иметь представления о семантике макроса.

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

WH>В концепцию Влада это не впишется никак.
WH>В моей системе это будет из коробки. Причем что характерно я про такой вариант даже не думал. Просто изначально строил целостную и не противоречивую систему.

Гы-гы. Ты явно даже не задумывался над тем как твои идеи смогут работать в режиме IDE, когда времени на типизацию всех тел просто нет, а каждый метод может типизировать от нуля до бесконечности раз.

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

_>Допустим вот возникла идея создания макроса "dynamic-наоборот".

_>

_>def f(o : dynamic)
_>{
_>  o.StringProp = "MaxValue = ";
_>  def max = Math.Max(o.Prop1 : int, o.Prop2 : int);
_>  Console.WriteLine(o.StringProp + max.ToString());
_>  o.Method(max);

_>  o.| //тут автокомплит показывает что o уже имеет StringProp, Prop1, Prop2 и Method(max : int) : void;
_>}
_>

Подобный подход конфликтует с работой под управлением IDE. Сам понимаешь, что в условиях когда метод может типизироваться по много раз и в разном порядке обеспечить подобный интеллисенс можно только в рамках одного метода.

Я бы предложит тут другое решение:

def f(o : dynamic[IFakeInterface])
{
  o.StringProp = "MaxValue = ";
  def max = Math.Max(o.Prop1 : int, o.Prop2 : int);
  Console.WriteLine(o.StringProp + max.ToString());
  o.Method(max);

  o.| //тут автокомплит показывает что o уже имеет StringProp, Prop1, Prop2 и Method(max : int) : void;
}

IFakeInterface — это интерфейс привязываемый к динамику только для целей поддержки интелисенса. В рантайме будет данимическая диспетчеризация.

Что же касается поддержки массивов с типизированными индексерами, то мне кажется тут лучше всего подошел бы класс-обертка, а не навороты на макросах.

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

S>>Ну ладно, пусть это будут макрос, генерирующий анонимные типы. Пока его не раскроешь, типизация испоьзующего его кода будет невозможна. Как предлагаешь ее решать? Не представляю, как можно описать декларативно тип, возвращаемый этим макросом. Тогда уж нужно вводить до реврайта еще одну фазу — вычисление возвращаемого типа.
WH>Не нужно.
WH>У нас на входе макроса есть все данные, чтобы вывести тип.

Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.

Сколтько можно игнорировать факты и упираться рогом в стену?

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

S>Если выполнять все стадии циклически то это будет трэш по производительности. Имхо ограничиться только частичной перетипизацией не получится, ведь новые типы могут сильно повлиять на уже сформированное дерево и верхние/нижние границы типов.

На самом деле новые типы не могут влиять на старые, так как старые формировались когда они отсутствовали. Новые типы как бы дополняют систему. Если бы это было не так, то в Н1 нельзя было бы добавить типы на поздних стадиях компиляции. А это сделать можно.

S>А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта. По моему вопрос двух(или более)-фазной работы макросов здесь уже обсуждался. Эти идеи не вошли в N2?

Есть только одна проблема — тела методов во время работы IDE могут типизироваться многократно и в хаотическом порядке. Это делает сложным добавление типов из процесса раскрытия (или типизации) макросов внутри тел методов.

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

VD>Очень часто данных у тебя не будет. Я уже устал повторять христоматийные примеры: linq, foreach, ... В них конкретные типы зависят от того во что макрос раскрывается. Это прямо в спецификацию C# записано.
А уже устал повторять, что вся информация есть.

VD>Сколтько можно игнорировать факты и упираться рогом в стену?
Вот. Вот.
Перестань упираться рогом в стену и прекрати нести пургу.
Самому же потом стыдно будет, когда это все заработает.

И что характерно ты точно также упирался рогом, когда я алгоритм парсинга изобретал.

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

S>Понял, что для работы макроса может понадобиться информация о типе, поэтому раскрыть его до типизаци нельзя.

Это заблуждение. На самом деле бывает по разному. Макросы вроде linq нельзя раскрывать после типизации, так как типизация возможна только на раскрытом представлении. Почитай спецификацию C#. Там ясно сказано, что семантика linq-запросов выражается исключительно через нетипизированное переписывание в query-паттерн.

Иногда наличие типов для отдельных параметров макроса является необходимым. Но это далеко не частый случай.

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

VD>>Они были с самого начала. Просто ты игнорируешь все что мешает построению твоей теории заговора.
WH>Начинаем тыкать носом:

Перестань хамить.

WH>

WH>TAST и AST не расширяемы. Точнее их можно расширять в процессе эволюционирования фрэймворка. Если у нас появляется язык который, например, для повышения производительности получаемого кода требует новую конструкцию, то мы посовещаемся и добавим новый подтипа TAST и/или AST.

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

Я для себя до сих пор не решил нужно ли заводить разные типы для TAST или можно свалить все в один тип, и программно контролировать отсутствие неких конструкций после преобразования (как это сделано в Н1).

VD>>Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил,
WH>Это очень трудно не делать особенно когда я тебе полгода вколачиваю в голову некоторую идею, а потом вдруг оказывается что ее придумал ты.

Я бы описал ситуацию с точностью до наборот. Вот как-то (месяца три назад) я тебе подсунул идею использования Pratt-а, а через месяц ты меня задолбал объяснением того, что ты это все придумал.

Причем, мне в общем-то по фигу. Но вот это вот постоянная заносчивость действительно напрягает.

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

VD>>и занялся бы совместным поиском правильных подходов.
WH>Довольно трудно заниматься совместным поиском, когда ты даже не пытаешься понять то о чем я говорю.

Я тебя понял. Идея типизации по SST придумана сильно раньше чем ты до нее дошел. Я ее видел и долго обдумывал возможность ее применения. В результате я пришел к выводу, что в чистом виде она не работает. Ты пока что не занимался глубоким анализом, от того и думаешь, что все будет шоколадно. Если бы ты просто потрудился рассмотреть все аспекты, то наверняка согласился бы со мной.

VD>>Да, и мне уже порядком осточертели твое наезды и хамство. Я стараюсь держаться, но желание вести беседу в подобном ключе стремительно улетучивается.
WH>Ты бы на себя посмотрел.

Я пытаюсь быть с тобой максимально корректным.