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

Посоветуйте язык программирования сверхвысокого уровня (ЯПСВУ), программа на котором могла бы в COMPILE TIME обрабатывать и изменять свой же собственный код

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

К примеру, чтобы язык,к примеру, поддерживал конструкции типа "если вызов метода Tarl::MySleep(int, double) присутствует в коде программы более 3-х раз - то определить тип MyType как long double".

Повторяю. Пример чисто вымышленный и искусственный, и служит чиста для иллюстрации идеи.

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

Добавлено 29.07.16, 20:03
Соответственно, получается, что когда пишешь программу на таком языке, и меняешь ТЕКСТ какой-то её части, то ТЕКСТ других частей программы может при компиляции автоматом измениться {что есть такая штука как "препроцессор" я в курсе - но нужны более серьёзные и радикальные ВСТРОЕННЫЕ в язык средства}.

Т.е. в ЯПСВУ должны быть операторы, операндами которых служат текстовые объекты в самом исходнике.

Почему я назвал такой язык языком СВЕРХ высокого уровня?

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

Сообщение отредактировано: Исмаил Прокопенко - 29.07.16, 20:08

Прочитал в вики про существование парадигмы "рефлексия/отражение"
Ну то, про что я писал выше, не совсем "просто отражение".
Там как-то примитивно все понимается считая что это всего лишь небольшое расширение ООП.
Тогда как это совершенно особая парадигма.
И там речь идет больше про модификацию исходника в run time.
А я говорил в корневом посте про модификацию исходника в COMPILE TIME.
Т.е. получается, что программа как бы является по совместительству ещё и частью кода своего же компилятора, которым она компилируется.
Препроцессорные макросы с параметрами - это самые примитивные средства данной парадигмы


В препроцессорах есть #IFDEF-ы
Но они позволяют задавать очень примитивные условия.
А нужны более навороченные средства анализа своего же собственного кода.
Например "если в программе код A, имеющий след. структуру <описывается структура с помощью REGEX или грамматики более высокого уровня иерархии Хомкого>, то код B должен иметь такую структуру <описывается структура B и её связи с компонентами структуры A>"

Т.е. хочется, чтобы в коде присутствовали фактически структуры управления парсером исходника. Т.е. в исходнике кроме проблемно-ориентированных конструкции содержался фактически код его же (исходника) компилятора

Добавлено 31.07.16, 08:55
Чтобы код исходника и код его компилятора образовывали единый неделимый гибрид

Цитата

Когда компилятор С++ обрабатывает единицу трансляции, у него есть доступ к большому количеству полезных метаданных. Но, к сожалению, программисту эти данные практически не доступны. Сейчас комитет по стандартизации С++ рассматривает предложения N4111, которое призывает расширить возможности рефлексии на этапе компиляции уже в следующем обновлении языка (С++17). А до той поры с решением нашей задачи на С++ лучше повременить.

©

Есть опасность, что с использованием рефлексии C++, оставшись достаточно сложным языком (а с рефлексией он скорее всего ещё усложнится), лишится своих преимуществ в плане скорости работы.
кроме того, рефлексия всё равно не позволяет менять код программы. В C/C++ для этого используется динамическая компиляция.

У C++ достаточно средств для решения рефлексивных задач другими средствами. А если очень надо, рефлексия реализуется библиотеками. COM в WinAPI тому яркий пример, причём языконезависимый.

Я уже понял, что С++ не подходит.
Что реализовать на нем программу, которая кроме основной задачи могла бы ещё анализировать свой код и при необходимости менять его, без "костылей" не получится.

Нужны специализированные языки.

Кроме предположений "может ЛИСП?" и препроцессора m4 в рунете мне ничего не посоветовали.
Видно это тема очень узкая и экзотическая и ей мало кто интересовался.

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

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

Самый примитивный пример.
Написал в коде метода TLAstTrim.send(), что вызов метода TLAstTrim.send() может встречаться в любом блоке, но только после вызова методов Tysh.reply(int) или Uydf.rev(double), и компилятор возьмет это на контроль.
Средствами С++ такой контроль, как я понимаю, сделать невозможно или крайне геморно

Цитата Исмаил Прокопенко @ 31.07.16, 17:04

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

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

Добавлено 31.07.16, 19:56

Цитата Исмаил Прокопенко @ 31.07.16, 17:04

Средствами С++ такой контроль, как я понимаю, сделать невозможно или крайне геморно

Безбожно легко. Найдёшь несинтестический пример, когда подобное нужно, любой третьекурсник тебе за пять минут код напишет.

Цитата Исмаил Прокопенко @ 31.07.16, 17:04

Кроме предположений "может ЛИСП?" и препроцессора m4 в рунете мне ничего не посоветовали.

Предложу немножко Perl'а

#!/usr/bin/perl
 
$Loc = 1;
$Code = "print \"\$Loc\\n\"; exit if (\$Loc>3); \$Loc++; eval \$Code;";
eval $Code;

Саму модификацию кода не показывал. Показывал как код вызывает на выполнение сам себя четыре раза. Если фантазии для модификации в процессе вызовов хватит - нет преграды патриотам.

Цитата Исмаил Прокопенко @ 29.07.16, 19:49

программа на котором могла бы в COMPILE TIME

А, сорри, неусмотрел условие. Если на С/C++, то теоретически проще пареной репы:

1) Пишется программа-парсер, которая по каким-то условиям может изменять исходный C/C++ код
2) Компилируется и линкуется в исполняемый модуль
3) Далее пишется элементарный пакетный файл сборки

* вызывается парсер из п.2 который обрабатывает свой же код
* обработанный код компилируется и линкуется, заменяя себя же (программу парсер из п.2)

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

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

Сейчас компиляторы "ловят" в лучшем случае синтаксические ошибки и некоторые "сомнительные места".
А с предлагаемой мной парадигмой/идиомой программа будет обнаруживать не только логические ошибки в себе, но даже ИДЕОЛОГИЧЕСКИЕ.

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


Что компилятор должен состоять из двух частей:
1) Фиксированная ("традиционная") часть, которую пользователь менять не может
2) "Размазанная" по всему коду создаваемой программы часть, которую пишет пользователь.

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

Мне на стек овер флов ру посоветовали присмотреться в языку Nemerle.
Кто-нибудь на нем кодил?
На нем реально сделать то, что мне нужно?

Исмаил Прокопенко, бери пример с разработчиков Qt - напиши свой moc++ и не парься.

Roslyn ?

D вполне умеет подобное.