Re[2]: проблема с обновлением макро-библиотеки - Nemerle

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

CU>Честно говоря не знаю истории появления этого синтаксиса, кажется это идет от экспериментов польских ребят в области создания макросистемы. Эти сокращения нигде и не объявлены, если поискать текст в исходниках компилятора, то работа с ними находится в hierarchy\MacroClassGen.n где производится генерация класса макроса и подобие лифтинга его параметров, где он и обрабатывается. Я давно уже забил на такого рода объявления, и все пишу обычными типами ClassMember или PExpr.

Имхо, надо объявить этот синтаксис deprecated и вычистить исходники.

В параметрах макроса есть тип ParsedField

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Field)]\
  macro Ref(typeBuilder : TypeBuilder, fld : ParsedField)
  
    registration(typeBuilder, fld, true)

когда я пытаюсь определить метод registration, компилятор в упор не знает ParsedField (все на Parsed..), что удивляет меня безмерно.
еще удивило, когда в исходниках компилятора я нахожу к нему отсылки, но не объявление.

 module Helpers

    public registration(typeBuilder :TypeBuilder, fld : ParsedField, control :bool) : void //ошибка unbound type name ParsedField
    
      mutable block = typeBuilder.UserData["data"] :> TypeBuilder
      ..

Добавление:
Nemerle, Nemerle.Compiler в Reference-ах имеются
в заголовке файла тоже все как по библии

using Nemerle;
using Nemerle.Collections
using Nemerle.Compiler
using Nemerle.Text
using Nemerle.Utility
using Nemerle.Compiler.Parsetree
using Nemerle.Compiler.Typedtree

using System;
using System.Collections.Generic;
using System.Linq;

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

_C_>В параметрах макроса есть тип ParsedField

_C_>

_C_>[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Field)]\
_C_>  macro Ref(typeBuilder : TypeBuilder, fld : ParsedField)
  
_C_>    registration(typeBuilder, fld, true)

_C_>

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

Это фокус компилятора при парсинге макросов, он может знать эти сокращения и подставляет на их место соответствующие им типы АСТ, в макросах это возможно но в хелпер методах нет, такого типа не существует. Можно задавать типы явно например ClassMember.Field который является аналогом ParsedField.

CU>Это фокус компилятора при парсинге макросов, он может знать эти сокращения и подставляет на их место соответствующие им типы АСТ, в макросах это возможно но в хелпер методах нет, такого типа не существует. Можно задавать типы явно например ClassMember.Field который является аналогом ParsedField.
Это я понял из анализа других исходников, но как и где объявлены эти сокращения и почему они не работают вне контекста макроса — загадка.
и какой смысл в этой мистике? почему тупо не объявить ClassMember.Field вместо ParsedField? это ж кипятит мозк при попытке найти хвосты..

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

_C_>Это я понял из анализа других исходников, но как и где объявлены эти сокращения и почему они не работают вне контекста макроса — загадка.
_C_>и какой смысл в этой мистике? почему тупо не объявить ClassMember.Field вместо ParsedField? это ж кипятит мозк при попытке найти хвосты..

Честно говоря не знаю истории появления этого синтаксиса, кажется это идет от экспериментов польских ребят в области создания макросистемы. Эти сокращения нигде и не объявлены, если поискать текст в исходниках компилятора, то работа с ними находится в hierarchy\MacroClassGen.n где производится генерация класса макроса и подобие лифтинга его параметров, где он и обрабатывается. Я давно уже забил на такого рода объявления, и все пишу обычными типами ClassMember или PExpr.

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

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

_C_>>Это я понял из анализа других исходников, но как и где объявлены эти сокращения и почему они не работают вне контекста макроса — загадка.
_C_>>и какой смысл в этой мистике? почему тупо не объявить ClassMember.Field вместо ParsedField? это ж кипятит мозк при попытке найти хвосты..

CU>Честно говоря не знаю истории появления этого синтаксиса, кажется это идет от экспериментов польских ребят в области создания макросистемы. Эти сокращения нигде и не объявлены, если поискать текст в исходниках компилятора, то работа с ними находится в hierarchy\MacroClassGen.n где производится генерация класса макроса и подобие лифтинга его параметров, где он и обрабатывается. Я давно уже забил на такого рода объявления, и все пишу обычными типами ClassMember или PExpr.

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

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

CU>>Это фокус компилятора при парсинге макросов, он может знать эти сокращения и подставляет на их место соответствующие им типы АСТ, в макросах это возможно но в хелпер методах нет, такого типа не существует. Можно задавать типы явно например ClassMember.Field который является аналогом ParsedField.
_C_>Это я понял из анализа других исходников, но как и где объявлены эти сокращения и почему они не работают вне контекста макроса — загадка.
_C_>и какой смысл в этой мистике? почему тупо не объявить ClassMember.Field вместо ParsedField? это ж кипятит мозк при попытке найти хвосты..

Это старая история. На самом деле — это косяк который поляки привнесли в самом начале развития языка.

Изначально типизация макросов была сделана из рук вон плохо. Там была масса хардкодинга.
Видимо, чтобы "облегчить" людям восприятие поляки решили дать "простые" имена для типов. Но вместо того чтобы завести псевдонимы (через декларацию type) они тупо захардкодили имена в типизаторе макросов и расплодили их по статьям и примерам.

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

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

CU>>Честно говоря не знаю истории появления этого синтаксиса, кажется это идет от экспериментов польских ребят в области создания макросистемы. Эти сокращения нигде и не объявлены, если поискать текст в исходниках компилятора, то работа с ними находится в hierarchy\MacroClassGen.n где производится генерация класса макроса и подобие лифтинга его параметров, где он и обрабатывается. Я давно уже забил на такого рода объявления, и все пишу обычными типами ClassMember или PExpr.

Z>Имхо, надо объявить этот синтаксис deprecated и вычистить исходники.

Его тяжело объявить деприкетед, так как там полнеший хардкод (таких типов нет). Можно вручную ворнинги кидать. Только при этом придется еще кучу мест в стандартной библиотеке править.

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

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

Их так расплодили, что теперь и не вычистишь вот так просто.

Можно создать псевдоним, чтобы эта хрень тоже типом будет.

проблема в изменении моего сгенерированного имени с обычного на _N_1_мое676.
делаю так.

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

name_field_loaded содержит то, что задумано — x_loaded, color == 1

fld.name имеет color == 1 но не меняется в итоговом коде.

что это значит и как сделать, что хочу?

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

_C_>что это значит и как сделать, что хочу?

Ты usesite имя сделал, оно и не должно меняться

_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_>

Так должно помочь:

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

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

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

_C_>>что это значит и как сделать, что хочу?

H>Ты usesite имя сделал, оно и не должно меняться

_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_>>

H>Так должно помочь:
H>

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

Ты не понял, оно меняется, а я не хочу. игры с контекстом и цветом не помогают — меняет хоть тресни. напр.
def ctx = Manager.MacroColors.UseContext;
def name_field_loaded = Name(fld.name.ToString() + "_loaded", 1, ctx)
def x = <[decl: mutable $(name_field_loaded : name) : bool ]>

меняет тоже. а какие ему цвет, контекст дать, чтобы не менял?

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

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

Офотоа: Умеешь ты сформулировать вопрос так, что понять не удается.

_C_>проблема в изменении моего сгенерированного имени с обычного на _N_1_мое676.
_C_>делаю так.

_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 но не меняется в итоговом коде.

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

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

_C_>что это значит и как сделать, что хочу?

Я не понял, что означает фраза "не меняется в итоговом коде"?

В итоге ты должен получить поле с именем "Prop2_loaded" (если имя поля было "Prop2").

В общем, объясни что ты понимаешь под "в итоговом коде" и что (по-твоему) должно меняться.

VD>Я не понял, что означает фраза "не меняется в итоговом коде"?

VD>В итоге ты должен получить поле с именем "Prop2_loaded" (если имя поля было "Prop2").

VD>В общем, объясни что ты понимаешь под "в итоговом коде" и что (по-твоему) должно меняться.

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

и код мой должен принять вид
mutable Prop2_loaded : bool

он несмотря на все мои извороты имею вот это

mutable _N_Prop2_loaded983 : bool

а я его не хочу.

VD>Офотоа: Умеешь ты сформулировать вопрос так, что понять не удается.

есть малеха.

_C_>>проблема в изменении моего сгенерированного имени с обычного на _N_1_мое676.
_C_>>делаю так.

_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>

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

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

_C_>Ты не понял, оно меняется, а я не хочу. игры с контекстом и цветом не помогают — меняет хоть тресни. напр.
_C_>def ctx = Manager.MacroColors.UseContext;
_C_>def name_field_loaded = Name(fld.name.ToString() + "_loaded", 1, ctx)
_C_>def x = <[decl: mutable $(name_field_loaded : name) : bool ]>

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

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

Возможно у тебя рядом автосвойство размещено и оно дает это имя.

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

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

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

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

_C_>>Ты не понял, оно меняется, а я не хочу. игры с контекстом и цветом не помогают — меняет хоть тресни. напр.
_C_>>def ctx = Manager.MacroColors.UseContext;
_C_>>def name_field_loaded = Name(fld.name.ToString() + "_loaded", 1, ctx)
_C_>>def x = <[decl: mutable $(name_field_loaded : name) : bool ]>

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

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

VD>Возможно у тебя рядом автосвойство размещено и оно дает это имя.
вообще не использую.

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

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

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

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

_C_>и код мой должен принять вид
_C_>mutable Prop2_loaded : bool

Покажи весь код.

Я попытался воспроизвести твой код:

Скрытый текст

using Nemerle;
using Nemerle.Collections;
using Nemerle.Compiler;
using Nemerle.Compiler.Parsetree;
using Nemerle.Compiler.Typedtree;
using Nemerle.Text;
using Nemerle.Utility;

using System;
using System.Collections.Generic;
using System.Linq;

namespace MacroLibrary
{
  [MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Property)]
  macro Ref(typeBuilder : TypeBuilder, property : ClassMember.Property)
  {
    RefImpl.DoTransform(Macros.ImplicitCTX(), typeBuilder, property)
  }
  
  module RefImpl
  {
    public DoTransform(typer : Typer, typeBuilder : TypeBuilder, property : ClassMember.Property) : void
    {
      Macros.DefineCTX(typer);
      def fieldsMap = Helpers.GetFieldsMap(typeBuilder);
      fieldsMap[property] = "REF";
      
      def name_field_loaded = Macros.UseSiteSymbol(property.name.ToString() + "_loaded");
      def x = <[decl: public mutable $(name_field_loaded : name) : bool ]>;
      typeBuilder.Define(x)
    }
  }
}

Проблем не обнаружил. Формируется поле с именем Prop2_loaded (у меня макрос на свойстве). Которое видно как в интеллисенсе (я специмально сделал его пабликом), так и ILSpy-ем.

И проверь, не используется ли у тебя старая версия. Замени Macro Reference на обычный Reference.

ЗЫ

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

Здравствуйте, _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. ну, переживу. на фронте и не такое видал.

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

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

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

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

Ладно, повторять одно и то же в 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
..

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

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

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

Лексерные (принимающие Token) макросы это перебор для твоей задачи. Твой синтаксис вписывается в синтаксис немерла. Так что достаточно сделать что-то подобное:

using Nemerle;
using Nemerle.Collections;
using Nemerle.Compiler;
using Nemerle.Compiler.Parsetree;
using Nemerle.Compiler.Typedtree;
using Nemerle.Text;
using Nemerle.Utility;

using System;
using System.Collections.Generic;
using System.Linq;


namespace MacroLibrary
{
  [MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Method)]
  macro RefSyntax(typeBuilder : TypeBuilder, _ : ClassMember.Function, expr : PExpr)
  syntax ("ref", expr)
  {
    RefSyntaxImpl.DoTransform(Macros.ImplicitCTX(), typeBuilder, expr)
  }
  
  module RefSyntaxImpl
  {
    public DoTransform(typer : Typer, _typeBuilder : TypeBuilder, expr : PExpr) : void
    {
      Macros.DefineCTX(typer);

      match (expr)
      {
        | <[ $(name : name) : $type ]> => Message.Hint(name.Location, $"ref $name : $type;");
        | _ => Message.Error(expr.Location, <#Expected: "ref" name ":" type ";"#>);
      }
    }
  }
}

Параметр (expr) один, так как парсер сам распознает все выражение.

ЗЫ

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

вот такую дичь

VAL(a) int

можно заставить работать, соотв. изменив синтаксис на

syntax("VAL", "(", tok_name,")", tok_type)

но почему

VAL a : int

не хочет? грамматика такую простую вещь должна ведь допускать.

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

_C_>вот такую дичь
_C_>VAL(a) int
_C_>можно заставить работать, соотв. изменив синтаксис на
_C_>syntax("VAL", "(", tok_name,")", tok_type)
_C_>но почему

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

...
syntax ("VAL", token)
...

Но тебе вообще не нужны эти токены. Лексерный макрос — это самый низкий уровень. Ты даже тип будешь вручную разбирать.
Рядом я тебе привел пример как сделать тоже самое без использования токенов.

	От:	Ziaw
	Дата:	24.11.11 13:20
	Оценка:	+3

	От:	_Claus_
	Дата:	24.11.11 12:29
	Оценка:

	От:	_Claus_
	Дата:	24.11.11 12:31
	Оценка:

	От:	CodingUnit
	Дата:	24.11.11 12:46
	Оценка:

	От:	_Claus_
	Дата:	24.11.11 13:00
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	24.11.11 15:42
Оценка:

От:	hardcase	http://nemerle.org
Дата:	25.11.11 07:36
Оценка: