Пожалуй что мое представление о том каким должен быть типизатор Н2 созрело и я могу им поделиться.
Некоторые предпосылки... из чего я исхожу...
1. Следует изобретать новые идеи только тогда когда старые не удовлетворяют требованиям и нет путей изменить это.
2. Создание макросов в Н2 должно упроститься и не в коем случае не усложняться. Ради упрощения создания сложных макросов нельзя жертвовать простотой написания простых.
3. Если есть выбор между декларативным описанием и кодом, то лучше предпочесть декларацию (К.О.).
4. Framework разрабатываемый в процессе работы над Н2 должен брать на себя максимум работы. Писатель макросов и создатель новых языков должен делать только необходимый минимум.
5. Поддержка IDE и бэкэндов должны даваться получаться автоматически, за исключением тех фич котоыре которые полностью зависят от языка (например, рефакторинги). Для зависящих от языка фич должны предоставляться стандартные решения упрощающих реализацию.
Для того чтобы было понятнее как проходит процесс типизации придется начать с парсинга. Итак синтаксический макрос Н2 будет описывать:
1. Правило грамматики разбирающее строку.
2. Ветку SST описывающую все данные разобранные из строки. По сути это будут отдельные вхождения вариантного типа + разная информация необходимая для работы IDE (о токенах, подсветке, фолдинге, ...).
3. Тело макроса, вызываемое для раскрытия макроса.
4. Необязательные декларации, описывающие требования к макросу и его параметрам.
Стадии работы:
1. Парсинг. На этой стадии файл проекта парсится макросами, которые загружаются для отдельных типов файлов и могут по ходу разбора кода подгружать дополнительные макросы в точки ресширения. В конце этого процесса мы получаем CompileUnit содержащий SST (Specific Syntax Tree) файла.
2. Производится раскрытие макросов уровня типов не требующих информации о типах. В результате получается набор TypeBuilder-ов (возможно их нужно назвать особо, но подходящее имя в голову не приходит) по одному для каждого типа. Это не окончательные TypeBuilder-ы, так как могут быть partial-типы. На этом этапе TypeBuilder-ы содержат только MemberBuilder-s – типы описывающие AST членов. Эти типы содержат SST тел и преобразованные в стандартное AST описание члена. Кроме того TypeBuilder и MemberBuilder могут содержать любую дополнительную информацию обеспечивающую их специализацию.
3. Производится слияние TypeBuilder-ов всего проекта и формирование дерева типов проекта. В результате получается дерево ветвями которого являются пространства имен, а листьями – TypeBuilder-ы и реализации ITypeInfo полученные из внешних сборок и других проектов.
4. Выполнятся макросы уровня типов не требующие информации о наследовании.
5. Производится предварительное вычисление наследования и реализации интерфейсов для TypeBuilder-ов.
6. Выполняются макросы которым требуется информация о наследовании, но не требуется информация о типах членов.
7. Производится связывание типов членом.
8. Производится разложение MemberBuilder-ов на MethodBuilder-ы. В конечном счете в исполнимом коде могут быть только функции. Значит все члены типов должны быть в итоге преобразованы в них. Например, свойства должны быть преобразованы в методы гетыры и/или сетеры.
8. Производится связывание типов сгенерированных методов.
9. Выполняются макросы которые зависят от типов членов.
10. Производится типизация тел методов. До этого момента в них находится SST, точнее корнем является AST-ветка-заглушка которая ссылается на SST. На выходе получается TAST. Кроме того в процессе работы генерируется AST. При этом в ветки SST помещается ссылки на сгенерированные по ним ветку AST и TAST.
11. Результат работы – TypeBuilder-ы, MethodBuilder-ы и TAST передается бэкэнду который по ним генерирует исполняемые модули в которые помещаются код и метаданные.
Описание процесса типизации тел методов привожу отдельно...
Типизация тел методов
Обратите внимание на то, что под термином «типизация» вы можете понимать нечто отличное от того что понимаю я!
Перед началом процесса типизации в методе (объекте MethodBuilder) присутствует информация о типах параметров и возвращаемого значения, название метода, кастом-атрибуты, модификаторы, (возможно) дополнительная информация и код тела метода в виде SST.
Процесс типизации тела метода:
1. Типизатор обрабатывает ветку AST метода одну за одной (начиная с корневой ветки ссылка на которую находится в MethodBuilder).
2. Если ветка является ссылкой на SST, то производится процесс раскрытия макроса.
3. Полученная в результате раскрытия ветка макроса анализируется и если это снова оказывается ссылка на SST, то выполнение продолжается с пункта 1.
4. Если текущая ветка не ссылка на SST, то вызывается функция трансформации AST в TAST. В процессе этой трансформации вычисляются типы AST, производится разрешение перегрузки и т.п. Кроме всего прочего ссылка на TAST помещается в AST, а ссылка на AST в SST. Таким образом, после окончания процесса типизации выражения, по SST можно получить порожденное по нему AST и TAST. Точно такие же ссылки помещаются и TAST, так что через любой вид деревьев можно получить связанные с ними другие виды деревьев.
В процессе типизации ветки AST получают ссылки на TAST и типы. Среди веток TAST могут быть неоднозначные ветки. Если в TAST имеются неоднозначные ветки, производится повторный проход по TAST и попытка разрешить неоднозначности. Если в процессе повторного прохода изменился список неоднозначностей, то производится еще одна попытка до тех пор, пока список неоднозначностей не станет пуст – что считается успешным завершением типизации, или пока список неоднозначностей не перестанет изменяться – что является ошибкой типизации. В процессе разрешения неоднозначностей одни ветки TAST могут заменяться на другие. Например, MemberAccess заменен на Overloaded, а Overloaded на Resolved.
Процесс раскрытия макроса:
1. SST-ветке может соответствовать более одного макроса (Н2 будет поддерживать перегрузку макросов по условиям), по этому процесс раскрытия макроса включает процесс разрешения перегрузки макроса.
2. Получается список макросов соответствующих раскрываемому SST.
3. Список сортируется по приоритетам и его элементы перебираются в порядке убывания приоритета.
4. Для каждого макроса проверяются декларативные условия. Если условие истинно, запускается макрос (раскрытие макроса). В ином случае производится проверка условия для следующего элемента списка.
5. Если макрос успешно раскрылся, перебор списка останавливается, а результат раскрытия возвращается процессу типизации. Если в процессе раскрытия макроса произошла ошибка, то результат раскрытия запоминается и процесс продолжается с пункта 4.
6. Если декларативные условия не были удовлетворены ни для одной перегрузки выдается сообщение об ошибке (которое может быть задана авторами макроса или сформирована на основе декларативных условий).
7. Если некоторые из макросов были запущены, но ни один из них не смог успешно раскрыться, то формируется ветка Ast.Errors() в которую помещается список сообщений об ошибках выданный обломавшимися макросами.
Примеры
Пример перегруженного макрос (foreach):
macro ForEach : Ast.Expression
syntax: "foreach" "(" pattern "in" collection ")" body
where: pattern = Ast.PatternWithGuard,
collection = Ast.Expression,
body = Ast.Expression;
require: collection.Type as X && !X.IsPrimitive
require: X has <[ method GetEnumerator() : $E ]>
{
<[ /* реализация по умолчанию реализующая паттерн "перечислитель" */ ]>
}
// Перегрузка макры ForEach. macro ForEachIEnumarableT overload ForEach
require: collection.Type is IEnumarable[_]
priority: < ForEach // Срабатывает только если не срабатывает основной вариант
{
<[ /* реализация для IEnumarable[T] */ ]>
}
...
// Где-то в другом месте... возможно в другой сборке...macro ForEachArray overload ForEach
require: collection.Type is array[_]
priority: > ForEachIEnumarableT // попытка раскрыть этот макрос будет предпринята перед ForEachIEnumarableT
{
<[ /* реализация для массива */ ]>
}
Декларативные условия и порядок типизации
В макросах Н2 можно будет задать декларативные условия. Они позволяют описать зависимость макроса от типов выводимых для параметров макроса.
По умолчанию макрос получает на вход нетипизированное SST. Если макрос хочет чтобы ему на вход пришло типизированное SST для некоторого параметра, то он может задать условие (путем добавления секции «require»).
Минимальным условием является требование наличия выведенного типа. Это может выглядеть так:
require: collection.Type
Кроме того можно задать более конкретное условие, что тип должен быть фиксированным:
require: collection.Type is fixed
это подразумевает, что должен быть выведен как сам тип, так и всего его параметры типов (если таковые имеются).
Конструкция:
require: collection.Type is fixed[]
означает, что ожидается что выведен хотя бы сам тип, без учета параметров типов. «fixed» — это ключевое слово заменяющее любой имя типа.
Конструкция:
require: collection.Type is fixed[_]
означает, что должен быть выведен тип имеющий один параметр типа. Через запятую можно указывать нужное количество параметров типов.
Конструкция:
require: collection.Type is Name[_]
означает, что ожидается тип Name с одним параметром типов (вместо Name может быть подставлено любое имя типа, например IEnumarable). Аналогично fixed могут быть вариации с другим количеством параметров типов или без них.
Конструкция macroParameter.Type as Name позволяет задать имя для переменной типа. Далее в выражениях можно оперировать этим именем.
Так же в require могут использоваться операторы «&&» и «||», а так же произвольные выражения над типами (использующими API типов). Например, !X.IsPrimitive (из примера выше) означает, что тип не должен быть примитивным (например, int).
Так же возможно задавать условия на наличие у типа некоторых членов. Например:
X has <[ method GetEnumerator() : $E ]>
означает, что у типа X ожидается наличие метода GetEnumerator. Причем тип E можно в дальнешем использовать в рамках макроса или других условий. Например, мы можем проверить, что у типа E есть свойство Current:
E has <[ property Current : $D ]>
Если тип задан без $, то можно ссылаться на конкретные типы. При этом параметры типов так же могут быть переменными. Кроме того можно использовать «_» или ключевое слово fixed.
Условие
priority: < ИмяДругогоМакроса
позволяет задать приоритет относительно другого макроса. Это позволяет вызвать раскрытие данного макроса до или после того как будет произведена попытка раскрыть другой макрос.
Если в макросе задано условие на тип одного из параметров макроса, то компилятор вначале раскрывает и типизирует SST находящееся в этом параметре, а потом вызывает макрос передавая ему SST в котором имеется ссылка на AST и TAST, а поле Type содержит ссылку на выведенный тип.
Если в процессе типизации параметра макроса тип для него не был выведен, в достаточной степени, чтобы можно было проверить декларативное условие, то раскрытие всего макроса откладывается до тех пор, пока данный тип не будет выведен.
Таким образом декларативные условия не только позволяют макросу оперировать типами, но и влияют на порядок типизации и раскрытия макросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
и потом в методах которые разбирают АСТ в случае обнаружения типа Custom вызвать обработчик в зависимости от тега ( а сами обработчики добавляются в систему во время подгрузи макро-сборки)
Таким образом макрос нижнего уровня не будет делать всю работу, а просто создаст кастомный тип элемента АСТ а потом на этапе типизации и возможно даже кодо-генерации будет вызван нужный обработчик. Без необходимости пилять напильником сам компилятор.
BM>Не ограничиваться чисто макроссами. А сделать какойто-то тип элемента АСТ ктоторые будет служыть для росшырения
BM>...Таким образом макрос нижнего уровня не будет делать всю работу, а просто создаст кастомный тип элемента АСТ а потом на этапе типизации и возможно даже кодо-генерации будет вызван нужный обработчик. Без необходимости пилять напильником сам компилятор.
Я мало чего понял из сказанного.
Попробую ответить... Макрос не будет раскрываться во время парсинга (никогда). Вместо этого часть макроса отвечающего за парсинг будет генерировать SST. Код раскрытия (т.е. код самого макроса) будет привязан к SST. Само же раскрытие будет производиться потом (в зависимости от стадии макроса и его типа). Например, макросы уровня выражения будут раскрываться в процессе типизации.
Кроме синтаксических макросов будут так же не синтаксические. Как и сейчас эти макросы будут выглядеть как вызов функции или кастом-атрибут.
Любой макрос сможет в вернуть в результате своей работы АСТ содержащее обращение к другим макросам. Так что схема будет гибкой.
Для представления несинтаксических макросов в АСТ будет предусмотрена специальная ветка. Она будет похожа на предложенную тобой, но без object и другой грязи. Это будет ссылка на макрос и список его параметров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Для представления несинтаксических макросов в АСТ будет предусмотрена специальная ветка. Она будет похожа на предложенную тобой, но без object и другой грязи. Это будет ссылка на макрос и список его параметров.
Прикольно. А возможность расширить кодо-генерацию (плагин для бекенда) будет?
Здравствуйте, BogdanMart, Вы писали:
BM>Прикольно. А возможность расширить кодо-генерацию (плагин для бекенда) будет?
Бэкэнды и есть плагины. Их архитектура уже проблемы тех кто их будет писать.
Точно будут плагины до бэкэнда. Так то что я называю TAST скорее всего не будет монолитом, а будет иметь уровни. Вначале в TAST будут такие конструкции как замыкания, классы, методы, и т.п. Но будут преобразователи TAST цель которых может быть разной. Некоторые могут оптимизировать код. Другие преобразовывать высокоуровневые конструкции в более примитивные. Например, заменять замыкания на обращение к классам. Или заменять классы на работу с областями памяти. Вот такие преобразовыватели можно будет писать самому.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Точно будут плагины до бэкэнда. Так то что я называю TAST скорее всего не будет монолитом, а будет иметь уровни. Вначале в TAST будут такие конструкции как замыкания, классы, методы, и т.п. Но будут преобразователи TAST цель которых может быть разной. Некоторые могут оптимизировать код. Другие преобразовывать высокоуровневые конструкции в более примитивные. Например, заменять замыкания на обращение к классам. Или заменять классы на работу с областями памяти. Вот такие преобразовыватели можно будет писать самому.
О... уже пошли уровни в TAST.
Что я тебе про иерархию языков говорил...
Через полгода ты дойдешь до того что говорю я.
А через год ты мне начнёшь доказывать, что все придумал ты.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>О... уже пошли уровни в TAST.
Они были с самого начала. Просто ты игнорируешь все что мешает построению твоей теории заговора.
WH>Что я тебе про иерархию языков говорил... WH>Через полгода ты дойдешь до того что говорю я. WH>А через год ты мне начнёшь доказывать, что все придумал ты.
У тебя проблемы с ЧСВ. Серьезные, такие.
Мне плевать кто что придумал. Я вижу ошибки в твоих рассуждениях и говорю тебе об этом. При этом я не игнорирую разумные замечания которые выдаешь ты и другие. Учет замечаний меняет вектор развития мысли.
Я тебе сразу сказал, что я не против возможности типизации по SST при условии, что это необязательная возможность, так как очевидно, что этот подход не прокатывает во всех случаях и к тому же избыточен.
ЗЫ
Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил, и занялся бы совместным поиском правильных подходов.
Для этого нужно изложить свои идеи в максимально развернутом виде и проанализировать их. Я свои изложил. Очередь за тобой.
Да, и мне уже порядком осточертели твое наезды и хамство. Я стараюсь держаться, но желание вести беседу в подобном ключе стремительно улетучивается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Они были с самого начала. Просто ты игнорируешь все что мешает построению твоей теории заговора.
Начинаем тыкать носом:
TAST и AST не расширяемы. Точнее их можно расширять в процессе эволюционирования фрэймворка. Если у нас появляется язык который, например, для повышения производительности получаемого кода требует новую конструкцию, то мы посовещаемся и добавим новый подтипа TAST и/или AST.
VD>У тебя проблемы с ЧСВ. Серьезные, такие.
Это у тебя проблемы с памятью.
VD>Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил,
Это очень трудно не делать особенно когда я тебе полгода вколачиваю в голову некоторую идею, а потом вдруг оказывается что ее придумал ты.
VD>и занялся бы совместным поиском правильных подходов.
Довольно трудно заниматься совместным поиском, когда ты даже не пытаешься понять то о чем я говорю.
VD>Да, и мне уже порядком осточертели твое наезды и хамство. Я стараюсь держаться, но желание вести беседу в подобном ключе стремительно улетучивается.
Ты бы на себя посмотрел.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Пока всё обсуждение больше завёрнуто вокруг синтаксических макросов. Но ведь возможны и другие.
Допустим вот возникла идея создания макроса "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;
}
Ну а дальше по ситуации и воле разработчика. Например этот dynamic может создавать интерфейс IDynamic_f_o { String, Prop1, Prop2, Method }, а может просто записывать куда-нить в аттрибуты сигнатуру для o, чтобы давать по рукам если при использовании f(x) 'x' заведомо не поддерживает { String, Prop1, Prop2 }, и т.п.
Т.е. синтаксис не меняется ну совсем, а вот тип меняется с каждой операцией над o.
Как сейчас реализовать такое для N1 я примерно представляю (не уверен что получится, но хотя бы знаю куда копать). Но в Н2 типизация тел методов — это 10-й шаг, а для макросов такого вида может понадобиться возможность добавить на этом шаге в неймспейс свой генерённый TypeBuilder или ITypeInfo. А если кто-то захочет у себя отнаследоваться от IDynamic_f_o, то его наследование должно быть обработано только после типизации метода, потому что до того — самого IDynamic_f_o просто нету. А если макрос генерирует не IDynamic_f_o а допустим добавляет поля в существуюшую структуру, нужно ведь макро-аттрибуты этой структуры вызывать, например генераторы ISerializable или HashCode, только после того как поля добавятся.
Здравствуйте, WolfHound, Вы писали:
VD>>Мне очень хотелось бы, чтобы ты отбросил ЧСВ, перестал вести учет того что и когда ты предложил, WH>Это очень трудно не делать особенно когда я тебе полгода вколачиваю в голову некоторую идею, а потом вдруг оказывается что ее придумал ты.
Влад не то, что бы присваивает идеи, просто он регулярно делает компиляцию всего, что ему кажется разумным на текущий момент не расписывая где чья идея. То, что твои идеи туда попали говорит лишь о том, что Влад убедился в их разумности.
Все кто следит за проектом видят и ценят твои предложения. Они действительно свежи и оригинальны. Кто не следит тому пофиг чьи они.
Здравствуйте, hi_octane, Вы писали:
_>Пока всё обсуждение больше завёрнуто вокруг синтаксических макросов. Но ведь возможны и другие.
_>Допустим вот возникла идея создания макроса "dynamic-наоборот".
Обобщу, проблему составляют анонимные классы, создание вью-модели на лету, dynamic-наоборот.
Все подобные идеи сводятся к изобретению собственной структурной типизации и более глобальному выводу типов. Поскольку это фреймворк для языков, структурная типизация из коробки должна быть.
Здравствуйте, Ziaw, Вы писали:
Z>Влад не то, что бы присваивает идеи, просто он регулярно делает компиляцию всего, что ему кажется разумным на текущий момент не расписывая где чья идея. То, что твои идеи туда попали говорит лишь о том, что Влад убедился в их разумности.
Проблема в том, что Влад начинает мне доказывать, что это его идеи.
И что я бы до этого никогда не додумался.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?
В концепцию Влада это не впишется никак.
В моей системе это будет из коробки. Причем что характерно я про такой вариант даже не думал. Просто изначально строил целостную и не противоречивую систему.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Типизатора Н2 – версия VladD2
От:
Аноним
Дата:
02.06.11 08:05
Оценка:
Здравствуйте, WolfHound, Вы писали:
VD>>Да, и мне уже порядком осточертели твое наезды и хамство. Я стараюсь держаться, но желание вести беседу в подобном ключе стремительно улетучивается. WH>Ты бы на себя посмотрел.
Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ?
Представляю, что не выносится на публику
Здравствуйте, Аноним, Вы писали:
А>Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ?
Нормальный рабочий процесс поиска архитектурного решения
А>Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ? А>Представляю, что не выносится на публику
Не парься Процесс спора двух умных людей, даже если они время от времени переходят на личности, намного более продуктивен чем если бы один из них был начальником, навыдумывал себе чего-то, а потом выставил другому таску "делай как я сказал, и без самодеятельности". Так что как представитель коллектива разработчиков успешно использовавший ещё Nemerle 1 для разработки софта, могу тебя заверить, что повод для меланхолии ваш коллектив выбрал совершенно надуманный
Здравствуйте, <Аноним>, Вы писали:
А>Я, как представитель коллектива разработчиков корпоративного софта, планирующий использование в будущем Nemerle для разработки софта, подумываю — а нужен ли мне Nemerle, если внутри коллектива творится такая грызня ?
Коллектив в настоящий момент насчитывает свыше 30 участников, из которых около десятка принимают активное в развитии проекта прямо сейчас. То, что между некоторыми из них периодически возникают трения и конфликты — совершенно нормальное и ожидаемое явление, было бы странно, если бы их не возникало. Для проекта важно не столько то, что происходит и как происходит, сколько что получается на выходе. Однажды, на выходе после точно такого же спора получился Nemerle.Peg...
Ты лучше представь, какой rocket science тут начнется, когда они наконец найдут общий язык
WH>В моей системе это будет из коробки. Причем что характерно я про такой вариант даже не думал. Просто изначально строил целостную и не противоречивую систему.
А как? И как твоя система справится если макросы взаимно перевязаны, например функция f(o : dynamic) : IEnumerable[o:dynamic] где внутри макрос yield генерит стэйт-машину для ещё не до конца сгенерированного типа описывающего 'o'?
Короче можно какой-то список шагов, как у Влада, пройдя который мы сможем гарантировать что тип выведен, все макросы отработали, можно генерить MSIL? Пусть даже пока и без особенностей синтаксиса отдельных макросов.
Здравствуйте, hi_octane, Вы писали:
_>Как сейчас реализовать такое для N1 я примерно представляю (не уверен что получится, но хотя бы знаю куда копать). Но в Н2 типизация тел методов — это 10-й шаг, а для макросов такого вида может понадобиться возможность добавить на этом шаге в неймспейс свой генерённый TypeBuilder или ITypeInfo. А если кто-то захочет у себя отнаследоваться от IDynamic_f_o, то его наследование должно быть обработано только после типизации метода, потому что до того — самого IDynamic_f_o просто нету. А если макрос генерирует не IDynamic_f_o а допустим добавляет поля в существуюшую структуру, нужно ведь макро-аттрибуты этой структуры вызывать, например генераторы ISerializable или HashCode, только после того как поля добавятся.
_>В общем вопрос как такое, и другие "макросы виртуальных типов", например типизированные индесы массивов
, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?
Если выполнять все стадии циклически то это будет трэш по производительности. Имхо ограничиться только частичной перетипизацией не получится, ведь новые типы могут сильно повлиять на уже сформированное дерево и верхние/нижние границы типов.
А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта. По моему вопрос двух(или более)-фазной работы макросов здесь уже обсуждался. Эти идеи не вошли в N2?
Здравствуйте, seregaa, Вы писали:
S>Здравствуйте, hi_octane, Вы писали:
_>>Как сейчас реализовать такое для N1 я примерно представляю (не уверен что получится, но хотя бы знаю куда копать). Но в Н2 типизация тел методов — это 10-й шаг, а для макросов такого вида может понадобиться возможность добавить на этом шаге в неймспейс свой генерённый TypeBuilder или ITypeInfo. А если кто-то захочет у себя отнаследоваться от IDynamic_f_o, то его наследование должно быть обработано только после типизации метода, потому что до того — самого IDynamic_f_o просто нету. А если макрос генерирует не IDynamic_f_o а допустим добавляет поля в существуюшую структуру, нужно ведь макро-аттрибуты этой структуры вызывать, например генераторы ISerializable или HashCode, только после того как поля добавятся.
_>>В общем вопрос как такое, и другие "макросы виртуальных типов", например типизированные индесы массивов
, впишутся в концепцию Н2? Будут ли стадии работы выполнятся циклически пока последнее SST не превратится в TAST?
S>Если выполнять все стадии циклически то это будет трэш по производительности. Имхо ограничиться только частичной перетипизацией не получится, ведь новые типы могут сильно повлиять на уже сформированное дерево и верхние/нижние границы типов.
S>А если раскрывать такие макросы не во время типизации тел методов, а раньше? Раскрываем (фактически это и есть выполнеие макроса) на более раннем этапе, а типизируем сформированное макросом выражение уже когда сформировано дерево для всего проекта. По моему вопрос двух(или более)-фазной работы макросов здесь уже обсуждался. Эти идеи не вошли в N2?
А какие ограничения есть объединение всех стадий в одну?
почему не проводить все вместе по мере возможности?
