Всем привет!

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

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

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

Кроме того предлагаются любые идеи в области распараллеливания работы макросов.

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

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

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

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

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

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

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

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

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

C>

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

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

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

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

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

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

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

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

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

using Nemerle.Extensions;


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

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

VD>Тогда остаются вопросы:
VD>1. Как сделать ссылку на локально созданное поле?

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

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

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

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


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

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

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

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

H>using Nemerle.Extensions;

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

Отлично. Как бы хотел видеть работу этого макроса при условии, что макросы начинают жить в параллельных потоках?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мне кажется эта задача сходная, с улучшением кода для множества асинхронных вызовов.

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

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

В nrails есть макрос viewmodel, он создает именованный тип, который может использоваться явно по имени либо генерацией типизированной view.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это решается запуском макроса на очень поздней стадии (после раскрытия всех макросов) или и вовсе подключением на событие.

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

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

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

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

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

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

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

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

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

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

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

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

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