Здравствуйте, vdimas, Вы писали:
V>Вопрос можно? Автор этой ветки высказал весьма полезную идею, но она явно полезна только для сред с автокомплитом и рефакторингом.
V>А сможет ли будущий рефакторинг для Nemerle отличить параметры макроса как элемента программы от параметров макроса как строковых идентификаторов или имен других вложенных макросов? Не получится ли там аналогичная С++ проблема с рефакторингом?
Хороший вопрос, присоединяюсь.

У рефакторера (как интеллисенсера), претендующего на универсальность, не будет другого выбора, кроме как исполнять код макросов, для того чтобы определять,
какое AST, они порождают.
Но тут нужна будет ещё нехилая дедукционная(?) логика, для определения того в какое место в результирующем AST попадут параметры макроса (если попадут вообще), и как они будут преобразованы.
С тривиальными макросами типа for — всё понятно. Они не модифицируют фрагменты выражений передаваемых в качестве параметров. А что если модифицируют, или на создают фрагменты AST с нуля, на основе них?

По этой причине, например, мне не нравиться макрос Accessor, которий разрешается использовать в форме:

[Accessor] mutable my_value : int;

В результате это создаётся имя MyValue, не присутствующее в исходниках, что как минимум, уменьшает их читабельность.
Интеллисенсу, впрочем, это не помешает (он тупо может выполнить макрос — и будет знать все имена). Но вот рефактореру, решающему задачу переименования имени MyValue в YourValue, в контексте использования свойства, можно только посочуствовать.

Уж лучше, как по мне, либо явно заставлять обязательно писать имя свойства в Accessor или хотя бы без параметров применять его в форме

[Property] mutable Y : int;

в котором бы генерилась property Y, теневой storage для неё со скрытым именем, публичный геттер и, например, приватный сеттер;

В любом случае, создание универсальных инструментов рефакторинга/интеллисенса для Nemerle — задача не для слабонервных.

xhalt wrote:
> Но тут нужна будет ещё нехилая дедукционная(?) логика, для определения
> того в какое место в результирующем AST попадут параметры макроса (если
> попадут вообще), и как они будут преобразованы.
Ха! А это невозможно в принципе.

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

X>С тривиальными макросами типа for — всё понятно. Они не модифицируют фрагменты выражений передаваемых в качестве параметров. А что если модифицируют, или на создают фрагменты AST с нуля, на основе них?

Ну модифицировать-то они не могут, ибо состояние PExpr read-only. А создать с нуля могут — но почему бы и нет? Мы всё равно получить это сможем, как получаем значения пропертей в дебаге (утрирую).

X>По этой причине, например, мне не нравиться макрос Accessor, которий разрешается использовать в форме:

X>[Accessor] mutable my_value : int;

X>В результате это создаётся имя MyValue, не присутствующее в исходниках, что как минимум, уменьшает их читабельность.

Не уменьшает, если ты знаешь, как этот макрос работает. Другое дело — как сообщить конечному пользователю макроса, как тот работает и что будет результатом его выполнения? Т.е. получить-то это можно (впрочем, об этом ты уже написал) — надо только подумать, как вывести.

X>Интеллисенсу, впрочем, это не помешает (он тупо может выполнить макрос — и будет знать все имена). Но вот рефактореру, решающему задачу переименования имени MyValue в YourValue, в контексте использования свойства, можно только посочуствовать.

Почему? Он не может поменять MyValue на YourValue, потому что, как ты правильно заметил, MyValue ещё нет в коде.

X>Уж лучше, как по мне, либо явно заставлять обязательно писать имя свойства в Accessor или хотя бы без параметров применять его в форме

X>[Property] mutable Y : int;

X>в котором бы генерилась property Y, теневой storage для неё со скрытым именем, публичный геттер и, например, приватный сеттер;

Ну дык напиши такой макрос Имхо иногда полезно знать и имя поля (иногда нет, конечно).

X>В любом случае, создание универсальных инструментов рефакторинга/интеллисенса для Nemerle — задача не для слабонервных.

Компилятор они как-то написали. Выведение типов тоже неплохо работает. Посмотрим

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

>> Но тут нужна будет ещё нехилая дедукционная(?) логика, для определения того в какое место в результирующем AST попадут параметры макроса (если попадут вообще), и как они будут преобразованы.
C>Ха! А это невозможно в принципе.
Уточни плиз, "невозможно в принципе" — это ко всему абзацу относится или только к последнему словосочетанию?

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

X>>С тривиальными макросами типа for — всё понятно. Они не модифицируют фрагменты выражений передаваемых в качестве параметров. А что если модифицируют, или на создают фрагменты AST с нуля, на основе них?
O>Ну модифицировать-то они не могут, ибо состояние PExpr read-only.
Имелось в виду модифицировать, путём создания нового экземпляра (клонирования),
или расщепление match'ем на два под-деревья и использование в разных контекстах.

X>>Интеллисенсу, впрочем, это не помешает (он тупо может выполнить макрос — и будет знать все имена). Но вот рефактореру, решающему задачу переименования имени MyValue в YourValue, в контексте использования свойства, можно только посочуствовать.
O>Почему? Он не может поменять MyValue на YourValue, потому что, как ты правильно заметил, MyValue ещё нет в коде.
Ты, кажется, не совсем понял о чём я.
Приведу полный фрагнмент кода:

using Nemerle.Utility;

public class X 
{
    [Accessor]  mutable my_value : double = 0;
}

def z = X().MyValue + 1;
System.Console.WriteLine(z);

Здесь мне не нравиться вот что:
1. Макрос Accessor употреблённый в таком вот виде нарушает принцип "наименьшего удивления".
Иными словами, он не интуитивно понятный.
2. Рефакторер не в состоянии справиться с задачай переименования MyValue на YourValue, в контексте использования свойства (мышой кликнули на MyValue -> Refactor -> Rename...)
Откуда имя взялось он-то найдёт (так же как интеллисенсер). А вот переименовать...

Заметь, если бы написали [Accessor(MyValue)] (или в моём вариенте [Property]) — то можно было бы установить однозначную связь с исходным и результирующим AST и всё бы было OK. И сюрпризов для непосвящённых нету (и откуда, блин, взялось это имя MyValue ?!).

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

X>И сюрпризов для непосвящённых нету (и откуда, блин, взялось это имя MyValue ?!).
а кстати откуда оно взялось?

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

Чувствую, слаб я в этом вопросе. Могу только сказать, что, видимо, рефакторинг для Nemerle будет выглядеть не так же, как для C# потому как макрос это black box и нету каких-то общих правил зависимости выхода от входа для всех макросов (что ты, собственно, и сказал). А вводить их значит ограничивать макросы. В общем, поживём — увидим.

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

X>У рефакторера (как интеллисенсера), претендующего на универсальность, не будет другого выбора, кроме как исполнять код макросов, для того чтобы определять,
X>какое AST, они порождают.

Для рефактринга не нужно знать что за АСТ пораждают макросы. Рефакторинг оперирует на исходном АСТ. Максимум что нужно — это построение конечного АСТ с целью вычесления дерева типов. Но это не проблема.

X>Но тут нужна будет ещё нехилая дедукционная(?) логика, для определения того в какое место в результирующем AST попадут параметры макроса (если попадут вообще), и как они будут преобразованы.

Зачем?

X>С тривиальными макросами типа for — всё понятно. Они не модифицируют фрагменты выражений передаваемых в качестве параметров. А что если модифицируют, или на создают фрагменты AST с нуля, на основе них?

Рефакторить то что пораждается невозможно в приципе. Тут уже нужно рефакторить "модель", т.е. АСТ которым оперируют макросы, а это и есть исходное АСТ, или тело самих макросов. Но тела макросов — это штатный код, то есть опять же исходное АСТ.

X>По этой причине, например, мне не нравиться макрос Accessor, которий разрешается использовать в форме:
X>

X>[Accessor] mutable my_value : int;
X>

X>В результате это создаётся имя MyValue, не присутствующее в исходниках, что как минимум, уменьшает их читабельность.

Хм. Думаю, ты не прав. Ты когда нибудь создавал типизированные датасеты? Ну, или пользовался другими кодогенераторами на базе custom tool (или генераторов ASP.NET)?

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

Мета-атрибуты генерирующие код просто позволяют тебе кратко записать некоторый паттерн проектирования. При этом код этого описания остается кратким. Это только повышает читабельность.

Да, конечно, ты обязан будешь знать и понимать соглашение вводимое этим мета-атрибутом. Но это куда проще, чем пытаться угадать паттерн в нагромождении кода.

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

X>Интеллисенсу, впрочем, это не помешает (он тупо может выполнить макрос — и будет знать все имена). Но вот рефактореру, решающему задачу переименования имени MyValue в YourValue, в контексте использования свойства, можно только посочуствовать.

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

А если удастся декларативно связать логику макроса с логикой формирования имен, то возмоно будет доступен и более умный рефакторинг.

X>В любом случае, создание универсальных инструментов рефакторинга/интеллисенса для Nemerle — задача не для слабонервных.

+1

Но рефакторинг и интелисенс вообще задачи сложные.

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

X>1. Макрос Accessor употреблённый в таком вот виде нарушает принцип "наименьшего удивления".

+1

X>Иными словами, он не интуитивно понятный.

Вот тут не сказал бы. Я как-то сразу въеъал и проблем не испытываю с пониманием.

X>2. Рефакторер не в состоянии справиться с задачай переименования MyValue на YourValue, в контексте использования свойства (мышой кликнули на MyValue -> Refactor -> Rename...)

Можно так. Сначала меняшь имя переменной. Интелисенст "чувствует", что в коде появилась ошибочная ссылка вида:

любоеДопустимоеВыражениеТипКоторогоСовпадаетСКлассомВКоторомБылоОбъявленоMyValue.MyValue.

Далее кликашь правой кнопкой по "MyValue" и выбирашь "заменить неверное имя на...". Рефакторер составляет список вхождений и махает MyValue на YourValue.

X>Заметь, если бы написали [Accessor(MyValue)]

Ничего ровным счетом не изменится. Рефакторер не поймет ассоциации между параметром атрибута и именем свойства. Чтобы он это понял прийдется захардкодить знание о поведение атрибута Accessor. А это кривое решение.

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

O>Чувствую, слаб я в этом вопросе. Могу только сказать, что, видимо, рефакторинг для Nemerle будет выглядеть не так же, как для C# потому как макрос это black box и нету каких-то общих правил зависимости выхода от входа для всех макросов (что ты, собственно, и сказал). А вводить их значит ограничивать макросы.
Есть ещё интересный путь:
Написал макрос, который не поддерживается рефакторером (т.е который выполняет несопоставимое автоматом преобразование) — напиши соответствующий модуль расширения рефакторера.
Например в той же сборке что и макрос, с пометкой специальным атрибутом.
Особенно может быть актуальным для макросов, которые внедряют в язык специфический DSL.

Как вывод — инструмент рефакторинга должен быть расширяемым.

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

X>>Заметь, если бы написали [Accessor(MyValue)]...

VD>Ничего ровным счетом не изменится. Рефакторер не поймет ассоциации между параметром атрибута и именем свойства. Чтобы он это понял прийдется захардкодить знание о поведение атрибута Accessor. А это кривое решение.
Зачем хардкодить?
Выполнив код этого макроса (в рефакторере) можно установить однозначное соответствие межлу входным AST <[MyValue]> и всеми вхождениями этого фрагмента в результирующий AST.
А значит можно решить задачу и переименования MyValue (найденного в результирующем AST) в результате которого будет фактически переименовано имя в параметре макроса.

Я не уверен на 100%, что это можно сделать в текущей реализации компилятора (объектной модели AST) и данного конкретного макроса Accessor, но в принципе, это не есть архисложной технической проблемой.

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

X>>С тривиальными макросами типа for — всё понятно. Они не модифицируют фрагменты выражений передаваемых в качестве параметров. А что если модифицируют, или на создают фрагменты AST с нуля, на основе них?

VD>Рефакторить то что пораждается невозможно в приципе.
Я как раз пытаюсь, показать что в Nemerle это возможно, но не в общем случае.

И это возможнно, как раз в тех (частных) случаях, в которых удаётся установить однозначное соответсвие между фгаментами AST переданных макросу и их вхождениями в результирующем AST.
Для этого не обязательно знать что внутри макроса.
Можно, например, передать макросу AST с метками на узлах а потом найти их в результирующем. Может и без меток можно обойтись, ограничившись Object.ReferenceEquals()

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

X>>>С тривиальными макросами типа for — всё понятно. Они не модифицируют фрагменты выражений передаваемых в качестве параметров. А что если модифицируют, или на создают фрагменты AST с нуля, на основе них?

VD>>Рефакторить то что пораждается невозможно в приципе.
В догонку... В буквальном смысле конечно невозможно.
Но можно создать видимость пользователю, что выполняется как-бы рефакторинг порождённого AST,
хотя на самом деле в результате будут автоматически измененяться параметры макроса, таким образом чтобы пользователь получил то порождённое AST, которое хотел.

К примеру, если бы я написал макрос MyMacro, который бы как-то по особому переписывал декларацию класса.

MyMacro(
  class A
    {
       //...
    }
)

и использовал порождённый класс таким образом

A a = A();

То переименование порождённого имени A в точке использования может оказаться вполне разрешимым (приводить к изменению имени A в параметре макроса)

xhalt,

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

>>> Но тут нужна будет ещё нехилая дедукционная(?) логика, для определения того в какое место в результирующем AST попадут параметры макроса (если попадут вообще), и как они будут преобразованы.
C>>Ха! А это невозможно в принципе.
X>Уточни плиз, "невозможно в принципе" — это ко всему абзацу относится или только к последнему словосочетанию?

Теорема Райса (неразрешимость проблемы распознавания свойств функций по задающим их программам), я правильно понимаю?

Lazy Cjow Rhrr wrote:
> C>>Ха! А это невозможно в принципе.
> X>Уточни плиз, "невозможно в принципе" — это ко всему абзацу относится
> или только к последнему словосочетанию?
> Теорема Райса (неразрешимость проблемы распознавания свойств функций по
> задающим их программам), я правильно понимаю?
Можно к банальному halting problem свести — у нас ведь в макросах
Nemerle может использоваться вся мощность С#.

Кстати, формально программы на С++ можно абсолютно точно рефакторить —
макросы C не являются Turing-complete языком. Хотя на практике задача
реверсирования макросов часто может быть слишком вычислительно сложной.

Cyberax,

>> Теорема Райса (неразрешимость проблемы распознавания свойств функций по
>> задающим их программам), я правильно понимаю?
C>Можно к банальному halting problem свести — у нас ведь в макросах
C>Nemerle может использоваться вся мощность С#.

Да, понятно.

C>Кстати, формально программы на С++ можно абсолютно точно рефакторить —
C>макросы C не являются Turing-complete языком. Хотя на практике задача
C>реверсирования макросов часто может быть слишком вычислительно сложной.

И это тоже

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

X>>Интеллисенсу, впрочем, это не помешает (он тупо может выполнить макрос — и будет знать все имена). Но вот рефактореру, решающему задачу переименования имени MyValue в YourValue, в контексте использования свойства, можно только посочуствовать.

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

VD>А если удастся декларативно связать логику макроса с логикой формирования имен, то возмоно будет доступен и более умный рефакторинг.

А ведь действительно. Насколько я понимаю, вся шумиха как раз таки из-за банального ренэйма поля/свойства/метода, для остальных задач рефакторинга макросы проблем не добавляют.
Мы пытаемся найти "язык будущего", а я не представляю себе такой язык без хорошего рефакторинга. А если язык становиться достаточно сложным для рефакторинга, то есть 3 пути:
1. Язык отправляется на помойку.
2. Языком пользуемся, рефакторим только то, что позволено автоматически отрефакторить, и материмся когда приходится что-то отрефакторить в ручную, но право быть "языком будущего" пропадает.
3. В язык вводятся конструкции для рефакторинга. Это должны быть не просто конкретный набор атрибутов для конкретного средства рефакторинга, а добавленные в спецификацию конструкции. В таком случае при описании макроса Accessor мы должны явно указать порождаемые сущности и что делать в случае их переименования:

[Nemerle.Refactoring.Generate(GeneratedEntity.Property),
 Nemerle.Refactoring.Action(RefactoringAction.Rename, ...)]
macro Accessor (...)
{
    ...

Однако, тут возникает вопрос, а как заставить разработчика макроса задекларировать порождаемые сущности? Хотя с другой стороны, можно и не заставлять, но тогда для части кода рефакторинг будет не возможен, что тоже достаточно неприятно.

Здравствуйте, ie, Вы писали:
ie>Однако, тут возникает вопрос, а как заставить разработчика макроса задекларировать порождаемые сущности? Хотя с другой стороны, можно и не заставлять, но тогда для части кода рефакторинг будет не возможен, что тоже достаточно неприятно.
По-моему, проблема несколько преувеличена. Вот есть такой пример: resx-файлы в 2005 студии. Так вот, по ним генерится соответствующий ресурсный файл. Что характерно, когда я переименовываю в resx — редакторе какой-то ресурс, студия корректно детектирует переименование мембера автогенеренного класса и проводит соответствующий рефакторинг. Не знаю, насколько распространено подобное удобство, и не является ли это явной "заплаткой", захардкоденной в студию для конкретного действия.

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

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

А там уже видно будет. Даже это уже позволит эффективно использовать этот язык.

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

ie>>Однако, тут возникает вопрос, а как заставить разработчика макроса задекларировать порождаемые сущности? Хотя с другой стороны, можно и не заставлять, но тогда для части кода рефакторинг будет не возможен, что тоже достаточно неприятно.
S>По-моему, проблема несколько преувеличена. Вот есть такой пример: resx-файлы в 2005 студии. Так вот, по ним генерится соответствующий ресурсный файл. Что характерно, когда я переименовываю в resx — редакторе какой-то ресурс, студия корректно детектирует переименование мембера автогенеренного класса и проводит соответствующий рефакторинг. Не знаю, насколько распространено подобное удобство, и не является ли это явной "заплаткой", захардкоденной в студию для конкретного действия.

Не берусь судить, но ИМХО это как раз таки является заплаткой.

S>К чему это я? А к тому, что ключ к успеху — ровно в том, чтобы правильно трэкать изменения в генеренном коде.

Этот ход пройдет, если рефакторинг идет от макроса к применению результатов работы этого макроса, а вот наоборот, вряд ли. Как узнает рефакторер, что для того, что бы поменять имя свойства, которое я "вот тут" использую, требуется изменить имя парамерта у макроса?

S>Неважно, чем он генерится — макросом или кастом тулом. Это значительно более перспективный путь, чем пытаться накормить рефакторинг.

Возможно, но пока мне таких путей не видится.

Здравствуйте, ie, Вы писали:
ie>Этот ход пройдет, если рефакторинг идет от макроса к применению результатов работы этого макроса, а вот наоборот, вряд ли. Как узнает рефакторер, что для того, что бы поменять имя свойства, которое я "вот тут" использую, требуется изменить имя парамерта у макроса?
А-а... Ну, в общем случае, это, имхо, неразрешимая задача. Просто далеко не все макросы позволят вообще отследить, что откуда взялось. Поэтому изобретать такую сложную систему, имхо, не имеет особого смысла — все равно пользоваться ей удастся только в экзотических случаях.

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

S>А-а... Ну, в общем случае, это, имхо, неразрешимая задача. Просто далеко не все макросы позволят вообще отследить, что откуда взялось. Поэтому изобретать такую сложную систему, имхо, не имеет особого смысла — все равно пользоваться ей удастся только в экзотических случаях.
Про неразрешимость в _общем_ случае уже неоднократно сказали. Есть предложение ограничиться конкретными случаями, и даже больше уделить внимание интеллисенсу (как более необходимому и более простому в реализации).
Но даже для того чтобы сделать корректный интеллисенс в теле цикла макроса for
есть варианты:
1. Научить инструмент распознавать и обрабатывать конкретный макрос for
2. Сделать более-менее универсальный механизм, который будет справляться с подобными макросами
3. Предусмотреть возможность расширения инструмента, если поведения по умолчанию не достаточно.
(можно, впрочем, и совмещать)

Самое сложное из — этого п.2.
В чём сложность даже для тупого автокомплита? Нужно знать в какой контекст попадёт тот фрагмент AST который мы "интеллисенсим".... Кто сказал, допустим, что в теле некого myfor, будут доступны локальные переменные? А вдруг макрос отдельный метод класса генерирует и туда тело помещает?
К слову, for и генерирует функцию, правда локальную.
Т.е. тут снова та же залача — определить в какой контекст попадают переданные аргументами куски AST.
Имхо, в частных случаях (for и прочие макросы не перекраивающие свои параметры), это вполне разрешимо, путём выполнения макроса и анализа результата.