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

_C_>Когда тестирую макрос в проекте из использующего экзешника и проекта макроса, при правильно выставленных зависимостях для
_C_>макробиблиотеки, каким-то образом при билде используется старая версия макросов, даже несмотря на ребилд макро-библиотеки (!).
_C_>Я добавлял референс двойным кликом через список в вкладке Проекты в Macro References. при переносе ссылки в References ошибка ушла.

Это известная проблема. Отлаживаемые макросы нужно подключать как обычный References. К сожалению, Macro References не отслеживает зависимостей.

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


_C_>>>

_C_>>>public registration(typeBuilder :TypeBuilder, fld : ClassMember.Field, control :bool) : void
_C_>>>        def name_field_loaded = Macros.UseSiteSymbol(fld.name.ToString() + "_loaded")                                      
_C_>>>        def x = <[decl: mutable $(name_field_loaded : name) : bool ]>
_C_>>>        typeBuilder.Define (x)
_C_>>>

_C_>>>name_field_loaded содержит то, что задумано — x_loaded, color == 1
_C_>>>fld.name имеет color == 1 но не меняется в итоговом коде.

VD>>С виду все нормально. Ну, кроме того, что все можно делать несколько проще:
VD>>

VD>>public registration(typeBuilder :TypeBuilder, fld : ClassMember.Field, control :bool) : void
VD>>        def name_field_loaded = $"$(fld.name)_loaded"
VD>>        def x = <[decl: mutable $(name_field_loaded : usesite) : bool ]>
VD>>        typeBuilder.Define(x)
VD>>

_C_>да это работает. а то что я написал — нет и ни за что. спасибо!

Твой код полностью аналогичен. Похоже ты запостил немного не то, что использовал.

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

VD>>Если твой код вызывается из макро-атрибута, то ничего меняться не должно.
_C_>мамой клянусь меняет.

Покажи полный код. Что-то у тебя явно не так. Или ты нашел какой-то хитрый баг.

VD>>Как универсальное средство наплевать на гигиену можно вместо usesite или name указывать dyn, т.е.
VD>>

VD>><[ decl: mutable $("some_name" : dyn) : bool ]>
VD>>

_C_>очень мудреное с этими decl-ами , dyn-aми, .. чувствую что-то курили..

Ничего особо мудреного. Если не было бы гигиены имен пришлось бы для каждого имени в макросе городить генерацию имен (или ошибки были бы там и тут). А так все имена в макросах автоматически переименовываются, а если хочешь чтобы этого не происходило, то используй usesite, global или dyn со строкой. "dyn" это полное нарушение гигиены. Будет сформировано имя которое совпадет даже с переименованным именем созданным в другом макросе. Потому dyn опаснее, но при этом и самый мощный способ забить на гигиену.

VD>Кстати, ты используешь бэту или релиз для 3.5-го фрэймворка?
я использую октябрьскую бету для 2010 студии

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

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


_C_>>>>

_C_>>>>public registration(typeBuilder :TypeBuilder, fld : ClassMember.Field, control :bool) : void
_C_>>>>        def name_field_loaded = Macros.UseSiteSymbol(fld.name.ToString() + "_loaded")                                      
_C_>>>>        def x = <[decl: mutable $(name_field_loaded : name) : bool ]>
_C_>>>>        typeBuilder.Define (x)
_C_>>>>

_C_>>>>name_field_loaded содержит то, что задумано — x_loaded, color == 1
_C_>>>>fld.name имеет color == 1 но не меняется в итоговом коде.

VD>>>С виду все нормально. Ну, кроме того, что все можно делать несколько проще:
VD>>>

VD>>>public registration(typeBuilder :TypeBuilder, fld : ClassMember.Field, control :bool) : void
VD>>>        def name_field_loaded = $"$(fld.name)_loaded"
VD>>>        def x = <[decl: mutable $(name_field_loaded : usesite) : bool ]>
VD>>>        typeBuilder.Define(x)
VD>>>

_C_>>да это работает. а то что я написал — нет и ни за что. спасибо!

VD>Твой код полностью аналогичен. Похоже ты запостил немного не то, что использовал.

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

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

Это. Цитируй, плиз, то что нружно, а не все подряд.

_C_>была же проблема с обновлением.

Скорее всего.

_C_>но твой вариант заработал

Это понятно. Он даже удобнее. Просто то что ты привел технически ничем не отличается. "usesite" вставляет очень похожий код. Потому я тебе и говорю, что дело не в этом коде.

нужно поля описание превратить в свойство.
из

class x
   [VAL] i : int

получить

class x:
   public i : int
      get
          ...
      set
          ...

для простейшего случая пишу

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Field)]\
  macro VAL(typeBuilder : TypeBuilder, fld : ClassMember.Field)          
    
    def type_ex = if (fld.ty.ToString() == "bool")    "bool" else "int"
    
    Implementation.registration(typeBuilder, fld, type_ex, true)            
    //простой обмен с полями структуры для чтения-записи
    
    <[decl:  public $(fld.name) : $(fld.ty) {     
              get {                                                 
                  _exchange.$(fld.name)    
                }
              set    {                                                                      
                  _exchange.$(fld.name) = value
                }
            }
         ]>

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

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

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

Ты хочешь заменить декларацию поля в свойство? Но это невозможно, можно добавить что то, удалить или заменить старое неудастся. Лучше либо сразу создавать нужные свойства из полей например макроаттрибутом [Accessor] на поле, либо помечать их в макросах и тогда они раскроются в свойства но с заглавной буквы, можно создать свойство но с другим именем. Здесь имена пересекаются и компилятор видимо игнорирует второе объявление.

CU>Ты хочешь заменить декларацию поля в свойство? Но это невозможно, можно добавить что то, удалить или заменить старое неудастся. Лучше либо сразу создавать нужные свойства из полей например макроаттрибутом [Accessor] на поле, либо помечать их в макросах и тогда они раскроются в свойства но с заглавной буквы, можно создать свойство но с другим именем. Здесь имена пересекаются и компилятор видимо игнорирует второе объявление.

Понятно. тогда как удалить поле? если написать вот так:

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Field)]\
  macro VAL(typeBuilder : TypeBuilder, fld : ClassMember.Field)          
    
    def type_ex = if (fld.ty.ToString() == "bool")    "bool" else "int"
    
    Implementation.registration(typeBuilder, fld, type_ex, true)            
    //простой обмен с полями структуры для чтения-записи
    
    def prop = 
      <[decl:  public $(fld.name) : $(fld.ty) {     
              get {                                                 
                  _exchange.$(fld.name)    
                }
              set    {                                                                      
                  _exchange.$(fld.name) = value
                }
            }
         ]>
     
    prop.SetEnv(fld.Env)            
    typeBuilder.Define(prop)

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

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

_C_>Понятно. тогда как удалить поле? если написать вот так:

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

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

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

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

_C_>Понятно. тогда как удалить поле? если написать вот так:...
_C_>тогда компилятор говорит о конфликте имен. должна быть возможность удаления.

Никак. Удалять ничего нельзя. Можно только менять и добавлять.

В твоем случае есть два разумных выхода из положения:
1. Объявлять авто-свойства, а уже далее генерировать им содержимое (в следствии чего они перестанут быть "авто") и создавать поля и т.п.
2. Описать синтаксическое расширение. Для этого нужно описать макрос уровня метода (это важно) в котором описать свой синтаксис. При этом синтаксис не должен конфликтовать с правилами немерла.

Я бы выбрал первый вариант. Причем сразу по двум причинам:
1. Он меньше всего будет удивлять пользователей, так как по факту свойство и объявляется.
2. При этом будет работать интеллисенс. Стало быть ползователи смогут выбрать тип свойства по человечески.

Но если тебе очень хочется именно синтаксис поля, то используй второй способ.

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

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

Что имеешь в виду под "применение обычного макроса внутри декларации макроса"? Если ты хочешь написать так:

ty.Define(<[decl: [Accessor] field : int; ]>);

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

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

_C_>она бы конечно и не нужна, будь в Nemerle возможность применения обычного макроса внутри декларации класса.

"Обычный" нельзя, если под этим иметь в виду макрос уровня выражения. Но можно применять обычный макрос верхнего уровня. В том числе и вводящий синтаксическое расширение. Я уже раза 3 это говорил, но мои слова игнорируются. Единственная хитрость — для введения синтаксического расширения надо создавать макрос уровня метода. Еще раз даю ссылку на пример такого макроса.

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

VD>"Обычный" нельзя, если под этим иметь в виду макрос уровня выражения. Но можно применять обычный макрос верхнего уровня. В том числе и вводящий синтаксическое расширение. Я уже раза 3 это говорил, но мои слова игнорируются. Единственная хитрость — для введения синтаксического расширения надо создавать макрос уровня метода. Еще раз даю ссылку на пример такого макроса.

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

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

да это получается вообще невозможно сделать как задумано и описано в http://www.rsdn.ru/forum/nemerle/4512432.1.aspx

Автор: _Claus_
Дата: 25.11.11

. ну, переживу. на фронте и не такое видал.

VD>2. Описать синтаксическое расширение. Для этого нужно описать макрос уровня метода (это важно) в котором описать свой синтаксис. При этом синтаксис не должен конфликтовать с правилами немерла.

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

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

_C_>да это получается вообще невозможно сделать как задумано и описано в http://www.rsdn.ru/forum/nemerle/4512432.1.aspx

Автор: _Claus_
Дата: 25.11.11

. ну, переживу. на фронте и не такое видал.

Ладно, повторять одно и то же в 10 раз я не намерен. Убедил себя черт знает в чем, ну и ладно. Раз меня не слушают, я ничем помочь не могу.

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

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

Если бы ты внимательнее слушал, что тебе говорят, то понял бы раньше. Я же пример раза три давал. Не меньше.

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

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

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

VD>Если бы ты внимательнее слушал, что тебе говорят, то понял бы раньше. Я же пример раза три давал. Не меньше.

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

описал макрос:

[Nemerle.MacroUsage(Nemerle.MacroPhase.BeforeInheritance, Nemerle.MacroTargets.Method)]\
  macro VAL(typeBuilder : TypeBuilder, method_builder : ParsedMethod, tok_name : Token, tok_type : Token)\
  syntax("VAL", tok_name, ":", tok_type)      
    
    def type_ex = if (tok_type.ToString() == "bool")    "bool" else "int"
    
    def (_, name_fld, name_type) = Implementation.registration(typeBuilder, tok_name, tok_type, type_ex, true)            
    //простой обмен с полями структуры для чтения-записи    
    def prop = 
      <[decl:  public $(name_fld : dyn) : $(name_type : dyn) {     
              get {                                                 
                  _exchange.$(name_fld  : dyn)    
                }
              set    {                                                                      
                  _exchange.$(name_fld : dyn) = value
                }
            }
         ]>
      
    //prop.SetEnv(tok_name.Env)            
        
    typeBuilder.Define(prop)

пытаюсь использовать в коде

class x 
  VAL a : int

до макроса вызов не доходит:

parse error near identifier `a': expecting `=', `;' or `{' in field / property declaration
..

и ; в конце не помогает. что не так?