В этой теме будут публиковаться мысли связанные со второй версий компилятора.
Приблизительная тематика:
1. Список фич отложенных до 2.0 (которые не будут реализованы в 1.0 или будут реализованы не полностью).
2. Изменения планируемые на вторую версию.
3. Стратегические и идеологические мысли по поводу 2.0.
4. Технические аспекты.
ЗЫ
Просьбы не засорять тему обсуждениями (открывайте другие темы). Эта тема — копилка того что нужно не забыть реализовать в 2.0 и для серьезных вопросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Поддержку сопоставления с образцом для nullable-типов
В 2.0 планируется реализовать новую систему синтаксических макросов (макросов расширяющих синтаксис языка).
Это потребует переработки всей системы парсинга.
Общая идея такова...
1. Из компилятора удаляются модули лексического и синтаксического разбора.
2. Вводится новый вид макросов описывающий синтаксис в виде PEG-нотации. Такой макрос при описании синтаксиса может пользоваться другими синтаксическими макросами доступными на момент компиляции (из других сборок) или находящихся в той же сборки что и данный. Этот вид макросов будет возвращать в результате своей работы АСТ. По всей видимости тип возвращаемого АСТ должен будет указываться при описании макроса.
3. Парсер собирается из доступных макросов. Каждый макрос рассматривается как правило грамматики языка. Результирующий парсер частично прекомпилируется (для конструкций верхнего уровня), а частично строится динамически (на основании открытых пространств имен, как это происходит с современными макросами).
4. В макросы вводятся функции самодокументирования. При описании макроса будет можно (или даже нужно) задать описание конструкции.
Плюсы данной схемы:
1. Парсер будет хорошо структурирован, что упростит его развитие.
2. Парсер будет полностью расширяемым (причем макросами, т.е. без изменения компилятора).
3. Будет возможно разбирать синтаксические конструкции любой сложности. Это позволит вводить практически не ограниченные синтаксические изменения. Например, конструкции вроде XML-я (не говоря уже о linq) можно будет описывать прямо правилами, а не загонять в строки и заниматься ручным парсингом внутри строк. В общем, почти полное снятие ограничений на разбираемые грамматики и возможность встраивать расширения прямо в язык.
4. Грамматика всего компилятора станет описываться декларативно.
5. Документацию к макросам, а значит и к самому языку можно будет генерировать автоматически.
Минусы:
1. В макросах нельзя будет производить побочных эффектов, так как правила описываемые макросами могут вызываться при парсинге ветвей грамматики которые в последствии будут отброшены как не верные.
2. Пока не ясно (и это следует обсудить) как в такой схеме воспроизвести синтаксис базируемый на отступах. Как вариант, можно просто от него отказаться. Возможно, что данную проблему получится решить самими же макросами (введя альтернативные макросы для парсинга последовательностей и элементов верхнего уровня. Хорошо бы, чтобы кто-то продумал это.
3. Парсер построенный в лоб на базе PEG неминуемо будет более медленным и прожорливым по сравнению с ручным. Это потребует потратить не мало времени на оптимизацию. Нужно реализовать генерацию ДКА для терминальных правил (разбирающих символы строки).
4. Весь код файла придется грузить в память перед парсингом (это требование алгоритма связанного с парсингом PEG-а). На сегодня это вряд ли будет проблемой. Если только на мобильных девайсах, где немерл и так не работает.
5. Придется парсить весь файл целиком, без предварительной токенизации и шага препарс (где на сегодня производится свертка токенов в группы). Это так же накладывает дополнительные требования на скорость парсинга (т.е. на оптимизацию PEG-а). Это же не позволит парсить части фалов (как это сейчас делает интеграция), но оно и правильно, так как это неминуемо ведет к проблемам в работе интеграции.
6. Грамматика используемая в макросах не должна быть лево-рекурсивной (так как это не поддерживается реализацией PEG-а) и должна будет подчиняться некоторым правилам разработанным для нашего PEG-парсера. Например, в операторах приоритетного выбора (... / ...) обязаны использоваться только имена правил (макросов) причем типы возвращаемых значений этих правил обязаны совпадать (или иметь общий базовый тип совпадающий с типом правила содержащего оператор приоритетного выбора).
7. Невозможно будет предсказать, что два подправила в операторе приоритетного выбора не конфликтуют. Правило стоящее первым будет всегда оказываться "победителем". Если правило разобралось, то для других даже не будет производиться попытка разбора. Возможно, имеет смысл кроме оператора приоритетного выбора PEG-а "/" ввести стандартный оператор перечисления равноценных правил "|" из BNF с тем, чтобы программисты могли явно выражать, что отдельные правила (макросы) не должны пересекаться и тем самым заставлять компилятор проверять это условие. Однако прочерка может оказаться трудной в реализации, так как для выявления эквивалентности правил придется строить для них конечный автомат (что приближает нас к ANTLR 3, и является весьма сложным занятием... особенно для динамически расширяемого парсера).
8. В макросах придется явно указывать пробельные символы. PEG позволяет обходиться без лексера, что координатно повышает гибкость и модульность парсера, но за это надо платить.
"macro class" — это класс позволяющий объединить несколько логически связанных макросов и методов реализации связанных с ними. Планируется, что "macro class" так же будет обеспечивать обработку событий связанных со стадиями компиляции и хранение состояния (в прочем тут нужно много думать, так как парсер PEG-а не любит глобального состояния).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).
Не уверен, что это хорошая идея с точки зрения производительности. Совместимость, конечно, сделать надо. Но можно ограничиться просто неявным приведением типов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>* Хинты Z>* Уметь менять подсветку Z>* По хорошему еще комплишенменеджер как-то указывать, но тут у меня думалка отказывает.
Подсказки и автодополнение при вводе работают на следующем уровне — на уровне AST. Для того чтобы все это дело работало корректно макросам нужно всего лишь правильно указать местоположения в возвращаемом AST. А эта задача резко упрощается за счет того, что сам парсер будет генерироваться (т.е. в нем не будет ошибок класса "забыли про что-то".
Остается одна проблема — макрос все же пишется вручную и именно его создатель должен указывать все местоположения (и не забывать про мелкие детали вроде местоположений скобок и т.п.). Возможно для простых случаев имеет смысл ввести автоматическую генерацию AST (по некоторому алгоритму или шаблону). Тогда за такие места можно будет не волноваться. Но по любому добиться точной информации о местоположениях будте намного проще (и если что, будет ясно где искать баги).
А вот с подсветкой проблема действительно может возникнуть.
Для PEG-а совершенно не нужны ключевые слова.
Плюс в его случае как класс отсутствует лексер. Так что не совсем ясно как организовать подсветку.
Нужно вводить какие-то соглашения. Например, если в грамматике встревающий строковые литералы, то расценивать их как ключевые словам и подсвечивать соответствующим образом.
ЗЫ
Вообще, поддержку IDE для двушки придется координатно пересмотреть.
В прочем, сама двушка во многом нацелена на то, чтобы избавиться от тех проблем которые сейчас присутствуют в IDE.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).
Более общий вопрос: какие фреймворки поддерживать? Вариант 2.0 и выше мне нравится больше всего, но дублирование функционального API из linq и того же System.Tuple — это не очень хорошо.
Здравствуйте, catbert, Вы писали:
C>Здравствуйте, hardcase, Вы писали:
H>>Пересесть на System.Tuple, доступный в .NET 4.0 (для .NET 2.0/3.5 написать аналог).
C>Более общий вопрос: какие фреймворки поддерживать? Вариант 2.0 и выше мне нравится больше всего, но дублирование функционального API из linq и того же System.Tuple — это не очень хорошо.
Думаю .NET 4.0 или даже 5.0 . К тому времени все что меньше 4.0 будет не актуально.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В 2.0 планируется реализовать новую систему синтаксических макросов (макросов расширяющих синтаксис языка).
VD>Это потребует переработки всей системы парсинга.
Будет ли это значить, что макросы можно объявлять и использовать в одной и той же единице компиляции? Как я понимаю, авторы немерле планировали реализовать эту фичу.
VD>Минусы: VD>1. В макросах нельзя будет производить побочных эффектов, так как правила описываемые макросами могут вызываться при парсинге ветвей грамматики которые в последствии будут отброшены как не верные. VD>2. Пока не ясно (и это следует обсудить) как в такой схеме воспроизвести синтаксис базируемый на отступах. Как вариант, можно просто от него отказаться. Возможно, что данную проблему получится решить самими же макросами (введя альтернативные макросы для парсинга последовательностей и элементов верхнего уровня. Хорошо бы, чтобы кто-то продумал это.
Если парсер поддерживате наследуемые атрибуты, можно просто передавать желаемую ширину отступа в дочернее правило, а там будет предикат, определяющий равенство количества отступов заданному. Вроде ничего сложного. Но лично мне не нравится такой синтаксис, и хотелось бы иметь возможность конвертировать из одного в другой. VD>3. Парсер построенный в лоб на базе PEG неминуемо будет более медленным и прожорливым по сравнению с ручным. Это потребует потратить не мало времени на оптимизацию. Нужно реализовать генерацию ДКА для терминальных правил (разбирающих символы строки). VD>4. Весь код файла придется грузить в память перед парсингом (это требование алгоритма связанного с парсингом PEG-а). На сегодня это вряд ли будет проблемой. Если только на мобильных девайсах, где немерл и так не работает. VD>5. Придется парсить весь файл целиком, без предварительной токенизации и шага препарс (где на сегодня производится свертка токенов в группы). Это так же накладывает дополнительные требования на скорость парсинга (т.е. на оптимизацию PEG-а). Это же не позволит парсить части фалов (как это сейчас делает интеграция), но оно и правильно, так как это неминуемо ведет к проблемам в работе интеграции.
Что в таком случае будет с диагностикой ошибок? Ведь макросы дадут возможность менять не только синтаксис, используя ограниченный набор типов лексем, но и вводить лексические конструкции (к примеры новый вид комментариев).
Почему бы все таки не оставить лексер, который будет выделять пробелы, слова (ключевые слова, идентификаторы и тд), операторы, строки и комментарии?
Такие неограниченный возможности изменения синтаксиса могут привести к тому, что
— парсер будет дико медленно работать
— язык будет превращаться в брейнфак
— реализация диагностики ошибок и предложенных оптимизаций(генераций ДКА) будет чрезвычайно сложна в реализации, что в итоге сделает такой автоматический парсер гораздо сложнее написанного вручную
В итоге, я думаю в любом случае необходимо наложить некоторые ограничения на изменение синтаксиса.
VD>6. Грамматика используемая в макросах не должна быть лево-рекурсивной (так как это не поддерживается реализацией PEG-а) и должна будет подчиняться некоторым правилам разработанным для нашего PEG-парсера. Например, в операторах приоритетного выбора (... / ...) обязаны использоваться только имена правил (макросов) причем типы возвращаемых значений этих правил обязаны совпадать (или иметь общий базовый тип совпадающий с типом правила содержащего оператор приоритетного выбора). VD>7. Невозможно будет предсказать, что два подправила в операторе приоритетного выбора не конфликтуют. Правило стоящее первым будет всегда оказываться "победителем". Если правило разобралось, то для других даже не будет производиться попытка разбора. Возможно, имеет смысл кроме оператора приоритетного выбора PEG-а "/" ввести стандартный оператор перечисления равноценных правил "|" из BNF с тем, чтобы программисты могли явно выражать, что отдельные правила (макросы) не должны пересекаться и тем самым заставлять компилятор проверять это условие. Однако прочерка может оказаться трудной в реализации, так как для выявления эквивалентности правил придется строить для них конечный автомат (что приближает нас к ANTLR 3, и является весьма сложным занятием... особенно для динамически расширяемого парсера).
Считается, что это невозможно. И несмотря на то, что в некоторых случаях возмножно определить неоднозначность правил, это приведет к усложнению парсера, и как следствие, к тормозам VD>8. В макросах придется явно указывать пробельные символы. PEG позволяет обходиться без лексера, что координатно повышает гибкость и модульность парсера, но за это надо платить.
Это очень неудобно. Должно быть соглашение о том, где добавлять пробелы в дочернем правиле или родительском, иначе неосторожное написание макросов приведет к тому, что от количества пробелов будет зависеть применится ли макрос или нет.
Здравствуйте, Aleх, Вы писали:
A>Будет ли это значить, что макросы можно объявлять и использовать в одной и той же единице компиляции?
Краткий ответ — нет. Но тут не все так просто.
Макросы нельзя будет использовать внутри кода, то есть их нельзя будет раскрыть. Но внутри описания синтаксиса других макросов их можно будет использовать.
То есть, можно будет сделать вот так (см. выделенное):
macro class Xml
{
macro tagOpen(lt, _, id, attrs, gt, _) : XmlAst.TagOpen
syntax: '<' s identifier attr* '>' s
{
TagOpen(lt.StartPos, gt.EndPos, id.Value, attrs.Map(x => x.Value :> Attr))
}
macroattr(id, _, _, value) : XmlAst
syntax: identifier '=' s attrValue;
{
Attr(id.Value.StartPos, value.Value.EndPos, id.Value, value.Value)
}
}
А так, нельзя:
macro class Xml
{
macro tagOpen(lt, _, id, attrs, gt, _) : XmlAst.TagOpen
syntax: '<' s identifier attr* '>' s
{
<[ ... $attr ... ]>
}
macroattr(id, _, _, value) : XmlAst
syntax: identifier '=' s attrValue;
{
Attr(id.Value.StartPos, value.Value.EndPos, id.Value, value.Value)
}
}
A>Как я понимаю, авторы немерле планировали реализовать эту фичу.
Не особо. Была расплывчатая фраза вроде "Это остается предметом будущих исследований.". И то эта фраза была в какой-то институтской работе.
VD>>2. Пока не ясно (и это следует обсудить) как в такой схеме воспроизвести синтаксис базируемый на отступах. Как вариант, можно просто от него отказаться. Возможно, что данную проблему получится решить самими же макросами (введя альтернативные макросы для парсинга последовательностей и элементов верхнего уровня. Хорошо бы, чтобы кто-то продумал это. A>Если парсер поддерживате наследуемые атрибуты, можно просто передавать желаемую ширину отступа в дочернее правило, а там будет предикат, определяющий равенство количества отступов заданному. Вроде ничего сложного. Но лично мне не нравится такой синтаксис, и хотелось бы иметь возможность конвертировать из одного в другой.
Парсера как такового, как я уже говорил, не будет. Макросы могут передавать что угодно, но как-то не хочется нагружать не относящиеся к отступам макросы дополнительной работой.
В текущей реализации парсера обработка отступом сделана весьма элегантно, как дополнительный шаг трансляции. Синтаксис с отступами переводится в синтаксис со скобками. Сделать там нам уже вряд ли удастся. Но отступы можно попытаться контролировать в самом парсере или в специально введенном для этого макросе (отлавливающем конец строки и идущие за ним пробельные символы).
VD>>5. Придется парсить весь файл целиком, без предварительной токенизации и шага препарс (где на сегодня производится свертка токенов в группы). Это так же накладывает дополнительные требования на скорость парсинга (т.е. на оптимизацию PEG-а). Это же не позволит парсить части фалов (как это сейчас делает интеграция), но оно и правильно, так как это неминуемо ведет к проблемам в работе интеграции.
A>Что в таком случае будет с диагностикой ошибок?
Отсутствие токенезации не должно влиять на обработку ошибок. Но на нее будет влиять тот факт, что новый парсер будет поддерживать парсинг с откатами.
Выявить место ошибки при этом так же будет можно если вести в процессе парсинга выявлять макросы/правила которые не разобралось при самом большой позиции. Однако кроме того еще нужно будет обеспечить стратегию восстановления после ошибки. Для этого нужно будет или вводить специализированный механизм отсечения (о котором я как-то говорил в Философии), или создавать специализированные макросы отлавливающие ошибочную ситуацию, выдающие сообщение о ошибке и пропускающие входной поток до момента с которого можно продолжить парсинг в штатном режиме. Скажу честно, что тут еще нужно произвести некоторые исследования, но в целом задача выглядит вполне понятной и реализуемой.
A>Ведь макросы дадут возможность менять не только синтаксис, используя ограниченный набор типов лексем, но и вводить лексические конструкции (к примеры новый вид комментариев).
Да, это так. Но чем это может помешать обработке ошибок?
A>Почему бы все таки не оставить лексер, который будет выделять пробелы, слова (ключевые слова, идентификаторы и тд), операторы, строки и комментарии?
Потому что это ограничит возможность встраивания нового синтаксиса в язык. В озвученном варианте синтаксис может меняться практически без ограничений. В плоть до того, что с помощью некоторой прагмы можно будет разбирать синтаксис Паскаля или C#-а.
В принципе введение лексера как минимум сняло необходимость введения оптимизаций парсинга терминальных правил), но при этом оно ничего не дало бы в вопросе обработки ошибок и ограничило бы возможности расширения синтаксиса.
A>Такие неограниченный возможности изменения синтаксиса могут привести к тому, что
Не понял. Что и где ограничено?
A>- парсер будет дико медленно работать
Практика показывает, что даже в текущем (не сильно оптимизированном виде) парсер на базе PEG работает с приемлемой скоростью. Если учесть, что нами планируется ввести ряд оптимизаций (построение ДКА для терминальных правил, точки отсечения и мемоизация результатов некоторых правил), то можно смело предположить, что скорость будет приемлемой. Причем приемлемой не только для компилятора, но и для работы в рамках интеграции.
A>- язык будет превращаться в брейнфак
Вот это точно не соответствует действительности. Наличие мощной системы макросов позволяющей менять синтаксис почти как угодно не означает, что язык (точнее его стандартная библиотека макросов) будет превращена в помойку.
Конечно кто-то нерадивый может превратить в помойку свой код, но это его проблемы. За чистотой стандартной библиотеки будет следить все сообщество.
A>- реализация диагностики ошибок и предложенных оптимизаций(генераций ДКА) будет чрезвычайно сложна в реализации, что в итоге сделает такой автоматический парсер гораздо сложнее написанного вручную
Про диагностику ошибок я уже говорил. Не вижу тут особых проблем.
Реализация же оптимизаций — это конечно сложная задача (потому она до сих пор и не сделана), но вполне подъёмная. Главное, что эту работу нужно будет проделать ровно один раз. После этого можно будет пользоваться декларативно описываемыми макросами которые по определению будут намного проще вручную написанного кода парсинга. Так что это опасение вообще не ясно из чего исходит.
A>В итоге, я думаю в любом случае необходимо наложить некоторые ограничения на изменение синтаксиса.
Зачем?
В прочем, некоторые ограничения конечно же будут. Так расширять синтаксис можно будет только в точках расширения специально предусмотренных теми кто будет писать стандартные макросы компилятора (т.е. грамматику языка).
Пока что планируется введение точек расширений на следующих уровнях:
1. На уровне файлов (скорее всего с помощью прагм). Это позволит вводить собственные языки. Возможно, что синтаксис базируемый на отступах будет сделать именно макросом такого типа.
2. На уровне пространств имен (для введения собственных конструкций верхнего уровня). Например, собственных типов).
3. На уровне префиксов и суффиксов типов. Например, чтобы можно было организовать синтаксис вида:
class A
invariant x == 10
{
...
4. На уровне содержимого типов. Для введения своих членов типов.
5. На уровне префиксов и суффиксов стандартных членов типов.
6. На уровне выражений (в телах членов).
7. На уровне макро-атрибутов.
8. Будет так же предусмотрен специальный синтаксис для введения унарных и бинарных операторов.
Точки расширений можно будет так же вставлять и в самодельные макросы. Это будет стандартный механизм расширения. Общая идея точек расширения заключается в том, что в некоторые списки приоритетного выбора можно будет добавить специальное правило подразумевающее, что на его место в рантайме могут подставляться те или иные макросы. Точка расширения должно будет описывать тип который обязан возвращать макрос который желает быть примененным в данной точке расширения. Таким образом если мы хотим позволить расширять синтаксис членов типов, то в макрос описывающий список доступных типов мы должны будем добавить точку расширения:
member(member) : ClassMember
syntax: method / property / field / type;
expansible: instead, besides // позволяет вставить новые правила вперед списка или в его конец
{
member
}
VD>>7. Невозможно будет предсказать, что два подправила в операторе приоритетного выбора не конфликтуют. Правило стоящее первым будет всегда оказываться "победителем". Если правило разобралось, то для других даже не будет производиться попытка разбора. Возможно, имеет смысл кроме оператора приоритетного выбора PEG-а "/" ввести стандартный оператор перечисления равноценных правил "|" из BNF с тем, чтобы программисты могли явно выражать, что отдельные правила (макросы) не должны пересекаться и тем самым заставлять компилятор проверять это условие. Однако прочерка может оказаться трудной в реализации, так как для выявления эквивалентности правил придется строить для них конечный автомат (что приближает нас к ANTLR 3, и является весьма сложным занятием... особенно для динамически расширяемого парсера). A>Считается, что это невозможно.
Можно разрешить выбор по ИЛИ в том случае когда компилятор в силах построить ДКА для всех вариантов перечисления и доказать тем самым, что правила не конфликтуют. Скажем совершенно не ясно зачем по очереди пытаться спарсить декларацию всех видов типов когда с помощью построения ДКА можно сразу перейти к разбору конеретного вида.
В рочем, согласен что это может оказаться весьма не простым занятием, так что это дело можно отложить на необозримый срок.
A>И несмотря на то, что в некоторых случаях возмножно определить неоднозначность правил, это приведет к усложнению парсера, и как следствие, к тормозам
Ну, к тормозам это точно привести не может, так как данные вычисления должны будут производиться не на стадии работы макросов, а на стадии их компиляции. Правда любые предвычисления связаны кроме всего с отказом от расширяемости. Так оператор ИЛИ не будет позволять встроить точку расширения. Но можно будет ведь создать правила таким образом:
standardMember(member) : ClassMember
syntax: method | property | field | type;
{
member
}
member(member) : ClassMember
syntax: standardMember;
expansible: instead, besides // позволяет вставить новые правила вперед списка или в его конец
{
member
}
Тогда компилятор сможет проверить непротиворечивость правил в standardMember и построить для него эффективный код, а member будет обеспечивать расширяемость.
Кстати, еще одной проблемой которую надо решить — это пеоритетность макросов. Ведь два расширения могут конфликтовать между собой и от того в какой последовательности они будут расположены в операторе приоритетного выбора будет зависеть то какой из макросов будет реально применен. Посему нужно так же продумать синтаксис позволяющий указать, что какой-то макрос более приоритетный чем другой (известный на момент компиляции первого).
VD>>8. В макросах придется явно указывать пробельные символы. PEG позволяет обходиться без лексера, что координатно повышает гибкость и модульность парсера, но за это надо платить. A>Это очень неудобно. Должно быть соглашение о том, где добавлять пробелы в дочернем правиле или родительском, иначе неосторожное написание макросов приведет к тому, что от количества пробелов будет зависеть применится ли макрос или нет.
Тут, к сожалению, имеет место противоречие между удобством и возможностями. Наличие возможности прямой манипуляции пробельными символами расширяет возможности синтаксического расширения макросов. Но с другой стороны — согласен — указывать пробельные правила удобно не всегда.
Возможно имеет смысл ввести два типа макросов. В одном можно будет манипулировать пробельными символами явно, а в другом компилятор будет не явно подставлять правило "s" после каждой грамматической конструкции. Например, вот как это может выглядеть.
Вариант без учета пробельных символов:
В первом варианте подразумевается, что "autospace: true", что означает, что после каждого элемента грамматики не явно вставляется правило "s".
Кстати, вставка правила "s" более одного раза подряд не приведет к проблемам, так как правило не обязательное. Ну, и компилятор сможет устранять лишние "s", так что можно смело лепить их "на всякий пожарный".
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Кроме того планируется ввести декларативное описание зависимостей между макросами. Пример (гипотетический) синтаксиса:
[MacroUsage(MacroPhase.BeforeTypedMembers, MacroTargets.Class)]
macro AbstractFactory(tb : TypeBuilder, params classes : list [PExpr])
depends on: Record
{
Это объявление означает, что макрос AbstractFactory зависит от результатов работы макроса Record, и что сначала должны будут раскрыться макросы Record, а затем уже AbstractFactory.
Конечно это касается только макросов работающих на одной и той же стадии компиляции.
Рекурсивные зависимости не допустимы. Зависимости от макросов не работающих на данной стадии так же недопустимы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Во второй версии так же нужно вынести процесс генерации MSIL-а в отдельную стадию.
Сейчас генерация кода методов производится сразу после окончания типизации их тел. Эмит структур данных должен происходить до того как они используются при генерации кода методов. Это создает серьезные проблемы. Так это препятствует генерации полей класса или модуля из макросов уровня выражений. Это происходит потому, что SRE-структуры генерируются после вызова метода TypwBuilder.Compile(), но после его вызова в класс уже невозможно добавить новые элементы.
Вынесение генерации MSIL-а в отдельную стадию позволит избежать проблем подобных описанным выше, а так же сделает код более чистым и менее связанным.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Вынести процесс генерации MSIL-а в отдельную стадию
Здравствуйте, VladD2, Вы писали:
VD>Сейчас генерация кода методов производится сразу после окончания типизации их тел. Эмит структур данных должен происходить до того как они используются при генерации кода методов. Это создает серьезные проблемы. Так это препятствует генерации полей класса или модуля из макросов уровня выражений. Это происходит потому, что SRE-структуры генерируются после вызова метода TypwBuilder.Compile(), но после его вызова в класс уже невозможно добавить новые элементы.
. К тому времени все что меньше 4.0 будет не актуально.
