LINUX.ORG.RU

\[C#, F#, Haskell\]Метапрограммирование в статических ЯП

 , ,


1

5

Есть вполне конкретная задача. Нужно типизировать достаточно большой объем данных. Есть описания типов и правила, по которым из этих описаний можно построить типы. Пример описания: (A nil nil (m :type Object :arg «m» :get t :set t)), это просто из головы, что значит - тип A, не имеет базового типа, не реализует интерфейсов, имеет слот m, который при создании типа должен быть взят из входных данных(имеющих заранее известный тип) по ключу «m» и для которого есть стандартные методы get и set.

Дело в том, что объект типа A создается по xml и является его типизированным описанием. К примеру, для инициализации типа A подойдет следующий xml:

<item> <m> I'mm </m> </item>

не очень важно но мало ли - есть описания обобщенных типов, и способ решения коллизий, если по одним входным типам можно построить несколько типов, к примеру если есть тип B =eq= A

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

К примеру, решение такой задачи на том же Common Lisp, выглядит вполне простым, это ничто иное как:

  • iDSL для описания типов
  • макрос, содержащий логику вывода/создания типа из iDSL

    Интересует, в первую очередь, подход для C# или F#, но интересно посмотреть на любой строго типизированный ЯП

Ответ на: комментарий от tailgunner

Ты хочешь в существующую программу добавить новые классы и загрузить из XML-файла объекты этих классов?

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

pseudo-cat ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

разница огромна, к примеру, на CL есть средства для метапрограммирования и эта задача решается достаточно тривиально. Писать генератор кода того же C++ я бы не взялся. Другое дело, что в том же C#, вроде есть какой-то способ описывать классы на уровне платформы, типа addMethod, addSlot, etc. Но я не разбирался. Простое howto, как это сделать в вашем любимом статическом ЯП я бы очень хотел увидеть.

pseudo-cat ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

естественно, CL хоть и динамический, но эта задача может решаться на нем также как и в статическом, т.е. кодогенерация за счет макросов

pseudo-cat ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

Другое дело, что в том же C#, вроде есть какой-то способ описывать классы на уровне платформы, типа addMethod, addSlot, etc.

А какая разница - вызвать addMethod или записать строчку в файл?

staseg ★★★★★
()
Ответ на: комментарий от staseg

ну к примеру не нужно описывать правила трансляции, этот этап просто опускается

pseudo-cat ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

Писать генератор кода того же C++ я бы не взялся.

Я бы тоже, но это уже проблемы Си++ (или моего недостаточного знания Си++). На Python я писал кодогенераторы (для Си) в совершенно «статическом» стиле, никаких принципиальных сложностей - CST, AST, код.

в том же C#, вроде есть какой-то способ описывать классы на уровне платформы, типа addMethod, addSlot, etc

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

Простое howto, как это сделать в вашем любимом статическом ЯП я бы очень хотел увидеть.

Мой любимый статический язык - Си %)

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

Ну вот, подбираемся к сути вопроса. Какого уровня компилятор тебе нужен?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от tailgunner

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

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

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

pseudo-cat ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

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

Если ты о Си - возможно, но я давно не писал трансляторов на Си.

Макропроцессор лиспа позволяет абстрагироваться от работы с текстом и дает возможность напрямую работать с AST

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

А тебе нужно еще преобразовать в него.

То, что никто не написал простой в использовании преобразователь (грамматика, строка) -> AST - плохо, но см. выше.

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

Воот. У меня как раз на этот код и уходит подавляющая часть времени. И я не вижу, как CL мне здесь поможет.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Воот. У меня как раз на этот код и уходит подавляющая часть времени. И я не вижу, как CL мне здесь поможет.

предположим, что CL - это и есть твое AST, чуешь?:)

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

  • транслятор в AST нужно как для CL так и для С писать, ок
  • как заметил один человек, оптимизации и там и там нужно делать, ок
  • транслятор из AST в target язык для CL не нужно писать(в частном случае).

    вот и думай кому проще живется, лисперу или тебе) Кстати, какими правилами обхода AST для Python ты пользуешься?)

pseudo-cat ★★★
() автор топика
Ответ на: комментарий от pseudo-cat

можно генерировать исходники просто, мне все равно

Ну так напиши транслятор, в чём проблема?

Dragon59 ★★
()
Ответ на: комментарий от pseudo-cat

предположим, что CL - это и есть твое AST, чуешь?:)

Чую. И что? Этот AST нужно проверить и преобразовать, а для этого нужно написать код. Не вижу разницы с не-CL.

транслятор из AST в target язык для CL не нужно писать(в частном случае).

Для этого случая - вероятно, выигрыш есть.

Кстати, какими правилами обхода AST для Python ты пользуешься?)

Эээ... думаю, я не понял твой вопрос, но depth-first обычно.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.