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


CU>>>C# здесь более гигиеничен,

VD>>Что? Этого высказывания я вообще не понял. В шарпе нет макросов.

CU>Здесь я имел в виду, что он более просто создает имена, информация строки из экспрешена исходного кода в коде IL метода сборки может отпугнуть.

Все равно не понял. Причем тут IL?

CU>Вообщем там просто, если объявление создано не с помощью цитаты, то оно просто генерируется по имени как есть, если с помощью цитаты, то имена скрытого поля и методов add remove, создаются по умолчанию то есть типа event_field_of и add_ remove_,

Ну, имена типа add_ и remove_ еще как-то можно считать паттерном отсутствующего имени. Но event_field_of чем не имя то? И как это имя модифицировать. Ведь компилятор и понятия не имеет о том, что поле и событие как-то связаны.

CU>при этом выражение обязательно должно пройти через метод DefineWithReturn TypeBuilder, объявление квазицитатой события, как я понимаю не имеет смысла без вышеназванного метода, где можно его перехватить и правильно обработать, как это делается со свойствами,

Дык события могут быть внутри класс. Например:

<[
  class A
  {
    public event $(var1 : usesite) : X;
    public event $(var2 : usesite) : Y;
    public event $(var3 : usesite) : Z;
  }
]>

и как их разбирать? Не универсальное какое-то решение.

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

Можно конечно и так. Но тогда нужно в корне менять большую часть логики компилятора. Меж тем Splicable.Expression как раз и задумывался для динамического формирования имен. Так почему бы его и не использовать?

CU> Если событие может создаться в обход метода DefineWithReturn то можно создавать add и remove в конструкторе ClassMember.Event, наверное самый гибкий вариант.

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

CU>Ладно еще этот вопрос исследую и тогда можно будет более точно сказать как лучше устроить.

ОК

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


H>По поводу dyn. Если в том коде использовать usesite, то компилятор будет для полученного имени будет формировать контекст, который не будет совпадать с контекстом, где будут объявлены аргументы value (сам я сути не вкурил, это домыслы — см. дизассемблерный листинг).

Может быть там имеет смысл использовать не dyn, а глобал? Ну, и соответственно его же использовать для объявления value.

H>Я считаю, что в данном случае dyn использовать безопасно (хоть и не шибко красиво), так как он фигурирует не внутри алгоритмического кода, но лишь для объявлений.

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

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

VD>Может быть там имеет смысл использовать не dyn, а глобал? Ну, и соответственно его же использовать для объявления value.

Я не очень хорошо осознаю их физический смысл.
value изготавливается как MkSplicableName, и сериализуется в виде:

new Splicable.Name(Name.NameInCurrentColor("value", _N_MacroContexts.Get(1, ManagerClass.Instance)))

Если global дает такой же эффект (контексты), то, похоже, его и нужно использовать.

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

H>Я не очень хорошо осознаю их физический смысл.
H>value изготавливается как MkSplicableName, и сериализуется в виде:
H>

H>new Splicable.Name(Name.NameInCurrentColor("value", _N_MacroContexts.Get(1, ManagerClass.Instance)))
H>

H>Если global дает такой же эффект (контексты), то, похоже, его и нужно использовать.

NameInCurrentColor — это значит в текущем цвете. В парсере он видимо должен быть равен глобальному цвету (1). А вот в макросах он будет уникальным (случайным).

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

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

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

VD>Меня лично устроил бы вариант форматирования только на основании токенов.

VD>Но можно конечно и смотреть есть ли информация от парсера и типизатора и если есть, то выполнять расширенное форматирование, а если нет, то по токенам.


VD>>>Я плохо понял смысл предложения. Уж больно оно большое. Можно все тоже самое изложить проще?
CU>>Я нашел такой эффект, сделал функцию которая создает итератор через слово yield, и он отказался его форматировать, хотя код простой, посмотрел поглубже оказалось что заместо всего блока с yield получается какой то мудреный код сгенерированный компилятором,

VD>Это код конечного автомата. Но ты можешь пользоваться исходным кодом метода доступным чере свойство ClassMember.Function.ParsedBody.

VD>Собственно только его и нужно анализировать. Код из ClassMember.Body может быть изменен макросами до неузнаваемости.

CU>> форматирование сгенерированных объявлений (те которых нет в исходнике) я убрал, весь блок пропускается, и участок остается без форматирования, здесь я понял что нужно форматировать тогда по токенам с помощью информации лексера, которая одна только может дать понятие что хранится в документе, тогда наверное правильно было бы сделать так что если объявление сгенерировано, то произвести его специальный анализ и форматирование с помощью информации лексера, а не пропускать, тогда форматирование должно быть корректным.

VD>Ну, я уже сказал, что если пользоваться ClassMember.Function.ParsedBody, а не ClassMember.Body, то такой проблемы быть не должно, но у меня есть одни вопрос.
VD>А какие проблемы возникают если форматировать только по токенам (т.е. без анализа кода вообще?). Ну, по крайней мере когда речь идет о коде методов?

CU>>По поводу того чтобы сначала парсить есть еще проблема, у меня на ноутбуке проект компилятора очень долго сканируется Intellisense, невыносимо и жутко жрет процессор, если запускать форматирование с принудительным парсингом то это может занять продолжительное время, Intellisense производит полную компиляцию при анализе или только парсинг, может сделать какой то облегченный вариант сканирования, чтобы быстрее сканировалось с минимумом нужной информации модулю форматирования? C# Intellisense вообще летает.

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

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

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

CU>По поводу проблем форматирования по токенам хочется сказать, что сейчас сделано на основе информации парсера,

Я, конечно, в этом коде плохо разбираюсь, но когда я его смотре, то там был вызов лексера как раз для получения реальных токенов.

Парсер некоторые токены выбрасывает. Так что могут быть проблемы даже если присутствует информация от парсера.

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

Дык это самое нужное (отступы по скобкам).

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

Такой облегченный парсер и так запускается (на каждое изменение, но в отложенном режиме). У любого ISource можно получить текущий CompileUnit через одноименное свойство.

Но, еще раз повторюсь, в этом дереве не вся информация о токенах. К сожалению, даже в дереве токенов не вся информация имеется. Например, комментарии, еще при построении дерева токенов выбрасываются (помещаются в отдельный список).

CU>Есть ли такой парсер который только сканирует файл и дает информацию дерева по нему?

См. выше. В общем, более детально все это дело проще было бы осбудить голосом (Скайп, МСН, телефон (если ты Москвич)).

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

CU>>поэтому придется наверное много переделать, еще хочется заметить что если производить форматирование по токенам, то информации лексера явно недостаточно для полного форматирования, может быть получится только отступы по скобкам и еще что то независимое от контекста,
VD>Дык это самое нужное (отступы по скобкам).

Я паралельно с поддержкой веб дизайнера, сделал smart indentation, залью в репозиторий сразу после коммита кода, связанного с дизайнером. Набивать код станет немного легче.

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

VD>Такой облегченный парсер и так запускается (на каждое изменение, но в отложенном режиме). У любого ISource можно получить текущий CompileUnit через одноименное свойство.

По моему в CompileUnit, полученном этим способом, отсутствует информация о позициях (

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

S>По моему в CompileUnit, полученном этим способом, отсутствует информация о позициях (

Нет, нет. Она там конечно же есть! Собственно там использцется тот же самый парсер. Просто используется он локально и в дальнейшем не производится типизации полученного АСТ. А так он точно такой же.

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

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


CU>>>>C# здесь более гигиеничен,

VD>>>Что? Этого высказывания я вообще не понял. В шарпе нет макросов.

CU>>Здесь я имел в виду, что он более просто создает имена, информация строки из экспрешена исходного кода в коде IL метода сборки может отпугнуть.

VD>Все равно не понял. Причем тут IL?

CU>>Вообщем там просто, если объявление создано не с помощью цитаты, то оно просто генерируется по имени как есть, если с помощью цитаты, то имена скрытого поля и методов add remove, создаются по умолчанию то есть типа event_field_of и add_ remove_,

VD>Ну, имена типа add_ и remove_ еще как-то можно считать паттерном отсутствующего имени. Но event_field_of чем не имя то? И как это имя модифицировать. Ведь компилятор и понятия не имеет о том, что поле и событие как-то связаны.

CU>>при этом выражение обязательно должно пройти через метод DefineWithReturn TypeBuilder, объявление квазицитатой события, как я понимаю не имеет смысла без вышеназванного метода, где можно его перехватить и правильно обработать, как это делается со свойствами,

VD>Дык события могут быть внутри класс. Например:
VD>

VD><[
VD>  class A
VD>  {
VD>    public event $(var1 : usesite) : X;
VD>    public event $(var2 : usesite) : Y;
VD>    public event $(var3 : usesite) : Z;
VD>  }
VD>]>
VD>

VD>и как их разбирать? Не универсальное какое-то решение.

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

VD>Можно конечно и так. Но тогда нужно в корне менять большую часть логики компилятора. Меж тем Splicable.Expression как раз и задумывался для динамического формирования имен. Так почему бы его и не использовать?

CU>> Если событие может создаться в обход метода DefineWithReturn то можно создавать add и remove в конструкторе ClassMember.Event, наверное самый гибкий вариант.

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

CU>>Ладно еще этот вопрос исследую и тогда можно будет более точно сказать как лучше устроить.

VD>ОК

Вообщем вопрос исследовал, пока все работает хорошо, проблем не возникает, пробовал разные варианты объявления событий, пока фантазии хватило на объявление с помощью вызова методов и разных сплайс строк, если кто то может более изощренно сделать проверку правильно ли формируются имена методов, то хорошо. Про il код, мне показалось что метод ToString() переведет в строку все выражение, и оно останется в il, тут извиняюсь был неправ, это мое невежество в квази-цитатах и сплайс выражениях. Так что работает хорошо, молодцы! Может быть стоит такие же изменения с именами аксессоров свойств, которые делаются пустыми для сложных экспрешенов и потом добавляются в методе Define?

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

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


CU>>>>C# здесь более гигиеничен,

VD>>>Что? Этого высказывания я вообще не понял. В шарпе нет макросов.

CU>>Здесь я имел в виду, что он более просто создает имена, информация строки из экспрешена исходного кода в коде IL метода сборки может отпугнуть.

VD>Все равно не понял. Причем тут IL?

CU>>Вообщем там просто, если объявление создано не с помощью цитаты, то оно просто генерируется по имени как есть, если с помощью цитаты, то имена скрытого поля и методов add remove, создаются по умолчанию то есть типа event_field_of и add_ remove_,

VD>Ну, имена типа add_ и remove_ еще как-то можно считать паттерном отсутствующего имени. Но event_field_of чем не имя то? И как это имя модифицировать. Ведь компилятор и понятия не имеет о том, что поле и событие как-то связаны.

CU>>при этом выражение обязательно должно пройти через метод DefineWithReturn TypeBuilder, объявление квазицитатой события, как я понимаю не имеет смысла без вышеназванного метода, где можно его перехватить и правильно обработать, как это делается со свойствами,

VD>Дык события могут быть внутри класс. Например:
VD>

VD><[
VD> class A
VD> {
VD> public event $(var1 : usesite) : X;
VD> public event $(var2 : usesite) : Y;
VD> public event $(var3 : usesite) : Z;
VD> }
VD>]>
VD>


VD>и как их разбирать? Не универсальное какое-то решение.

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

VD>Можно конечно и так. Но тогда нужно в корне менять большую часть логики компилятора. Меж тем Splicable.Expression как раз и задумывался для динамического формирования имен. Так почему бы его и не использовать?

CU>> Если событие может создаться в обход метода DefineWithReturn то можно создавать add и remove в конструкторе ClassMember.Event, наверное самый гибкий вариант.

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

CU>>Ладно еще этот вопрос исследую и тогда можно будет более точно сказать как лучше устроить.

VD>ОК

Предыдущий пост мой.
Вообщем вопрос исследовал, пока все работает хорошо, проблем не возникает, пробовал разные варианты объявления событий, пока фантазии хватило на объявление с помощью вызова методов и разных сплайс строк, если кто то может более изощренно сделать проверку правильно ли формируются имена методов, то хорошо. Про il код, мне показалось что метод ToString() переведет в строку все выражение, и оно останется в il, тут извиняюсь был неправ, это мое невежество в квази-цитатах и сплайс выражениях. Так что работает хорошо, молодцы! Может быть стоит такие же изменения с именами аксессоров свойств, которые делаются пустыми для сложных экспрешенов и потом добавляются в методе Define?

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

А>Может быть стоит такие же изменения с именами аксессоров свойств, которые делаются пустыми для сложных экспрешенов и потом добавляются в методе Define?

Да, наверное надо.