Re[6]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.11 14:37
Оценка: +2
Здравствуйте, Ziaw, Вы писали:

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


Что-то у них совсем уродское ГУИ. Напоминает ГУЙ к древнему CVS. Почему они просто не содрали ГУЙ с Тортилы для SVN (с учетом особенностей, конечно)?
Ладно. Вопрос риторический .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Требуются примеры макросов уровня выражения создающи
От: Аноним  
Дата: 08.01.11 15:33
Оценка: -1 :)
Делегаты вообще создавались для событий то потом их уже за уши притянули к функциональному программированию.
Re[7]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 06.01.11 20:33
Оценка: 9 (1)
Здравствуйте, Ziaw, Вы писали:

Z>Вот этот этап не совсем ясен, после него, некие синтаксические макры захотят сделать что-то еще.

Синтаксические макры это макры которые текст разбирают. Те это этап номер 1.

Z>Осталось понять как записать макрос, для которого это все должно выглядеть императивно.

А может не надо императивно?

macro MyArray 
"my_array" "(" count : Expression ")"
type of count int;
type of return array[$knownType]; // Говорим что возвращаемое значение должно быть этого типа
{
  def defaultValue = GetDefaultExprForType(knownType);
  <[
    def arr = array($count);
    for (int i = 0; i < arr.Length; i++)
       arr[i] = $defaultValue;
    arr
  ]>
}


На первом этапе у нас отработает только парсер и поместит в АСТ просто разобранный код:
MyArray(IntLiteral(1))
На втором этапе отработает информация о типах.
На третьем этапе уже будет вызван сам код макроса.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Требуются примеры макросов уровня выражения создающих ти
От: catbert  
Дата: 03.01.11 19:10
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>По сему нам нужны наиболее реалистичные примеры (usecase-ы) макросов уровня выражения которым требуется порождать (менять, удалять) новые типы (члены типов).


Сразу приходит в голову макрос s:

    button.Text = s"Create New Foo"; // добавляет в класс, скажем, StringsToLocalize поле, которое нужно перевести на другой язык
Re[5]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 06.01.11 19:10
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Самое кэширование — это уже императивный подход.

Нет это реактивный подход.

VD>В компиляторе есть структуры данных которые принципиально не могут быть функциональными. Главная из них — это дерево типов. Его части могут быть "чистыми". Но само дерево одно на проект. И как не крути его придется менять. Даже если сделать самое дерево неизменяемым (порождающим новую версию), то все равно будет одна переменная в которую придется поместит новую версию дерева.

И как же в хаскеле fold то работает...

VD>К тому же хэш-таблицы при больших объемах значительно быстрее нежели деревья. Так что для поиска данных выгоднее использовать хэш-таблицы, а не деревья.

Тут не факт что все так просто.
Ибо хештаблици придется постоянно перестраивать, а деревья можно обновлять инкрементально.

VD>Ну, а к дереву типов нужен параллельный (конкурентный) доступ.

На чтение.

VD>Так что как не крути, а тут без синхронизации не обойтись.

Если будет синхронизация то можно сразу тушить свет. Работать все будет хуже чем в одном потоке.

VD>В идеале было бы вообще сделать так, чтобы IDE работала как часть компилятора. Тогда бы можно было вообще почти молниеносно стартовать при изменении тела метода. Но тут вступают в силу реалии мира. Многие макросы настолько медленны, что они по разному работают в режиме IDE и в режиме компиляции. Пример такого макроса — PegGrammar.

Это следствие отсутствия стройной концепции стоящей за макросистемой.
Сейчас все навалено в большуюю кучу в которой хрен разберешься.
Поляки делали макро систему примерно также как автор D делал D.
Решения принимались по принципу: "Ой какая фича! Давайте и ее прикрутим!"

На самом деле нам нужно вводить 3 больших этапа трансляции программы.
1)Парсинг.
Идеология этого этипа проста:
Парсер это чистая функция от текста и загруженных в проект синтаксических макросов.
Чистая означает что мы можем как угодно плющить АСТ поступивший в обработчики и все на этом.
Те никаких вызовов внешнего кода. Никакого изменения глобальных переменных итп быть не должно.

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

2)Типизация и генерация видимых пользователю типов и методов.
Не важно приватных или публичных.

3)Кодогенерация.
На этом этапе должн генерироваться тот код который пользователь никогда не увидит.
В случае с тем же PegGrammar это методы семейства __GENERATED_PEG__RULE__*__

В интеграции нам нужны только первые два этапа.

Причем идеологически правильно чтение из всех внешних источников данных делать на первом этапе.
Те если мы хотим прочитать метаданные из базы нужно представить что база это некий виртуальный исходник. Прочитать метаданные и положить их в АСТ.

А всю запись во внешние хранилища производить на третьем этапе.

На втором этапе никаких походов за приделы компилятора быть не должно.

Детали я еще подумаю но каркас компилятора должен быть именно таким.
Иначе у нас не будет шансов сделать понятную систему.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.11 07:07
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

Z>>Осталось понять как записать макрос, для которого это все должно выглядеть императивно.

WH>А может не надо императивно?

WH>
WH>macro MyArray 
WH>"my_array" "(" count : Expression ")"
WH>type of count int;
WH>type of return array[$knownType]; // Говорим что возвращаемое значение должно быть этого типа
WH>{
WH>  def defaultValue = GetDefaultExprForType(knownType);
WH>  <[
WH>    def arr = array($count);
WH>    for (int i = 0; i < arr.Length; i++)
WH>       arr[i] = $defaultValue;
WH>    arr
WH>  ]>
WH>}
WH>


WH>На первом этапе у нас отработает только парсер и поместит в АСТ просто разобранный код:

WH>MyArray(IntLiteral(1))
WH>На втором этапе отработает информация о типах.
WH>На третьем этапе уже будет вызван сам код макроса.

Это какие-то фантазии имеющие мало общего с реальностью и мало понятные. Что такое "type of count int" я так и не понял. Какой-то ОКамл.

В подобных случаях все будет очень просто. Нужно просто применять не один, а два макроса. Один синтаксический, другой обычный. Код будет примерно таким:

macro MyArray 
syntax: "my_array" "(" count : PExpr ")"
{
  <[
    def arr = array($count);

    for (int i = 0; i < arr.Length; i++)
      InitByDefaultValues(arr[i]);
    arr
  ]>
}

macro MakeAssignmentMacro(expr : PExpr)
{
  def typedExpr = typer.TypeExpr(expr);
  def ty = typedExpr.Type.Hint;

  if (ty.HasValue)
    if (ty.Value.Equqlas(typer.StandatrTypes.Int32))
      <[ $typedExpr = 42; ]>
    else if (ty.Value.Equqlas(typer.StandatrTypes.String))
      <[ $typedExpr = "42"; ]>
    else
      PExpr.Error(expr.Location, $"The my_array macro supprt only int and string type, but expression has $(ty.Value) type.")
  else
    null // сообщаем тайперу, что мы пока неготовы раскрыть макрос
}


Скажу больше. Это совершенно надуманный пример, так как для конструкции my_array(3) нет смысла вводить новый синтаксис, так что можно было бы спокойно обойтись обычным макросом.
Более того тут даже макрос был не нужен. Тип для деволтного значения и так не трудно получить. Например, воспользовавшись mutable-переменной не имеющей инициализиатора. Можно даже дженерик-функцию написать:
def my_array[T](count : int)
{
  def arr = array($count);

  for (int i = 0; i < arr.Length; i++)
    arr[i] = default(T);
  arr
}


Если говорить о текущей реализации макросов, то и тут это спокойно реализуется.

ЗЫ

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

Это четко демонстрирует, что все разговоры о концепциях очень быстро разбиваются о реальность, если их не подкреплять скрупулезным (детальным) планом реализации.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 07.01.11 13:08
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Это какие-то фантазии имеющие мало общего с реальностью и мало понятные. Что такое "type of count int" я так и не понял. Какой-то ОКамл.

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

VD>В подобных случаях все будет очень просто. Нужно просто применять не один, а два макроса. Один синтаксический, другой обычный. Код будет примерно таким:

Блин. Ты сравни колличество кода.
А вот эту магию вообще никто не поймет.
  def typedExpr = typer.TypeExpr(expr);
  def ty = typedExpr.Type.Hint;

  if (ty.HasValue)

Что тут происходит? Императив какойто.
При том что мой вариант декларативный.

VD>Скажу больше. Это совершенно надуманный пример, так как для конструкции my_array(3) нет смысла вводить новый синтаксис, так что можно было бы спокойно обойтись обычным макросом.

Это вообще к делу не относится.
Все что изменится это то что вместо пользовательского правила отработает стандартное.

VD>Короче, пример надуманный. Так как типы в нем не порождаются, то и проблем он вызвать не может.

VD>Но даже на таком простом примере ты уже на фантазировал черти чего.
Это ты наговнокодил черт знает чего.
Весь твой императив никто никогда не поймет.
Если ты думаешь что мой вариант не ясен то это не так. Ziaw все понял.

VD>Это четко демонстрирует, что все разговоры о концепциях очень быстро разбиваются о реальность, если их не подкреплять скрупулезным (детальным) планом реализации.

Нет.
Это четко демонстрирует что прежде чем спорить нужно понять о чем вообще разговор.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Требуются примеры макросов уровня выражения создающи
От: WolfHound  
Дата: 07.01.11 16:31
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Ага. Фантазии на вольную тему с жутким синтаксисом.

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

VD>Дык не с чем сравнивать. Фантазии против реального кода.

N2 одни сплошные фантазии.

VD>Фантазии у тебя там написаны, а не варинт. Ничего общего с реальностью. Это не только не взлетит, но еще и не нужно никому.

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

VD>Что он мог понять? Ты сам то не понял что написал . Изобрел какой-то ОКамл без малейшей нужды.

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

VD>Да понял я все. Ты спустись от фантазий к реалиям. И поймешь, что все сильно сложнее.

Все сложно по тому что нет строгой системы.
Мелкософты при создании .НЕТ пользовались твоими принципами и получили делегаты, войд и еще кучу всякого бреда на ровном месте.
Иногда нужно остановиться и подуцмать о том как сделать лучше, а не чутка добавить сахору к тому что уже есть.
Ибо если продолжить в томже духе то N2 будет отличатся от N1 примерно также шарп от жабы. А ведь можно сделать намного лучше.
Но для этого тебе надо перестать орать и подумать о том что предлагают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Требуются примеры макросов уровня выражения создающих типы
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.11 19:02
Оценка:
Всем привет!

Мы тут продумываем новую стратегию компиляции. Главной ее особенностью будет параллелизм компиляции тел методов (и вообще, любой макрос может быть запущен параллельно другим. Таким образом мы хотим ввести неизменяемое АСТ которое можно будет только порождать и хотим сделать так чтобы макросы не могли бесконтрольно менять дерево типов и сами типы.

Как идея сейчас рассматривается полностью изолированное создание новых типов / членов и последующее их объединение (мэрдж).

По сему нам нужны наиболее реалистичные примеры (usecase-ы) макросов уровня выражения которым требуется порождать (менять, удалять) новые типы (члены типов).

Кроме того предлагаются любые идеи в области распараллеливания работы макросов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Требуются примеры макросов уровня выражения создающих ти
От: catbert  
Дата: 03.01.11 19:14
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>По сему нам нужны наиболее реалистичные примеры (usecase-ы) макросов уровня выражения которым требуется порождать (менять, удалять) новые типы (члены типов).


Макрос Object Expression создает анонимный класс, который реализует заданный интерфейс.
Re[2]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.11 19:28
Оценка:
Здравствуйте, catbert, Вы писали:

C>Сразу приходит в голову макрос s:


C>
C>    button.Text = s"Create New Foo"; // добавляет в класс, скажем, StringsToLocalize поле, которое нужно перевести на другой язык
C>


Тип (StringsToLocalize) содержащий поля можно создать и заранее. Поля получаются локальными для каждого макроса. Стало быть мы можем как бы создавать их локально в каждом макросе (чтобы другие об этих полях не знали). Главное чтобы чтобы имена полей были уникальны.

Тогда остаются вопросы:
1. Как сделать ссылку на локально созданное поле?
2. Как и когда добавить эти новые поля? Ведь когда-то нужно еще сформировать их инициализацию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.11 19:32
Оценка:
Здравствуйте, catbert, Вы писали:

C>Макрос Object Expression создает анонимный класс, который реализует заданный интерфейс.


Здесь, видимо, лучше всего подойдет идея интеллектуального слияния типов. Типы с одинаковой структурой и именем можно считать одним и тем же типом. Так что компилятору будет достаточно выкинуть дубликаты и заменить ссылки на них на ссылки на первый экземпляр.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Требуются примеры макросов уровня выражения создающих
От: hardcase Пират http://nemerle.org
Дата: 03.01.11 19:48
Оценка:
Здравствуйте, VladD2, Вы писали:

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


Анонимные классы?
using Nemerle.Extensions;


def x = new ( a = 10, b = "foo" );
/* иЗвиНите зА неРовнЫй поЧерК */
Re[3]: Требуются примеры макросов уровня выражения создающих
От: catbert  
Дата: 03.01.11 19:55
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Тогда остаются вопросы:

VD>1. Как сделать ссылку на локально созданное поле?

Ссылка создается макросом прямо вместо выражения. То есть вместо s"blah" подставляется __GeneratedClassName.string5356

VD>2. Как и когда добавить эти новые поля? Ведь когда-то нужно еще сформировать их инициализацию.


Поля добавляются в класс, сгенерированный до этого макросом уровня сборки, а код их инициализации в это же время — в конструктор сгенерированного класса:

    class __GeneratedClassName
    {
        public string5356 : string; // добавляем поле сюда


        public this()
        {
            ...
            string5356 = ReadValueFromLanguageFile("string5356");
        }
    }


Конечно можно поля не создавать, а использовать хеш-таблицу. Но все равно нужно собрать где-нибудь воедино объединенную информацию про все строки, которые нужно локализовать.
То есть обобщенный юзкейс таков: собрать изо всех вызовов макроса-выражения какую-то информацию (в данном случае ключ для таблицы переводов), и на ее основе сгенерировать тип (в данном случае класс, который загружает переведенные строки из файла).
Re[4]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.11 21:38
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Анонимные классы?

H>
H>using Nemerle.Extensions;

H>def x = new ( a = 10, b = "foo" );
H>


Отлично. Как бы хотел видеть работу этого макроса при условии, что макросы начинают жить в параллельных потоках?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 03.01.11 21:40
Оценка:
Здравствуйте, catbert, Вы писали:

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


Как бы видел реализацию этого юзкейза если предположить, что макросы могут зить в разных потоках?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Требуются примеры макросов уровня выражения создающих ти
От: Аноним  
Дата: 04.01.11 00:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Таким образом мы хотим ввести неизменяемое АСТ которое можно будет только порождать и хотим сделать так чтобы макросы не могли бесконтрольно менять дерево типов и сами типы.


Похоже макросы оказались слишком сильной штукой и приходится их сознательно ослаблять.
Re[2]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.11 00:48
Оценка:
Здравствуйте, Аноним, Вы писали:

VD>>Таким образом мы хотим ввести неизменяемое АСТ которое можно будет только порождать и хотим сделать так чтобы макросы не могли бесконтрольно менять дерево типов и сами типы.


А>Похоже макросы оказались слишком сильной штукой и приходится их сознательно ослаблять.


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

Об ослаблении макросов речи не идет. В Nemerle 2, наоборот, макросы будут более мощными нежели в 1.х. Снимутся практически все ограничения на расширение синтаксиса и будут устранены другие проблемы которые были выявлены в ходе использования Nemerle 1.х.

Просто в целях распараллеливания компилятора и уменьшения количества ошибок решено сделать AST неизменяемым. Это вовсе не значит, что его нельзя будет менять. Просто его изменение будет иметь характер трансформации (порождения нового дерева), а не императивного изменения.

Так что не надо искать здесь какое-то доказательство своих теорий. Слишком сильной штукой оказалось императивное программирование базирующаяся на машине Фор Нэймана. Вот ее мы и хотим урезать. Императив будет только там где от него есть серьезная выгода и мало вреда.

Короче, мы просто хотим реализовать новый компилятор без ошибок в дизайне (или с их минимальным числом), так как его следовало бы делать с самого начала.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Требуются примеры макросов уровня выражения создающих
От: Аноним  
Дата: 04.01.11 05:25
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Об ослаблении макросов речи не идет. В Nemerle 2, наоборот, макросы будут более мощными нежели в 1.х. Снимутся практически все ограничения на расширение синтаксиса и будут устранены другие проблемы которые были выявлены в ходе использования Nemerle 1.х.

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

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

Мне кажется эта задача сходная, с улучшением кода для множества асинхронных вызовов.
Re[3]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 04.01.11 06:28
Оценка:
Здравствуйте, VladD2, Вы писали:

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


В nrails есть макрос viewmodel, он создает именованный тип, который может использоваться явно по имени либо генерацией типизированной view.
Re[4]: Требуются примеры макросов уровня выражения создающих
От: hardcase Пират http://nemerle.org
Дата: 04.01.11 08:42
Оценка:
Здравствуйте, Аноним, Вы писали:

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


Код макроса потенциально может вызывать черте что и находиться вообще в других сборках.
/* иЗвиНите зА неРовнЫй поЧерК */
Re[2]: Требуются примеры макросов уровня выражения создающих
От: catbert  
Дата: 04.01.11 11:54
Оценка:
Здравствуйте, Аноним, Вы писали:

А>Похоже макросы оказались слишком сильной штукой и приходится их сознательно ослаблять.


Ага, в том же смысле, что автомат Калашникова слишком сильная штука, и приходится сознательно добавить в его конструкцию предохранитель.
Re[5]: Требуются примеры макросов уровня выражения создающих
От: catbert  
Дата: 04.01.11 11:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Как бы видел реализацию этого юзкейза если предположить, что макросы могут зить в разных потоках?


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

В любом случае, мердж, мне кажется, вполне разумное решение. Только для макроса локализации остается проблема: после того как ВСЕ макросы s"" создадут свои поля, нужно еще создать конструктор этого класса, где будут загружаться переводы. Причем, смержить конструктор не получится, потому что для одинаковых s""-строк нужен один и тот же перевод. я

То есть нужен еще механизм отложенного запуска кода после мерджа.
Re[6]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.11 12:29
Оценка:
Здравствуйте, catbert, Вы писали:

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


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

C>Если макрос живет не в том потоке, в каком компилируется тело метода, тогда по-моему вообще начинается хаос.


Макрос живет в том потоке в котором типизируется метод тела в котором задействован макрос.
Проблема в том, что параллельно может типизироваться несколько тел методов. Точно так же параллельно может парситься несколько файлов.

C>В любом случае, мердж, мне кажется, вполне разумное решение.


Боюсь, что это будет излишним переусложнением.

C>Только для макроса локализации остается проблема: после того как ВСЕ макросы s"" создадут свои поля, нужно еще создать конструктор этого класса, где будут загружаться переводы. Причем, смержить конструктор не получится, потому что для одинаковых s""-строк нужен один и тот же перевод. я


C>То есть нужен еще механизм отложенного запуска кода после мерджа.


Это решается запуском макроса на очень поздней стадии (после раскрытия всех макросов) или и вовсе подключением на событие.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 04.01.11 12:31
Оценка:
Здравствуйте, Ziaw, Вы писали:

Сори за офтоп.

Я тут поставил бэту TortoiseHg и никак не могу найти в ней где задавать логин и пароль.

Ну, и еще один вопрос. Ты не пробовал заниматься чтением метаданных? Клон ты вроде завел. Но в нем никаких изменений с тех пор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 04.01.11 13:39
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Сори за офтоп.


VD>Я тут поставил бэту TortoiseHg и никак не могу найти в ней где задавать логин и пароль.


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

VD>Ну, и еще один вопрос. Ты не пробовал заниматься чтением метаданных? Клон ты вроде завел. Но в нем никаких изменений с тех


Не пробовал. У меня сейчас другой личный проект требует времени, надеюсь уже немного, но его все равно не хватает, а CCI вроде кто-то занялся и без меня. А клон я вообще заводил для демонстрации работы с клонами и для того, чтобы покончить с голословным обсуждением начальной структуры каталогов.
Re[7]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 04.01.11 14:56
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Что-то у них совсем уродское ГУИ. Напоминает ГУЙ к древнему CVS. Почему они просто не содрали ГУЙ с Тортилы для SVN (с учетом особенностей, конечно)?

VD>Ладно. Вопрос риторический .

А какой там гуй глобально отличается? Вобщем-то они все и содрали. Только потом еще сделали одно большое окно в котором можно делать все не вылезая из него. Мне удобно

Тортила для свн она постарше будет, и работает только в винде, с гуем у нее по любому будет получше.
Re[5]: Требуются примеры макросов уровня выражения создающих
От: Аноним  
Дата: 04.01.11 21:34
Оценка:
Здравствуйте, hardcase, Вы писали:

H>Код макроса потенциально может вызывать черте что и находиться вообще в других сборках.

Разве с этим не придется тоже как-то справляться в рамках борьбы за распараллеливание?
Или почему-то будет достаточно только запрета на изменение AST?
Re[6]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 05.01.11 00:02
Оценка:
Здравствуйте, Аноним, Вы писали:

H>>Код макроса потенциально может вызывать черте что и находиться вообще в других сборках.

А>Разве с этим не придется тоже как-то справляться в рамках борьбы за распараллеливание?
А>Или почему-то будет достаточно только запрета на изменение AST?

АСТ меняется локально, так что с этим проблем нет. Вот дерево типов вещь глобальная по своей природе. И его изменение (т.е. изменение состава типов и их содержимого) и требует защиты.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Требуются примеры макросов уровня выражения создающих ти
От: Ziaw Россия  
Дата: 05.01.11 07:37
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Мы тут продумываем новую стратегию компиляции. Главной ее особенностью будет параллелизм компиляции тел методов (и вообще, любой макрос может быть запущен параллельно другим. Таким образом мы хотим ввести неизменяемое АСТ которое можно будет только порождать и хотим сделать так чтобы макросы не могли бесконтрольно менять дерево типов и сами типы.


Тут подумалось, что кроме одновременного запуска на нескольких ядрах, это ведь даст возможность запоминать иммутабельные куски и перекомпилировать только измененные части большого проекта. Фактические это означает, что любой корректный код можно запустить в доли секунды.
Re[2]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.11 00:48
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


Собственно неизменяемость добавляется не только из соображений распараллеливания. В частности это упростит разработку поддержки IDE.
Что же касается быстрой компиляции, то там не все так просто. Так что навряд ли удастся сделать инкрементальную компиляцию. Но несомненно неизменяемое АСТ упростит реализацию этой фичи.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 05:56
Оценка:
Здравствуйте, VladD2, Вы писали:

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

VD>Что же касается быстрой компиляции, то там не все так просто. Так что навряд ли удастся сделать инкрементальную компиляцию. Но несомненно неизменяемое АСТ упростит реализацию этой фичи.

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

Например макрос уровня выражения, для запоминания локализованных строк не использует какое то хранилище внутри себя, а просто вставляет кое-то свое UserInfo в AST. При генерации хелперного типа мы сможем получить все свои вшитые UserInfo и сгенерировать нужные поля в каком-то классе.
Re[4]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.11 06:16
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Ну как минимум, результаты парсинга уже можно кешировать. Если


Да. Но не целиком, а по файлам. Изменяющийся файл придется перепарсивать.

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


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

Самое кэширование — это уже императивный подход.

В компиляторе есть структуры данных которые принципиально не могут быть функциональными. Главная из них — это дерево типов. Его части могут быть "чистыми". Но само дерево одно на проект. И как не крути его придется менять. Даже если сделать самое дерево неизменяемым (порождающим новую версию), то все равно будет одна переменная в которую придется поместит новую версию дерева. К тому же хэш-таблицы при больших объемах значительно быстрее нежели деревья. Так что для поиска данных выгоднее использовать хэш-таблицы, а не деревья.
Ну, а к дереву типов нужен параллельный (конкурентный) доступ.

Так что как не крути, а тут без синхронизации не обойтись.

Во-вторых, как я уже говорил есть ряд проблем.

В идеале было бы вообще сделать так, чтобы IDE работала как часть компилятора. Тогда бы можно было вообще почти молниеносно стартовать при изменении тела метода. Но тут вступают в силу реалии мира. Многие макросы настолько медленны, что они по разному работают в режиме IDE и в режиме компиляции. Пример такого макроса — PegGrammar.

Z>Например макрос уровня выражения, для запоминания локализованных строк не использует какое то хранилище внутри себя, а просто вставляет кое-то свое UserInfo в AST. При генерации хелперного типа мы сможем получить все свои вшитые UserInfo и сгенерировать нужные поля в каком-то классе.


Примерно об этом и идет речь. Только вот люди не хотят траха. Они хотят писать простой и понятный им (а значит синхронный) код.

Потом компилятор ведь не будет знать, что делать с этим UserInfo. Где-то все равно будет код который будет заменять эти UserInfo на код по которому можно сгенерировать выполнимый код. А его результаты уже кэшировать невозможно. Точнее может и можно, но анализ нужно ли это делать или нет будет сложнее генерации.

В общем, есть ряд проблем:
1. Макросы генерирующие типы препятствуют кэшированию.
2. Любое изменение дерева типов приводит к перегенерации всего. Можно попытаться оптимизировать это, но при этом получится очень сложный код.
3. Некоторые макросы принципиально не могут работать быстро. Это приводит к тому, что их поведение в режиме IDE и режиме компиляции отличается. А это не позволяет использовать кэш IDE для компиляции. Выходит, что придется иметь два кэша, но это может оказаться слишком накладно (процессоров то пока что ограниченное количество).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 07:53
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>В компиляторе есть структуры данных которые принципиально не могут быть функциональными. Главная из них — это дерево типов. Его части могут быть "чистыми". Но само дерево одно на проект. И как не крути его придется менять. Даже если сделать самое дерево неизменяемым (порождающим новую версию), то все равно будет одна переменная в которую придется поместит новую версию дерева. К тому же хэш-таблицы при больших объемах значительно быстрее нежели деревья. Так что для поиска данных выгоднее использовать хэш-таблицы, а не деревья.

VD>Ну, а к дереву типов нужен параллельный (конкурентный) доступ.

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

А вот требование к мутабельности самого дерева во всех стадиях компиляции действительно сильно напрягает. Может подумать в сторону нескольких этапов трансформаций дерева типов? Тогда мы сможем иметь дело с иммутабельным lock-free деревом типов.

Правда макрос придется писать либо в event-driven виде, либо cps, либо как сейчас: несколько одноименных макросов на разные стадии компиляции. Стадии компиляции, все равно придется синхронизировать, от этого не уйти, зато очередную трансформацию дерева можно запускать как только мы получили все нужные для нее данные, что дает хорошее поле для оптимизаций порядка запуска макросов.
Re[6]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 06.01.11 08:55
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Хештаблицы вполне могут просто обеспечивать быстрый доступ к листьям дерева и никак не мешают самому существованию дерева, строится оно не медленнее хештаблиц.


Гы. Хэш-таблицы — это императивные штуки. Их нужно синхронизировать. По сему проще запретить менять дерево напрямую.

Z>А вот требование к мутабельности самого дерева во всех стадиях компиляции действительно сильно напрягает. Может подумать в сторону нескольких этапов трансформаций дерева типов? Тогда мы сможем иметь дело с иммутабельным lock-free деревом типов.


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

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

Z>Правда макрос придется писать либо в event-driven виде, либо cps, либо как сейчас: несколько одноименных макросов на разные стадии компиляции. Стадии компиляции, все равно придется синхронизировать, от этого не уйти, зато очередную трансформацию дерева можно запускать как только мы получили все нужные для нее данные, что дает хорошее поле для оптимизаций порядка запуска макросов.


Ага. Тут есть над чем подумать. Мне больше нравятся варианты с cps и запросом на создание/модификацию типа. В последнем случае можно попытаться автоматически вычислить, что ссылка идет на еще не добавленный тип и автоматом отложить типизацию на следующую стадию. А стадии сделать неограниченными.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[7]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 14:36
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Гы. Хэш-таблицы — это императивные штуки. Их нужно синхронизировать. По сему проще запретить менять дерево напрямую.


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

Z>>А вот требование к мутабельности самого дерева во всех стадиях компиляции действительно сильно напрягает. Может подумать в сторону нескольких этапов трансформаций дерева типов? Тогда мы сможем иметь дело с иммутабельным lock-free деревом типов.


VD>Об этом я и думаю. Вольфхаунд предлагает как ты (в первый раз) не парясь тупо возвращать новые типы из макросов и потом их сувать в дерево (не парясь над конфликтами). Но это сильно усложнит жизнь марописателям.


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

Допустим трансформируем мы
unless (macro1(x))
{
  macro2();
  macro3();
}


Макрос unless возвращает не до конца вычисленный матч,
match (macro1(x))
{
  | false => 
    macro2();
    macro3()
  | true => 
    ()
}

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

VD>Я пока не определился, но похоже что проще всего будет ввести те самые стадии. Но тот же Вольфхаунд что-то ерепенится против этого.


Вероятно у него есть какой-то не до конца созревший план.

VD>Ага. Тут есть над чем подумать. Мне больше нравятся варианты с cps и запросом на создание/модификацию типа. В последнем случае можно попытаться автоматически вычислить, что ссылка идет на еще не добавленный тип и автоматом отложить типизацию на следующую стадию. А стадии сделать неограниченными.


Именно, стадий должно быть столько сколько нужно коду. Тут правда встает вопрос о неаккуратном замедлении компиляции и сложностью выявления таких мест, но это тоже решаемый момент.
Re[6]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 20:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>2)Типизация и генерация видимых пользователю типов и методов.

WH>Не важно приватных или публичных.

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

Осталось понять как записать макрос, для которого это все должно выглядеть императивно.

// допустим нам нужна макра создающая массив и заполняющая его значениями зависящими от типа элемента.
def x = my_array(5);

when (x[0] == "1") // вот тут по идее компилятор сможет вывести тип из использования
{
 ...
}

macro my_array 
  syntax my_array '(' count : int ')'
{
  // здесь мы должны прервать выполнение макроса и дождаться вывода типов 
  // но парсинг должен продолжаться, поэтому мы, для начала возвращаем заглушку
  def unknownType = Context.MakeUnknownType()
  def knownType = yield <[ array.[$unknownType]($count) ]> and wait Context.GetType(unknownType); 

  // сюда мы попадаем уже после той стадии типизации, которая смогла вывести тип для заглушки
  def defaultValue = GetDefaultExprForType(knownType); // логика получения дефолтного выражения для типа не важна для примера

  <[
    def arr = array($count);
    for (int i = 0; i < arr.Length; i++)
       arr[i] = $defaultValue;
    arr
  ]>  // а вот это уже окончательный вариант работы макроса, генерация кода
}


Этот макрос сам не трогает дерево типов, как только начнет — типизацию придется проводить заново после его выполнения.
Re[6]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 20:15
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Те если мы хотим прочитать метаданные из базы нужно представить что база это некий виртуальный исходник. Прочитать метаданные и положить их в АСТ.


Только эти метаданные в AST надо научиться помечать как не кешируемые. Ибо изменяться они могут чаще чем исходник с макросом который их порождающим.
Re[8]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 20:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

Z>>Вот этот этап не совсем ясен, после него, некие синтаксические макры захотят сделать что-то еще.

WH>Синтаксические макры это макры которые текст разбирают. Те это этап номер 1.

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

Z>>Осталось понять как записать макрос, для которого это все должно выглядеть императивно.

WH>А может не надо императивно?

WH>На первом этапе у нас отработает только парсер и поместит в АСТ просто разобранный код:

WH>MyArray(IntLiteral(1))
WH>На втором этапе отработает информация о типах.
WH>На третьем этапе уже будет вызван сам код макроса.

Идея очень нравится. Только не очень понятно, как описать макру возвращающую тип который требуется создать. Конструктор анонимного типа или viewmodel в nrails. До создания этого типа полная типизация невозможна, создание типа до проведения частичной типизации тоже выглядит невозможным.
Re[7]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 06.01.11 21:01
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Только эти метаданные в AST надо научиться помечать как не кешируемые. Ибо изменяться они могут чаще чем исходник с макросом который их порождающим.

Тут нужно делать хитрее.
Нужно сделать "поставщиков АСТ" частным случаем которых будут исходники положенные в проект.
ast provider DataBaseMetadataProvider(connectionString : string) : DataBaseMetadata
load
{//Производит чтение метаданных из базы.
//Возвращает АСТ
}
need update
{//вызывается каждый раз когда компилятор хочет узнать не изменился ли АСТ
//Возвращает true если нужно обновить АСТ.
//Если вернули true то вызывается load
}

Также нужно подумать о том как провайдер может сказать компилятору о том что аст нужно перечитать.

Таким образом мы можем не только перечитывать АСТ чаще чем парсим исходник где вызывается DataBaseMetadataProvider но и реже. Ибо зачем перечитывать базу данных если connectionString не изменился?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Требуются примеры макросов уровня выражения создающих
От: Ziaw Россия  
Дата: 06.01.11 21:16
Оценка:
Здравствуйте, WolfHound, Вы писали:

Z>>Только эти метаданные в AST надо научиться помечать как не кешируемые. Ибо изменяться они могут чаще чем исходник с макросом который их порождающим.

WH>Тут нужно делать хитрее.
WH>Нужно сделать "поставщиков АСТ" частным случаем которых будут исходники положенные в проект.

У меня тоже последнее время крутятся мысли вокруг фшарповских typeproviders.

WH>Также нужно подумать о том как провайдер может сказать компилятору о том что аст нужно перечитать.


Тут как раз обычный ООП подойдет, задаем у базового класса
public virtual IsModfiedSince(DateTime dt) : bool { true }
и даем возможность провайдеру самому управлять кешированием.

WH>Таким образом мы можем не только перечитывать АСТ чаще чем парсим исходник где вызывается DataBaseMetadataProvider но и реже. Ибо зачем перечитывать базу данных если connectionString не изменился?


Например затем, чтобы прочитать актуальную версию изменившейся схемы или свежие данные. Но основная мысль понятна, IsModfiedSince ей в помощь.
Re[8]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.11 10:51
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Z>>Только эти метаданные в AST надо научиться помечать как не кешируемые. Ибо изменяться они могут чаще чем исходник с макросом который их порождающим.

WH>Тут нужно делать хитрее.
WH>Нужно сделать "поставщиков АСТ" частным случаем которых будут исходники положенные в проект.

Таких поставщиков можно просто оформлять отдельными проектами. Перекомплил проект, получил обновление метаданных. В рамках проекта могут и более сложные макры работать которые могут отслеживать изменения в СУБД хоть по таймеру, хоть как. Ну, и при изменении тупо махать список типов.

В новой версии компилятора проект (или сборка) у нас будет выражаться вот таким интерфейсом:
  public interface IReferencedAssembly
  {
    CustomAttributes  : ICustomAttributes { get; }
    Types             : Seq[NTypeInfo]    { get; }
    Macros            : Seq[IMacro2]      { get; }
    Msgs              : list[Msg]         { get; }
    ImagePath         : string            { get; }
    FullName          : string            { get; }

    event Changed : EventHandler;


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

Получается стройная модель для случаев вроде провайдеров метаданных СУБД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 07.01.11 13:08
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Таких поставщиков можно просто оформлять отдельными проектами. Перекомплил проект, получил обновление метаданных. В рамках проекта могут и более сложные макры работать которые могут отслеживать изменения в СУБД хоть по таймеру, хоть как. Ну, и при изменении тупо махать список типов.

И какими же механизмами будут пользоваться эти самые "более сложные макры"?
В какой момент они будут цепляться к СУБД?
Как на это будт реагировать интелисенс внутри проекта?

Я уж не говорю про то что вместо одной строчки появился целый проект на пустом месте.

Ты бы хоть для разнообразия попытался понять о чем я говорю, а не начинал с ходу спорить со своим воображением.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 07.01.11 13:08
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Идея очень нравится. Только не очень понятно, как описать макру возвращающую тип который требуется создать. Конструктор анонимного типа или viewmodel в nrails. До создания этого типа полная типизация невозможна, создание типа до проведения частичной типизации тоже выглядит невозможным.

У меня есть несколько вариантов но надо еще подумать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[9]: Требуются примеры макросов уровня выражения создающих
От: WolfHound  
Дата: 07.01.11 13:08
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>У меня тоже последнее время крутятся мысли вокруг фшарповских typeproviders.

typeproviders частный случай и тривиально реализуются через этот механизм.

Z>Например затем, чтобы прочитать актуальную версию изменившейся схемы или свежие данные. Но основная мысль понятна, IsModfiedSince ей в помощь.

Ну так этот IsModfiedSince и не даст перечитывать базу чаще чем нужно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Требуются примеры макросов уровня выражения создающи
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.11 15:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


VD>>Таких поставщиков можно просто оформлять отдельными проектами. Перекомплил проект, получил обновление метаданных. В рамках проекта могут и более сложные макры работать которые могут отслеживать изменения в СУБД хоть по таймеру, хоть как. Ну, и при изменении тупо махать список типов.

WH>И какими же механизмами будут пользоваться эти самые "более сложные макры"?
WH>В какой момент они будут цепляться к СУБД?

Это уже их проблемы. По таймеру, например, можно проверять изменение БД.

WH>Как на это будт реагировать интелисенс внутри проекта?


Ему то что? Скажут перечитать проект, перечитает. Если сборка сигнализирует о своем изменении, интеллисенс обязан отреагировать.

WH>Я уж не говорю про то что вместо одной строчки появился целый проект на пустом месте.


Что-то я ни разу не видел, чтобы описание ORM занимало одну строчку.

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


Ты бы лучше для разнообразия сам бы разок этот самый ORM наладил. Тогда понял бы что говорить об одной строчке в таком вопросе смешно. Автоматический мапинг только в тестах прокатывает. Посмотри на то как мапинг выглядит в Nemerle on Rails. Там как раз отдельный проект и используется (если не ошибаюсь).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Требуются примеры макросов уровня выражения создающи
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.11 15:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

VD>>Это какие-то фантазии имеющие мало общего с реальностью и мало понятные. Что такое "type of count int" я так и не понял. Какой-то ОКамл.

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

Ага. Фантазии на вольную тему с жутким синтаксисом.

VD>>В подобных случаях все будет очень просто. Нужно просто применять не один, а два макроса. Один синтаксический, другой обычный. Код будет примерно таким:

WH>Блин. Ты сравни колличество кода.

Дык не с чем сравнивать. Фантазии против реального кода.

WH>А вот эту магию вообще никто не поймет.

WH>
WH>  def typedExpr = typer.TypeExpr(expr);
WH>  def ty = typedExpr.Type.Hint;

WH>  if (ty.HasValue)
WH>

WH>Что тут происходит? Императив какойто.

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

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

WH>При том что мой вариант декларативный.


Фантазии у тебя там написаны, а не варинт. Ничего общего с реальностью. Это не только не взлетит, но еще и не нужно никому.

VD>>Скажу больше. Это совершенно надуманный пример, так как для конструкции my_array(3) нет смысла вводить новый синтаксис, так что можно было бы спокойно обойтись обычным макросом.

WH>Это вообще к делу не относится.

Ну, да решаем задачу которую решать то не надо и получаем горы кода.

VD>>Короче, пример надуманный. Так как типы в нем не порождаются, то и проблем он вызвать не может.

VD>>Но даже на таком простом примере ты уже на фантазировал черти чего.
WH>Это ты наговнокодил черт знает чего.
WH>Весь твой императив никто никогда не поймет.

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

WH>Если ты думаешь что мой вариант не ясен то это не так. Ziaw все понял.


Что он мог понять? Ты сам то не понял что написал . Изобрел какой-то ОКамл без малейшей нужды.
На фиг компилятору твои подсказки? Да еще в таком ужасном виде? Он все типы и так выведет.

VD>>Это четко демонстрирует, что все разговоры о концепциях очень быстро разбиваются о реальность, если их не подкреплять скрупулезным (детальным) планом реализации.

WH>Нет.
WH>Это четко демонстрирует что прежде чем спорить нужно понять о чем вообще разговор.

Да понял я все. Ты спустись от фантазий к реалиям. И поймешь, что все сильно сложнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Требуются примеры макросов уровня выражения создающи
От: WolfHound  
Дата: 07.01.11 16:31
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>Ему то что? Скажут перечитать проект, перечитает. Если сборка сигнализирует о своем изменении, интеллисенс обязан отреагировать.

Еще раз. Что ты будешь делать внутри этой сборки?
Сборки которые на нее ссылаются меня сейчас не волнуют.

WH>>Я уж не говорю про то что вместо одной строчки появился целый проект на пустом месте.

VD>Что-то я ни разу не видел, чтобы описание ORM занимало одну строчку.
Я не говорил про мапинг. Я говорил про чтение метаданных.
Это нужно делать в том же проекте где описан маппинг.
И чтение метаданных это одна строчка.
И таки интелисенс нужен в этом же проекте, а не в каком то другом.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Требуются примеры макросов уровня выражения создающи
От: VladD2 Российская Империя www.nemerle.org
Дата: 07.01.11 17:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Я не говорил про мапинг. Я говорил про чтение метаданных.

WH>Это нужно делать в том же проекте где описан маппинг.
WH>И чтение метаданных это одна строчка.

Мапинг как раз имеет смысл выделять в отдельный проект. При его сборке и читать метаданные. А уж в другом спокойно писать запросы и т.п. Так, собственно, сейчас и делается.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Требуются примеры макросов уровня выражения создающи
От: WolfHound  
Дата: 07.01.11 17:39
Оценка:
Здравствуйте, VladD2, Вы писали:

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

Пятидесятый раз: Какми средствами ты будешь обеспечивать интелисенс в проекте с маппингом?
Самый простой и концептуально правильный способ получить метаданные это представиь БД как виртуальный исходник и распарсить его в АСТ читалкой базы данных.
А все таймеры и прочую ерунду должна взять на себя интеграция. Ибо повторять это все в каждом макросе который будет ходить во внешние источники данных дурь редкостная.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Требуются примеры макросов уровня выражения создающи
От: catbert  
Дата: 07.01.11 20:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Самый простой и концептуально правильный способ получить метаданные это представиь БД как виртуальный исходник и распарсить его в АСТ читалкой базы данных.


Что-то я этого простого способа не понимаю. Если БД это виртуальный исходник, где код? В БД сохраняется или как?
Re[15]: Требуются примеры макросов уровня выражения создающи
От: WolfHound  
Дата: 07.01.11 21:01
Оценка:
Здравствуйте, catbert, Вы писали:

C>Что-то я этого простого способа не понимаю. Если БД это виртуальный исходник, где код? В БД сохраняется или как?

Код это метаданные БД.
"Парсер" это хрень которая цепляется к БД, читает метаданные и генерит по ним аст.
Для остального кода разници между текстовым файлом и вот такм вот "исходником" нет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Требуются примеры макросов уровня выражения создающи
От: Ziaw Россия  
Дата: 08.01.11 12:18
Оценка:
Здравствуйте, VladD2, Вы писали:

WH>>Я не говорил про мапинг. Я говорил про чтение метаданных.

WH>>Это нужно делать в том же проекте где описан маппинг.
WH>>И чтение метаданных это одна строчка.

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


А зачем вводить такие ограничения? Костыли для интелисенса? Он у нас изначально инвалидом задумывается что-то? Виртуальные исходники вообще для очень разных задач могут применяться, маппинг в бд один из частных случаев?
Re[10]: Требуются примеры макросов уровня выражения создающи
От: Ziaw Россия  
Дата: 08.01.11 12:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

Z>>У меня тоже последнее время крутятся мысли вокруг фшарповских typeproviders.

WH>typeproviders частный случай и тривиально реализуются через этот механизм.

Просто принцип действия очень похож, у меня тоже в эту сторону мысли были.

Z>>Например затем, чтобы прочитать актуальную версию изменившейся схемы или свежие данные. Но основная мысль понятна, IsModfiedSince ей в помощь.

WH>Ну так этот IsModfiedSince и не даст перечитывать базу чаще чем нужно.

Брр, это был ответ на "зачем перечитывать базу данных если connectionString не изменился". Про IsModfiedSince я именно это и имел ввиду.
Re[11]: Требуются примеры макросов уровня выражения создающи
От: WolfHound  
Дата: 08.01.11 15:58
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Брр, это был ответ на "зачем перечитывать базу данных если connectionString не изменился". Про IsModfiedSince я именно это и имел ввиду.

Ну вырывай слова из контекста.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Требуются примеры макросов уровня выражения создающих ти
От: BogdanMart Украина  
Дата: 31.05.11 20:01
Оценка:
Здравствуйте, VladD2, Вы писали:

VD>По сему нам нужны наиболее реалистичные примеры (usecase-ы) макросов уровня выражения которым требуется порождать (менять, удалять) новые типы (члены типов).


Не знаю. может что то подобное и писали но воот пример:

public Figase() : void
{
  when (1 == 2) // это я шутю... )
    throw exception FigaseException("Описание");  // тут генерируется внешне видимый класс для исключения
}


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

Ну то не суть важно, просто просили юзкейс.
Re[8]: Требуются примеры макросов уровня выражения создающих
От: Danchik Украина  
Дата: 01.06.11 08:45
Оценка:
Здравствуйте, Ziaw, Вы писали:

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


VD>>Что-то у них совсем уродское ГУИ. Напоминает ГУЙ к древнему CVS. Почему они просто не содрали ГУЙ с Тортилы для SVN (с учетом особенностей, конечно)?

VD>>Ладно. Вопрос риторический .

Z>А какой там гуй глобально отличается? Вобщем-то они все и содрали. Только потом еще сделали одно большое окно в котором можно делать все не вылезая из него. Мне удобно


Есть у меня принцип: не нравится программа визуально — внутри полный трындец. Имхо чуствуется безалаберность. Работает в 90%.
Тем кто создавал TortoiseHg надо было MS Guidelines начитаться и курить до полного просветления.
Один только этот скриншот убил наповал


Z>Тортила для свн она постарше будет, и работает только в винде, с гуем у нее по любому будет получше.

Ага TortoiseHg будет работать и под иксами Щас
И что надо сразу писать у...но, а потом когда постареем, все само и поправится?
Re[9]: Требуются примеры макросов уровня выражения создающих
От: Аноним  
Дата: 01.06.11 09:59
Оценка:
macro MakeAssignmentMacro(expr)
{
    <[ def MakeAssignmentMacro(ref expr){expr=42;}
       def MakeAssignmentMacro(ref expr){expr="42";}
       def MakeAssignmentMacro(ref expr) error("требеется или строка или число")
       MakeAssignmentMacro($expr);
 ]>
}


так не проще?
Re[2]: Требуются примеры макросов уровня выражения создающих
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.06.11 16:53
Оценка:
Здравствуйте, BogdanMart, Вы писали:

BM>Не знаю. может что то подобное и писали но воот пример:


BM>
BM>public Figase() : void
BM>{
BM>  when (1 == 2) // это я шутю... )
BM>    throw exception FigaseException("Описание");  // тут генерируется внешне видимый класс для исключения
BM>}
BM>


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