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

O>Не совсем. Про задачу от AndrewVK

Автор: AndrewVK
Дата: 13.07.05

я. Там ещё и конструктор генерится — типа чуть сложнее. Вот последние решения (их два):

Так и я о нем
Там, кстати еще есть разные

Автор: eao197
Дата: 15.07.05

решения (в том числе и на Ruby , именно исходной задачи, с парсингом XML). А еще и на Erlang-е

Автор: Gaperton
Дата: 14.07.05

.

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

O>Вообще в исходной задаче надо сгенерить класс на C#, но пусть лучше на Ruby — интересно посмотреть, как у Ruby именно с метапрограммированием.

Вообще-то, нормально
Metaprogramming et al: Ruby?

Автор: eao197
Дата: 10.08.05

и пару сообщений ниже. Там же интересные примеры метепрограммирования на Smalltalk.
И вот реальный проектик, который возможности метапрограммирования Ruby использует: [Ruby,C++] RuCodeGen -- простой фреймворк для кодогенерации

Автор: eao197
Дата: 16.11.05

(я таки остаюсь приверженцом precompile-time генерации).

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

IT>Хинт. Объявляешь к классу интерфейс с одним методом, который возвращает BLToolkit.Reflection.TypeAccessor. Дальше надо сгенерировать геттеры и сеттеры, набить их в возвращаемый TypeAccessor и готово. В BLToolkit добавляется проверка на наличие такого интерфейса и готово Nemerle в действии, одна run-time генерация устранена.

Попробовать можно. Но только ты ж понимаешь, что сам класс должен быть написан на Nemerle в таком случае.

Другой вариант — генерить наследник TypeAccessor-а по типу (брать инфу о классе прямо из рефлекшна), а в классе (который уже на C#) искать его по имени (ну или по атрибуту, на него нацепленному, — что-то вроде того). Правда, тогда получится гораздо менее удобно.

Это я так... вдруг начал размышлять о том, как логику оставить в C# (чтобы пользователи твоей тулзы особо не переживали ), а кодогенерацию вынести отдельно в Nemerle. Насколько я тебя понял, ты хочешь поиметь первый вариант.

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

O>Это я так... вдруг начал размышлять о том, как логику оставить в C# (чтобы пользователи твоей тулзы особо не переживали ), а кодогенерацию вынести отдельно в Nemerle. Насколько я тебя понял, ты хочешь поиметь первый вариант.

Нет, это не сильно отличается от того, что есть сейчас. К тому же можно сгенерировать сборку с аксессорами на пост-билд степе. Я имею ввиду код исключительно на Nemerle.

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

IT>Нет, это не сильно отличается от того, что есть сейчас. К тому же можно сгенерировать сборку с аксессорами на пост-билд степе. Я имею ввиду код исключительно на Nemerle.

Ок. В общем, постараюсь — самому интересно (иначе бы и не брался). Времени, времени только маловасто

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

S>Из заменяемого — мало. ВинАПИ имеет то "преимущество", что его невозможно выкинуть и заменить. В общем, мне кажется, что ты будешь выбирать ту библиотеку, которая хорошая.

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

S>Плохая — нафиг не нужна по очевидным причинам, а хорошую вряд ли напишут люди, которые просто хотели другой формы записи. Тем более вряд ли в проект попадут прямо десятки таких уродцев. "Я вчера случайно в шестой раз перечитал вашу книгу и опять плевался".

Так ты еще читаешь мои книги?

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

O>Смотри — ты всё равно в итоге генерируешь код из XML, используя XSLT

Я уже говорил — далеко не только код.

O>, на этапе компиляции, правильно?

Неправильно. И на этапе деплоймента тоже.

O> Почему бы не использовать Nemerle вместо XML и макросы вместо XSLT?

Перечитай

Автор: AndrewVK
Дата: 22.02.06

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

ВВ>>Вообще-то ядро написано на С.

VD>Я слышал, что весь на Лиспе. Может речь о диалекте была...

Ядро его Лиспа написано на С. Все остальное, включая львиную долю самого диалекта этого Лиспа, ядра EMacs-a и всего остального — на Лиспе.

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

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

WH>>Нет это не вопрос вобще...

VD>До тех пор пока ДжетБрэйнс не доделает РеШарпер для 2005-ой студии еще вопрос. Так как я предочту на сегодня менее навороченный, но стабильный варинт от МС.

вышла версия 2.19 — вполне стабильна

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

IT>Боюсь, этим скорее всго и закончится.

Обявляй. Я уже задолбался писать 10 строк вместо 1-2. Пол кода в объявлении свойст.

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

O>Он простой. Просто надо было докопаться до того, как всунуть список полей в объявление класса — всего и делов Это можно вынести во внешнюю функцию один раз и юзать всегда (если лучшего решения нет).

Мне кажется это просто баг компилятора. Нужно поговорить с его разработчиками.

VD>>Ты бы, кстати, объяснил его смысл. Почему ты пришел к такому решению?

O>Re[30]: Новая версия макроса

Автор: Oyster
Дата: 23.02.06

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

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

O>А сделано всё это так "императивненько" потому, что другого, более красивого способа, я не нашёл. Ну а код активации с их форума ещё не пришёл почему-то

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

В варианте приведеном nazgul:
http://nemerle.org/phpBB/viewtopic.php?t=200

macro metaclass(className, body) 
syntax ("metaclass", className, body) 
{ 
        def ctx = ImplicitCTX(); 
        def builder = ctx.Env.Define(<[ decl: [Record] public class $(className.ToString() : usesite) { } ]>); 
        mutable code = []; 
        match (body) 
        { 
                | <[ { .. $props } ]> => 
                        foreach(<[ $(n : name) : $(t : name) ]> in props) 
                        { 
                                builder.Define <[ decl: 
                                        [Accessor] 
                                        mutable $(n.NewName("_" + n.Id) : name) : $(t : name) ; 
                                ]>; 
                        } 
                | _ => Message.FatalError($"Invalid metaclass syntax, expected properties definition, got $body"); 
        } 
        builder.Compile(); 
        <[ () ]> 
}

код выглядит значитально проще чем в XSLT-варианте АВК:
http://rsdn.ru/Forum/Message.aspx?mid=1272272&only=1

Автор: AndrewVK
Дата: 14.07.05

<stylesheet>
    <template match="/objects">
        <!-- Здесь обычно пишется заголовок файла и неймспейс, но в примере его нет -->
        <apply-templates/>
    </template>
    
    <template match="object">
public class <value-of select="@name"/>
{
        <call-template name="make-ctor"/>
        <apply-templates/>
}
    </template>
    
    <template match="property">
    private <value-of select="@type"/> _<value-of select="@name"/>;
    public <value-of select="@type"/> <value-of select="@name"/>
    {
        get { return _<value-of select="@name"/>; }
    }
    </template>
    
    <template name="make-ctor">
    public <value-of select="@name"/>(
        <for-each select="property">
            <value-of select="@type"/> _<value-of select="@name"/>
            <if test="position() != last()">, </if>
        </for-each>
    )
    {
        <for-each select="property">
            _<value-of select="@name"/> = <value-of select="@name"/>;
        </for-each>
    }
    </template>
</stylesheet>

и это без функциональной декомпозиции.

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

V>Можешь начинать снимать. Есть такая либа VCF. Там смесь шаблонов и макросов используется для того, что ты сейчас сказал и еще для кучи вещей.

Пример в студию. И в общем, то сама библиотека не интересна. Интересен компилируемый код.

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

V>(в принципе, может зайти далеко, в MS есть открытый проект оптимизирующего бэк-энда компиляторов для дотнета, насколько я понял Nemerle пока его не юзает, но теоретически ничего не мешает)

Ты все перепутал. Есть Феникс. Феникс — это бэкэнд, но не оптимизирующий или для дотнета, а общий бэкэнд для всех компиляторов МС. Его можно использовать и для генерации MSIL-а, и для пре- или джит-компиляции готовых дотнетных сборок. Кроме того его можно применять для модификации МСИЛ-а готовых сборок и для генерации кода компиляторами. В частности планируется перевести VС++ на Феникс.

Пока что Феникс находится в стадии альфы, но уже доступен для скачивания. Ошибок там море. Rsdn.Editor он поднять не смог (вылетел с ошибкой).

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

V>Ядро его Лиспа написано на С. Все остальное, включая львиную долю самого диалекта этого Лиспа, ядра EMacs-a и всего остального — на Лиспе.

Ну, то что Лисп написан на С, а не на самом себе (все же VM у него нету) конечно прискорбно, но к делу не относится.

А спросил я это так как интересно какой объем исходников у базовой части редактора. Ну, за вычетом разных колореров и интелисенсов. То есть самой основной функциональности. Ведь размер кода Сцинтилы и Rsdn.Editor извесны, так что есть с чем сравнивать. Если Лисп действительно так крут на любых задачах, то код редактора должен быть в разы меньше.

Для сравнения код Сцинтила имеет ~680 кил кода, а Rsdn.Editor ~390.

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

O>Фигня вопрос. Смотрим код макроса (core.n):

O>

O>def ctx = if (expand) Some (Macros.ImplicitCTX()) else None ();
O>PrettyPrint.PrintExpr (ctx, exp);
O>

O>Как видишь, внутри вызов обычной функции — только контекст нужен. Итого: делаем ctx (как в макросе) и пихаем вместе с AST в PrintExpr().

Хм. Можно пример рабочего кода?

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

VD>Ну, то что Лисп написан на С, а не на самом себе (все же VM у него нету) конечно прискорбно, но к делу не относится.
VD>А спросил я это так как интересно какой объем исходников у базовой части редактора.

Боюсь чтобы это узнать нужно прежде всего выучить Лисп и выкинуть из нескольких десятков метров сурсов все лишнее

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

V>вышла версия 2.19 — вполне стабильна

Ага, стабильно глючит на больших проектах.

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

VD>Вот T-SQL или PL-SQL как раз полноценные языки, так как это обычные императивные ЯП с встроенным SQL.

Сделаешь хеш-табличку на T-SQL?

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

ВВ>Боюсь чтобы это узнать нужно прежде всего выучить Лисп и выкинуть из нескольких десятков метров сурсов все лишнее

Дык из Сцинтилы и RE я викинул все лишнее минут за 5.

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

VD>>Хм. И даже если я пишу утилиту командной строки для собственных целей?
S>Влад, твои утилиты командной строки никому не интересны. Кроме тебя же самого. Меня интересует разработка для заказчика, а не для меня.

Синклиер, ты меня извини, но многим, и в том числе мне, не интересны твои заказчики. У меня, например, ни разу в жизни не было не русскоязычных заказчико.
Так что не нужно уж так категорично. ОК?

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

VD>>И что мне помешает сделать такой макрос?
S>Я не знаю. Я пока вообще немерле не смотрел — у меня linq то проверить времени нету.

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

Одна из сильнейших фич макросов — это возможность исполнять код во время компиляции. Вот этот код может во истину творить чудеса.

VD>>Ну, а зачем номер?
S>Чтобы в другом порядке можно было аргументы поставить.

Порядок, и т.п. — это детали реализации.

VD>>И чем, раскажи на милость, это отличается от:
VD>>

VD>>$"Имя: $(person.Name) Фамилия: $(person.LastName) Возраст: $(person.Age), Место работы: $(person.Employment.CompanyName_ "
VD>>

S>Рассказываю: Я могу написать вот так:
S>

S>string.Format(Resources.PersonReportHeaderString, person);
S>

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

Ответ — в языке нет средств для расширения контроля во время компиляции.
Твои решения навязаны условностями и ограничниями используемого инструмента.
Теперь предстваь, что вместо string.Format ты можешь вызвать некий кусок кода который вполнится во время компиляции и сделает все что угодно, от преобразования кода, до создания нового файла.
Что бы ты мог сделать в таких условиях?

S>Еще раз: придумай, как решить проблему локализации. Это было бы очень круто.

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

S> А возможность слеплять строчки малоинтересна, т.к. она не дает ничего нового по сравнению с:
S>

S>"Имя: "+name+"Фамилия: "+lastname;
S>

S>Особенно заметно это станет, если ты попробуешь при помощи своего макроса вывести что-то без пробелов. Что-то мне подсказывает, что парсер споткнется на этом:
S>

S>$"Имя:$nameФамилия:$lastname"
S>

Пробелы не проблема, и тебе это показали рядом. А вот читается твой код с плюсами очень не красиво. Согласись.