Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 38
бедный человек, которому придется использовать это, аст это один из способов представления программы для комплиятора/интерпретатора, для человека воспринимать программу как дерево выражений не естественно, максимум на очень большом приближении
предполагаю, что здесь педагогическая профдеформация привела к такому оригинальному решению
Несколько поколений действительно профессиональных людей, принесших примерно все идеи, которые используются сейчас, в разработку, программировавшие на LISP и его потомках — вышли из чата.
Иногда лучше жевать, чем говорить.
Редактируется не дерево непосредственно, оно представлено на рисунках для примера, а результат его визуализации на экране, об этом сказано. Фактически видится код но по существу внутри идёт работа с АСД, которое уже затем связано с компилятором-интерпретатором на уровне промежуточного представления. То есть это, можно сказать, syntax-free язык программирования, ведомый IDE. Можно редактировать как обычный текст, представить в виде блок-схемы, вынести отдельно комментарии, дать ссылки. Но само АСД, формирующее скелет кода не меняется, например, при изменении комментариев, документации, это уходит в атрибуты. Изменение же алгоритма проявляется в изменении узлов и взаимосвязи между ними.
если пользователь все равно редактирует представление в виде кода, зачем вообще ему аст? чтобы код без этой ide нельзя было прочитать нигде?
все таки программный код первичнее, его и без специальных инструментов прочитать можно и отредактировать в любом редакторе
а тут получается из исходного кода делается некий документ аля docx
это уже вопрос философско-религиозного толка. Мы просто привыкли из детства что текстовый редактор - это перевод строки и возврат каретки по нажатию Энтер. То есть мы можем взять любой алфавитно-цифровой терминал из 70-х и накодить что угодно даже сейчас. Речь о том что действительно, язык программирования встраивается в IDE и является неотъемлемой его частью, это как данность. Да действительно можно сгенерировать обычный текст по обходу АСД и даже похожий на программу для редактирования класическими редакторами в XML/JSON/txt/HTML/md/CSV/ итд итп но зачем. Ведь даже простейший редактор сейчас это нечто из обработки событий от клавиатуры, "прерываний от мыши", вывод в OpenGL/Direct/Vulkan/Qt что угодно - по сложности это уже давно не Volkov Commander в 64 кБ и висящий резидентно на int21/int10. Это уже целая подсистема ввода вывода. И уже без разницы что к ней будет плагин-довесок для визуализации АСД соизмеримой сложности (!). То есть это просто защита принципа редактора ASCII нежели принципа редактора результатов визуализации уже непосредственного представления программы.
В этом случае нет input->txt<->AST<->txt->output а есть только (input,output)<->AST->txt (экран)
попробуйте навайбкодить макет редактора, на словах это может и выглядит, как отличное решение, но оно абстрактное в вакууме, примеры рассмотрены на сильно упрощенном коде, хотя при этом 4 строчки цикла фор кажутся наоборот более сложным в восприятии, чем в текстовом виде
Так в этом и дело что визуальное восприятие - это то практически для чего и создавались языки программирования. Чтобы все логические связи, абстракции влезли в "контекстное окно человека", который одновременно может держать 10-15 сущностей не более, причём это зависит от настроения, обстановки, срочности, дедлайнов и прочих неприятностей. Поэтому разрабатывается для языка его дополнительное окружение - либы, хабы, примеры, копипасты, форумы. Здесь же это расширяется до возможности любой визуализации по желанию пользователя, хоть с begin-end, хоть с {} хоть с табуляциями, от этого сам алгоритм не меняется. Для полной наглядности нарисовал картинку ниже.
Визуальное представление на любой вкус и цвет определяемый пользователем
В АСД вывод запрограммирован с использованием атрибутов и правил - в синих лейблах первое - строка, второе - столбец. 0,1,2,3 внутри операторов - последовательность выполнения, у break может быть сразу несколько циклов в подчинении, поэтому можно выходить из вложенных без флагов и goto. Это всё затем представляется согласно правил синтаксиса, которые невозможно нарушить - они захардкожены в IDE и лишь отображают сам алгоритм, программу а не его текстовое исполнение. Те же скобки - это границы между ветвями дерева, они же begin-end, ставятся по месту в момент обхода первой и конечной ветвей. Равно как и скобки - они автоматом следуют из АСД при нахождении узла "Цикл" сразу отображается открывающая и закрывающая затем внутрь вставляется то что получается в ходе обхода узлов по ссылкам 0, 2 и 3. Внутрь скобок с любым разделителем, хоть ; хоть | или # вставляются уже другие ветви дерева. То есть то что на экране - это результат работы алгоритма восстановления дерева а не текст программы. Там же слежение за типами данных - они не отображаются на экране но они есть. Как в САПР электроники - показать скрытые выводы, атрибуты компонента итд.
В сети уже давно валяется статья на rsdn по этому поводу, и даже в jetbrains была реализована такая штука, здесь есть автор, его канал на Ютубе соло на .net.
Есть ссылка на википедии - JetBrains MPS - Wikipedia
Я не верю, что автор статьи не читал этот материал за авторстовм @mezastel - Языково-ориентированное программирование: следующая парадигма. Можно было и ссылку приложить @TimurZhoraev
Зумеры изобрели LISP.
Этому поделию больше 15 лет. Оно уже не воскреснет, хватит его раскапывать и пытаться расшевеливать. Там буквально всё сделано неправильно.
Это продолжение ЛИСП-машины но на несколько новом уровне. Там основная проблема, что текст на экране должен соответствовать некоторому мета-языку который напрямую генерирует для имеющихся компиляторов. И делать это напрямую в реалтайме. То есть тогда в принципе это был очень большой объём, так как необходимо было фактически полностью переделать под асинхронные запросы С компилятор, включая обвес под мультипроцессорную работу, очереди, взаимдоействие с ОС. Фактически gcc который висит на localhost и работает как сервер, причём что-то компилирует как JIT, что-то в код, что то подключает и кеширует. Сейчас же это стало возможным попытаться сделать как коцепт вайбкодингом, благо полно библиотек для Питона, С, да и сами компиляторы уже могут генерить АСД в нужном виде чтобы выкинуть фронтенд компилятора напрямую в IDE а бекенд распараллелить и отправить в фон, плюс отпадает необходимость git или контейнеров, так как версии и всё остальное отслеживаются на уровне сервисов/идентификаторов самой IDE и уже не применимо к файлам-тексту (!) а непосредственно к языку предметной области: данные, функции, конечные автоматы, вплоть до элементов HDL-языков и редакторов схемотехники с печатными платами (дополнить "код" диаграммками а-ля Матлаб-Симулинк).
Любое решение, завязанное на IDE (и любой иной инструментарий, кроме консольных пайпов) — мертворожденное говно, которое никогда не взлетит вне очень узкого круга академических структур.
Wolfram Mathematica — блистательнейший инструмент, опередивший время на десятилетия. Требовал своего IDE. Остался игрушкой для продвинутых студентов.
Про Матлаб вообще говорить смешно: сделай они импорт/экспорт в текстовые форматы двадцать пять лет назад — уже покорили бы мир.
Список бесконечен.
текст на экране должен соответствовать некоторому мета-языку который напрямую генерирует для имеющихся компиляторов
Я уже раз триста, по-моему, вам сказал: мета-язык никому не должен ничего генерировать, чтобы генерировать — обычные компиляторы подойдут, они и так (нормальные, современные, речь не идет, разумеется, про наколеночные поделия типа го/раста и про мастодонтов типа питона/плюсов) работают с AST.
Ну отвлекитесь вы от витания в облаках, посмотрите, что люди уже сделали, даже ваш собеседник вон приложился: https://hexdocs.pm/metastatic/
Ну отвлекитесь вы от витания в облаках, посмотрите, что люди уже сделали, даже ваш собеседник вон приложился: https://hexdocs.pm/metastatic/
Там на странице невозможно ничего изменить, а значит, это ещё не активный текстовый редактор. Это к тому что можно было для рендера сгенерировать небольшой JS-апп, который бы позволял работать с кусочком этой концепции. Пока я вижу фикс-синтаксис который не определяется пользователем, это не то. В системе не должно быть даташита на язык чтобы его учить, он должен давать подсказки из системы. BASIC from scratch. Всё что нужно - это курсор по центру. Пользователь пишет "пгркгпанрамывавыа" и система знает что ему необходимо, при этом, это синтаксически правильная конструкция и может быть скомпилирована. Забыть слово парсер, в АСД не нужно ничего делать из текста - оно готовое.
Основной язык, мета-язык, байткод что угодно - это генерация по АСД, machine generated no not edit. Максимум парсер это для библиотек рэгэкспов чтобы упростить мелкие задачи с текстом. То есть вводятся пользователем конструкции АСД синтаксически правильные с точки зрения того если бы это был текст. Затем синтаксически правильный текст отображается на экране. И далее рендерятся как угодно. Вместо <-, :=, =, присвоить, пробел - что угодно. Там не нужно учить "для того чтобы сделать вот это, надо записать вот это именно так или это будет ошибкой". Ошибок синтаксиса в принципе нет никаких, есть только неправильная последовательность ввода, которая купируется протоколом. Это как в диалоге кнопки "да", "нет", но пользователь жмёт где-то в другом месте "отмена", которая ему показалась.
Maxima, Mathematica, Derive, Maple итд это системы символьных вычислений с выводом формул. Там всё АСД это дроби и интегралы для удобного копипаста. Матлаб вполне себе генерирует текстовые файлы для HRF, только в этом нет необходимости, всё что нужно классически - в m файлы. Никто же сейчас не правит нетлисты вручную в редакторах схемотехники.
Ещё раз - метаязык в предлагаемой концепции, да и любой язык - это семантика отображения АСД на экране. Там текст чтобы его прочитать и редактировать буквы, это не программа! Программа - это АСД, а текст, картинка, смайлик - результат обхода этого дерева. Программирование - это взаимодействие с IDE на протокольном уровне а не вбивание синтаксиса. Как в Симулинке перетаскивать значки на экране и чертить линии подключая к портам, это тоже протокол. Просто сейчас производительности стало достаточно чтобы асинхронно шуршать и рендерить часть кода как угодно, распорстраняя изменения на остальное АСД в большом проекте без лагов и зависаний, по сути проблема таких ide сугубо техническая и архитектурная, чтобы пользователь не видел лаги между хоткеями и откликом.
По поводу привязки к IDE это всё равно что привязка к ОС, фреймворкам, библиотекам, инструментам, компиляторам, учить тонны описания Cmake, git, docker помимо самого языка, тонны зависимостей в файловой системе чтобы не попутать имена, вспомогательные шелл-скрипты, плюсом навернуть зависимости от аппаратуры (особенно для ИИ), облачных сервисов, хотелок-апдейтов. Так что всё уже давным давно вышло за рамки простых текстовых редакторов, для сложных языков рефакторинг ими это целая боль плагинами. Без IDE и облачных сервисов для ИИ уже не обойтись от слова совсем, содержать серверную у себя на ноуте - ну такое себе занятие.
Маленько не то. Там опять-таки заостряется внимание на коде. Здесь нет синтаксиса, каких-то правил которые необходимо запомнить, шаблонов, среда предоставляет эти инструменты по умолчанию. Язык программирования становится просто протколом обмена с IDE! Это совершенно иной подход. Фактически сейчас он имеется в виде хоткеев на рудиментарном уровне когда в VSCode том же или любой другой в командной строке есть факториал. От комбинаций команд. Взять любую работу, даже профи и посмотреть что там делается кейлоггером. Ctrl+C Ctrl+V по моему на первом месте, далее F5 компилировать F6 по шагам. Но это опять таки всё для текста. Здесь же предлагается это делать непосредственно для программных сущностей, избегая текста как такового, который необходим только компилятору. Редактируется АСД содержащее всё необходимое для безопасного рефакторинга. Там невозможно перепутать имена так как они жёстко привязаны как атрибуты узлов. Переменные можно хоть с пробелами хоть картинки а алгоритмы визуализировать и на экране, пением в динамик, арома-генератором, уровнем насыщенности кофе причём АСД в этом случае полностью адаптировано под такой вайб с максимально возможной плотностью информации относительно контекстного окна.
Еще в 80ых на платформе MSX, которые массово закупил СССР у Японии в виде КУВТ, был такой софт Информатика 87 (потом 89). Там как раз было редактирование на основе АСД. Сам язык был вроде некоего 'русского паскаля'. Школьники не могли вносить текст произвольно, кроме разве что названий функций и переменных.
Да как раз застолблённые редакторы с фиксированным синтаксисом появились именно тогда. Вообще говоря одна из разновидностей - это банальный редактор электрических схем или тот же Derive/Mathcad, они также имеют внутреннее представление и визуализацию. Здесь же речь идёт о расширении использования АСД в том числе и для манипуляций с кодом - рефакторинг, локальные тесты, версии итд. Чтобы не прибегать к сторонним инструментам. Фактически там и макросы и скрипты и всё остальное на одном и том же универсальном языке. Теги: syntax driven editor, active text editor итд. Не взлетело потому что перебирать АСД теми мощностями было тяжеловато а для компиляторов/трансляторов/интерпретаторов была уже сформированная платформа плюс гарантия того что 100500 текстовых редакторов смогут открыть одно и тоже. Тогда всё-таки маловато было открытого софта, в основном пропиретарка. В итоге закончилось подсветкой синтаксиса. Умный же рефакторинг требует углублённого погружения. Под спойлером - пример теста где просто так уже Ctrl+F с поиском и заменой не работает, даже с ИИ-помощником, особенно когда объём перебора для рефактора на уровне 10 тыс строк. То есть замена должна уметь:
- парсить вложенные комментарии
- выяснять тип доступа . или -> по указателю
- typedef Myname и объекты Myname
- менять или не менять Myname в комментариях
- наличие одинаковых имён в макросах
....
То есть это уже необходимость некой культуры программирования в части именования сущностей чтобы "тупой рефактор" не вынес переменные. Поэтому предлагаемая среда собственно изолирует благодаря АСД необходимые имена которые точно могут быть и точечно изменены, включая контекст с ними связанный. То есть работа с текстом - это практически реалтайм парсинг, а если язык сложный и синтаксически насыщенный. Причём это делается в фоне практически до 50% загрузки CPU с каждым чихом и изменением.
Рефактор-тест
#ifndef TEST_REFACTOR_H
#define TEST_REFACTOR_H
#include <stdlib.h> // for malloc/free
typedef struct {
int old_member;
float other;
} MyStruct;
// Second struct with random ASCII text
typedef struct {
char* random_text;
int length;
double value;
} MyStruct2;
// Third struct with embedded MyStruct and array of string pointers
typedef struct {
MyStruct embedded;
char* strings[6]; // array of 6 pointers to char
int num_strings; // actual number of strings used
} MyStruct3;
/**
*
* multi string comment
*/
// Another struct with nested array
struct Complex {
int id;
char name[32];
MyStruct nested;
MyStruct2* extra; // pointer to MyStruct2
struct Complex* next;
};
// Enumeration
enum Color { RED, GREEN, BLUE };
// Macro definitions
#define MAX(a,b) ((a) > (b) ? (a) : (b))
#define ARRAY_SIZE 10/*
multi string comment 2
*/
...
...
// Global variable
...
// Process a struct
void process_struct(MyStruct* s) {
if (s) {
s->old_member *= 2;
s->other = 3.14f;
}
}
// Function that calls another function
void call_chain(void) {
printf("Starting call chain\n");
helper_func(5);
int result = compute_sum(10, 20);
printf("Sum result: %d\n", result);
MyStruct ms = { .old_member = 42, .other = 2.71f };
process_struct(&ms);
printf("Processed struct member: %d\n", ms.old_member);
// Use macro
int max = MAX(result, ms.old_member);
printf("Max: %d\n", max);
// Macro with string
DEBUG_PRINT("Call chain completed");
}
// Manipulate Complex struct with malloc/free
void manipulate_complex(struct Complex* c) {
if (!c) return;
// Allocate MyStruct2
MyStruct2* ms2 = (MyStruct2*)malloc(sizeof(MyStruct2));
if (!ms2) {
printf("malloc failed\n");
return;
}
// Assign random ASCII text
const char* random_text = "Random ASCII: ~!@#$%^&*()_+`1234567890-=[]\\{}|;':\",./<>?";
ms2->random_text = strdup(random_text); // allocate copy
ms2->length = strlen(random_text);
ms2->value = 3.14159;
c->extra = ms2;
// Print the text
printf("MyStruct2 text: %s\n", c->extra->random_text);
printf("Length: %d, Value: %f\n", c->extra->length, c->extra->value);
// Free after use (just for demonstration, we'll free later)
}
// Demonstrate MyStruct3 with example arrays of different size q
void demonstrate_mystruct3(void) {
// Create character arrays of different sizes initialized with "abcd" variations
char str4[] = "abcd"; // size 5 (including null)
char str5[] = "abcde"; // size 6
char str6[] = "abcdef"; // size 7
char str7[] = "abcdefg"; // size 8
char str8[] = "abcdefgh"; // size 9
char str9[] = "abcdefghi"; // size 10
// Initialize MyStruct3 instance
MyStruct3 ms3 = {
.embedded = { .old_member = 99, .other = 2.5f },
.strings = { str4, str5, str6, str7, str8, str9 },
.num_strings = 6
};
printf("MyStruct3 demonstration:\n");
printf("Embedded struct: old_member=%d, other=%.2f\n",
ms3.embedded.old_member, ms3.embedded.other);
printf("Number of strings: %d\n", ms3.num_strings);
for (int i = 0; i < ms3.num_strings; i++) {
printf(" strings[%d] = '%s' (length %zu)\n",
i, ms3.strings[i], strlen(ms3.strings[i]));
}
}
int main() {
MyStruct s;
s.old_member = 42;
s.other = 1.0f;
// Call various functions
helper_func(3);
loop_example();
conditional_example(75);
call_chain();
// Use struct and enum
struct Complex comp;
comp.id = 1;
strcpy(comp.name, "Test");
comp.nested = s;
comp.next = NULL;
comp.extra = NULL; // initially NULL
// Manipulate complex with malloc/free
manipulate_complex(&comp);
...
// Array of pointers to char strings
const char* strings[] = {
"Hello",
"World",
"Test",
"Example",
"String",
"Array"
};
int num_strings = sizeof(strings) / sizeof(strings[0]);
for (int i = 0; i < num_strings; i++) {
printf("String %d: %s\n", i, strings[i]);
}
// Demonstrate MyStruct3
demonstrate_mystruct3();
return s.old_member;
}
Не взлетит. Человеку удобно работать с текстом программы именно как с текстом. Я оценил, что вы привели Basic-редактор от ZX Spectrum в качестве примера, но писать в нём код было пипец неудобно по нынешним меркам: ни возможности работать с блоками текста, нет поиска, переименовать переменную - боль. Современные IDE делают всё правильно: это текстовые редакторы, которые строят AST на основе введённого текста и, в функциональном смысле, накладывают AST поверх текста: подсветка синтаксиса, рефакторинг, ранее обнаружение ошибок.
Относительно недавно были вот такая статья и ещё вот такая, под ними обеими много комментариев, которые я рекомендую.
Так к этому примерно всё и продвигается, что теперь не текст первичен а именно AST, а текст на экране - результат его визуализации. То есть текстовый редактор наоборот. Никто же не читает страницы в браузере в HTML, то что мы видим - результат обработки. Также и здесь, просто с деревом самой IDE работать гораздо проще чем каждый раз затягивать тысячи файлов в дублирующую базу данных, которая по сути precompiled headers. IDE делает двойную работу за первичный обработчик компилятора в виде лексера-парсера. Вот и предлагается разу решать задачу на уровне GIMPLE/GENERIC, существенно упрощая компилятор, так как больше не требуется синтаксический анализ текста - он изначально приведён в необходимый вид. То что видим на экране - это результат визуализации АСД а не само АСД как может показаться изначально. По поводу Спектрума - по нынешним меркам конечно это примитив, но и было это полвека назад, а вот сама идея активного текстового редактора с помощником позволяющим писать сразу без ошибок это да. Текста в данной концепции больше нет - это просто атрибуты к узлам АСД. По фиксированным узлам гораздо проще рефакторить и делать что угодно, то есть не надо каждый раз согласовывать синтаксис обычного текста и правила его использования.
Никто же не читает страницы в браузере в HTML, то что мы видим - результат обработки.
Ключевое слово тут: "читает". А код ещё писать и редактировать надо. Вот вы мне HTML, а я вам другой пример приведу: markdown. Я сейчас тексты пишу в Obsidian, и это просто праздник какой-то: без мышки, без тучи хоткеев я могу писать текст и делать разметку, перенося блоки как мне угодно, не боясь сломать иерархию (потому что её нет), и текстовый поиск работает.
Я хотел бы иметь возможность в процессе набора или исправления кода временно ломать AST, и если редактор не будет позволять мне это делать, я буду злиться. Я с большим трудом представляю себе редактор в виде визуализатора AST.
не боясь сломать иерархию [в маркдауне] (потому что её нет)
Дайте угадаю: вы никогда не писали парсеры маркдауна. Если бы иерархии не было — это было бы плёвое дело.
Я с большим трудом представляю себе редактор в виде визуализатора AST.
Это милый каминг-аут, но какое отношение он имеет к объективной реальности? Попробуйте угадать, как работает форматтер кода во взрослых языках (не в наколеночных поделочках типа гошечки). Ага, через преобразование код → AST → код. Спасибо Джону Хьюзу (автору property-based тестирования) и Филипу Уодлеру, формализовавшему и улучшившему алгоритм, — любая макака теперь может сделать это а) правильно и б) однозначно.
Не проходящие валидатор ноды дерева остаются специальными «текстовыми» нодами вплоть до того момента, как AST станет снова приемлемым.
Людям этот подход известен более семидесяти лет, алгоритм Хьюза старше тридцати, формализации Уодлера — двадцать с хвостиком.
Но, как говаривал Публий Сир, «In nil sapiendo vita iucundissima est». В английский фраза проникла как «Ignorance is bliss».
Короче, невеждам жить гораздо интереснее: каждый день приносит что-то новое.
Программа изначально хранится в виде АСД с атрибутами, отражающими расположение на экране, комментариями, ссылками, UUID, хешами, что угодно. В двоичном или текстовом виде для чтения человеком, любое дерево/клубок (с обратными связями) можно втолкнуть в JSON, базу данных что угодно. Файловая система отсутствует как класс, работа ведётся непосредственно на языке предметной области - данные, функции, пространства имён. Узлами дерева являются дескрипторами данных и методов. Явный пример - вывод gcc с флажком, например, как в спойлере. IDE открывает уже готовое дерево, его не нужно компилировать в части синтаксического и лексического анализа! Визуальные средства же предоставляют вывод хоть текстом, хоть линиями хоть ещё чем на усмотрение пользователя. Вся сложность - как раз в визуализации и организации грубо говоря "прерываний от клавиатуры", надеюсь это удастся напромптить. Чтобы визуализировать часть дерева из огромного проекта и обновлять ссылки.
Пример фиксированного АСД с узлами
AST_DUMP_FLAG = -fdump-tree-original-raw
CFLAGS = $(MCU) \
-Og \
-fmessage-length=0 \
...
-std=gnu11 \
$(AST_DUMP_FLAG)
Вывод:
;; Function __sputc_r (null)
;; enabled by -tree-original
@1 bind_expr type: @2 body: @3
@2 void_type name: @4 algn: 8
@3 statement_list 0 : @5 1 : @6
@4 type_decl name: @7 type: @2
@5 debug_begin_stmt type: @2
@6 cond_expr type: @2 op 0: @8 op 1: @9
op 2: @10
@7 identifier_node strg: void lngt: 4
@8 truth_orif_expr type: @11 op 0: @12 op 1: @13
@9 statement_list 0 : @14 1 : @15
@10 statement_list 0 : @16 1 : @17
@11 integer_type name: @18 size: @19 algn: 32
prec: 32 sign: signed min : @20
max : @21
@12 ge_expr type: @11 op 0: @22 op 1: @23
@13 truth_andif_expr type: @11 op 0: @24 op 1: @25
@14 debug_begin_stmt type: @2
@15 return_expr type: @2 expr: @26
@16 debug_begin_stmt type: @2
@17 return_expr type: @2 expr: @27
@18 type_decl name: @28 type: @11
@19 integer_cst type: @29 int: 32
@20 integer_cst type: @11 int: -2147483648
@21 integer_cst type: @11 int: 2147483647
@22 predecrement_expr type: @11 op 0: @30 op 1: @31
@23 integer_cst type: @11 int: 0
@24 ge_expr type: @11 op 0: @32 op 1: @33
@25 ne_expr type: @11 op 0: @34 op 1: @35
@26 modify_expr type: @11 op 0: @36 op 1: @37
@27 modify_expr type: @11 op 0: @36 op 1: @38
@28 identifier_node strg: int lngt: 3
В этом примере уже практически готовое АСД для визуализации на экран как код некоторого "С" но уже заранее синтаксически выверенного самой IDE.
Зачем вы мне-то это рассказываете?
Если бы на дворе был 1958-й год, это был бы прям прорыв. Сегодня — это очень кривая наколеночная и тупиковая реализация первых интерпретаторов LISP,
Программа изначально хранится в виде АСД с атрибутами […]
Да ну? А как я без инструментария буду PR мёрджить, или просто для общего развития чужой код рассматривать?
любое дерево/клубок (с обратными связями) можно втолкнуть в JSON, базу данных что угодно
Это и близко не так.
IDE открывает уже готовое дерево, его не нужно компилировать в части синтаксического и лексического анализа!
Обалдеть, дайте две. А зачем? Выиграть 100μs?
Пример фиксированного АСД с узлами […]
Прям жаль вас расстраивать, но это не дерево.
заранее синтаксически выверенного самой IDE
А если у меня нет IDE?
Так любая IDE и есть сегодня интерпретатор того что читается из *.c и *.h. Речь о том чтобы не городить отдельную базу данных предварительного парсинга а непосредственно использовать АСД в качестве кода в дальнейшем идущим на компилятор или интерпретатор без синтаксиса. Фактически это уже готовый код для виртуальной машины.
А как я без инструментария буду
Так для этого и дана IDE. В данном случае она неотделима от реализации АСД и правил визуализации, там же инструменты для работы не только с кодом но и с версиями, тестами, флажками компилятора (но уже для практически LLVM) итд
Обалдеть, дайте две. А зачем? Выиграть 100μs?
Визуальное представление, удобство работы без ошибок, компиляция только того что нужно - бесценно по времени. А если это сотня заголовочников и куча реализации? Зачем для helloworld компилировать всю либу когда достаточно вытащить только те функции по цепочке которые необходимо. Мало того изменив что то в /**/ начинает перекомпилироваться весь мир, так как компилятор не знает что это изменение этикетки а не изменение кода. Так что ускорение может быть весьма существенным, плюс дерево - готовая виртуальная машина для моделирования, например, быстро налету в интерпретации проверить локальный for что он там сделает со строкой.
Прям жаль вас расстраивать, но это не дерево.
Но оно на то и абстрактное. По факту конечно это "клубок" - в нём дочерние узлы могут иметь ссылки на себя и предыдущие. Там и конечные автоматы и всевозможные таблицы-графы переходов/состояний. Это технические моменты реализации.
А если у меня нет IDE?
Тогда вручную, текстом, как в конце 60-х. А если ещё на телетайпе с рулоном перфорированной бумаги то можно видеть и отслеживать все diff-ы. Нет необходимости в 21м веке привязываться к методам ввода-вывода, хранения полувековой давности, просто потому что к этому привыкли или когда-то учили. Тем более спецификация на IDE и АСД может быть вполне открытой, даже в виде скиллов и промптов как ТЗ для её генерации.
Упустил важный момент. Модель код → AST → код чуточку более общая
ввод->код->AST->код->вывод. Всего лишь нужно (ввод, вывод) <-> AST -> код, что собственно и предлагается.
Иными словами код - это результат обработки синтаксического дерева на экране, то что нужно для чтения, понимания человеком, а само дерево двоичное/текстовое, хранится где-то там в памяти и формируется... прерываниями от клавиатуры, мыши или эвентами от ИИ-агента, хоть прилетающие по UART. То есть синтаксис языка это не то что принято видеть как просто редактируемый текст курсором а фактически команды IDE для его формирования, хоткеи можно сказать и клики мышью. На экране уже виднеется результат обработки дерева согласно правилам визуализации. Там хоть {} хоть begin-end - что угодно выставить в настройках.
То есть если Вы набираете a+b - создаётся узел a, хоткей "+" даёт команду IDE создать новый узел включающий "a", затем нажимая "b" он даёт ссылки от "+" к "a" и "b", одновременно в диалоге говоря что этот + есть + между целым и целым, предлагая к диалогу о типах данных для a и b если они ранее не определены. Помимо этого, быть может, он визуализирует а как 
, b как
, значок + оформит как 
на экране, потому как это двоичное ИЛИ. То есть синтаксис это интерактив между пользователем и IDE, это не железобетонно вбитые конструкции. Равно как я могу переопределить операторы смайликами просто потому что just for fun. В этой концепции нет места синтаксиса как таковому - он уходит в правила формирования и визуализации АСТ в ответ на действия пользователя и становится просто протоколом.
В этом ключевой момент - Вы редактируете текст! А не код ) и даже не программу. Поэтому если он является узлом АСД с дополнительным атрибутом координат на экране, приведённых к координатам программного пространства (полный диапазон int32 думаю достаточен, там экранов текста от Земли до Луны), в отличие от нелинейного float int более пригоден для этого. Когда Вы вводите текст - происходит изменение атрибута узла или вида узла. Например, имя переменной это атрибут к типу, когда вводите a + b в момент нажатия + даётся команда IDE. То есть +-*/ это не операторы в обычном понимании а фактически команда IDE на его перегрузку в целевом языке программирования. Он сам знает уже априори к какому типу узла он применён, где находится "operator+" и определён ли он в базе данных. Тоже самое с фрагментами и черновиками, я их назвал скетч-кодом, это тоже есть в предлагаемой концепции. Иерархия - это тоже самое дерево только с атрибутом типов данных. Самое главное - можно разделять/объединять классы как раз не боясь сломать их структуру, так как то что Вы видите на экране - это просто отображение АСД, которое невозможно сломать в принципе какой-либо ошибкой в тексте. Текст это просто атрибут к узлу который при обходе кусочка АСД, влезающего в экран, летит в видеокарту не более того. То есть Вы набираете не текст программы, грубо говоря, а фактически даёте инструкции IDE для её построения, это ключевой аспект.
Трудно сказать, если бы победила иная парадигма программирования, как бы мы сейчас программированли и как бы сейчас выглядели IDE. Работа конечно прорделана автором колосальная. Идеи интересные. Реализовать их просто сложно, ибо требуется: а) иной подход к пониманию процесса написания программ, а многим просто лениво выбираться из того что привык б) идея опоздала, ибо сейчас автивно идет очень массовый переход на парадигму метапрограммирования через вайб-кодинг, а значит скоро вообще будет мало людей. разбирающихся в том, чего "наваял" ИИ
Да, до полномасштабного развёртывания ИИ конечно же это было актуальным, поэтому пришлось пересмотреть в его сторону, этому как раз и посвящены заключительные слайды. Но тут есть и огромный плюс - IDE с АСД предложит гораздо больше возможностей так как генерации LLM может вести сразу к этому дереву, без текстового представления кода в классическом виде (он может быть текстовый но это опкоды виртуальной машины АСД). Компилятор и интерпретатор на промежуточном языке, например, Python AST/ C или даже LLVM становятся некими модулями для практически любой исполняемой последовательности. Контекстное окно уже не для текста а для.. алгоритма и данных, позволяя существенно экономить токены. Плюс различные diff-ы в концепции без файловой системы для непосредственной работы на языке предметной области, прямые атрибтуы в виде среды исполнения также упрощают модель взаимодействия без пыток флажками git/docker. LLM генерирует как текст так и двоичный формат и ввод становится также комплексным - часть токенов текст часть двоичные после векторизации. По крайней мере LLM уже готовят к этому. Да и разбирать код, который IDE причесала из АСД гораздо приятнее чем пробираться через дебри синтаксиса и комментариев.
Ну, есть у меня смутные сомнения в особой полезности такого подходя даже для LLM Ну ,разве что его очень конкретно доучат под такого рода восприятие исходного кода. Но нужно ли это, если само по себ еобучение ведется на корпусе кода, который так или иначе строится по классической текстовой схеме, а не АСД. Наверное можно если поднатужится и такое решение внедрить, но вот нужно ли такое , это тоже очень большой вопрос
Здесь немножко иная концепция, повторюсь (ответил выше с примером) - текст есть результат визуализации АСД программы а не сама программа. Если пользователю удобно видеть алгоритм как Python - пожалуйста, как Go - тоже, хоть LISP или C++. В этом подходе обучение синтаксису бессмысленно, его просто нет как такового, мало того он может настраиваться пользователем под собственные нужды. Главным является изучение методов промежуточного представления компиляторов. Для GCC это GIMPLE/GENERIC (причём одинаковый что для C/C++, Pascal, Fortran да хоть Algol 68) для Python это Python AST. То как алгоритм представлять на экране и с каким синтаксисом - это дело вкуса. Комментарии же вообще можно задавать координатным способом в любом удобном месте а не только напротив строки. Причём компиляция не зависит от комментариев, заметок, ссылок PDF-ок, Datasheet-ов, картинок - структура кода уже известна для отправки на кодогенератор. В этом случае полностью отпадает огромный и прожорливый пласт компилятора в виде лексического и синтаксического анализа. Для реализации конечно первичной среды по конвертации C->AST пришлось мне посмотреть и на основе Bison-Flex, CLang, кастомные парсеры, надо остановиться на чём-то одном. В этом случае среда будет self-hosted, то есть IDE может компилировать саму себя.
его очень конкретно доучат под такого рода восприятие исходного кода
Кого доучат? Вы в курсе про существование RAG? А про MCP-сервера? Знаете, зачем это всё нужно? — Сюрприз: пихать код как есть в LLM не только крайне неэффективно, но и невозможно; средние и большие проекты не лезут в контекстное окно.
Поэтому в MCP-протоколе определены специальные инструментальные вызовы (tools), к которым и обращается этот продвинутый T9.
И пока люди восторгаются всякими клодами и курсорами, самодельный MCP-сервер, построенный на чистом AST, — даёт гигантский гандикап, как автор одного из таких инструментов говорю. Мой даже открыт в опенсорс, в отличие от большинства.
Второй по эффективности (со значительным, но не прям гигантским отрывом) — MCP на tree-sitter (который строит некий аналог AST для бедных).
На заключительных слайдах есть примеры и про MCP/RAG. Речь идёт про токенизацию двоичного кода АСД и генерацию с использованием LLM непосредственно байткода виртуальной машины, которую "понимает" IDE. В этом случае синтаксис сжимается ещё больше и модель может иметь дело непосредственно с "байткодом" а не с синтаксисом, который нужен только человеку для восприятия. Это уже свойства моделей, но думаю появятся инструменты для двоичного ввода-вывода, просто это проблема стандартизации, так как отрасль новая, используется то что есть, не все конечно потянут претренинг на 3 месяца с арендой 10 тыс GPU, там одно обучение под лимон баксов. Поэтому на начальном этапе будет какое-то промежуточное широко распространённое представление байткода. В том же C/Python но предельно сжатое, только формальное описание без излишеств, так как датасетов на этом языке предельно много. Разработка агента это отдельное направление но так как за платформу выбран K&R C с довеском образца 23 года, то думаю он вполне сгодится как intermediate для AST. Тут главное как его визуализировать и по каким правилам. Уверен что из не так много если выбросить шелуху придуманную только для удобства ЯП в виде синтаксического сахара и парадигм. Для агентного программирования это не нужно.
Речь идёт про токенизацию двоичного кода АСД и генерацию с использованием LLM непосредственно байткода виртуальной машины, которую "понимает" IDE.
Я знаю все слова в этом предложении, но вы их мастерски расставили таким образом, что даже каждая пара соседей уже лишена какого бы то ни было смысла.
Вы мне очень напоминаете тех людей, которые в 90-е годы стояли в коридорах техничеких ВУЗов с напечатанными на ротопринте книжечками «Доказательство Большой теоремы Ферма».
В данной области вам катастрофически не хватает образования, кругозора и опыта.
Это как концепция. Она проверяется эмбеддером BAAI/bge-m3, например, взяв облачный. Плюс часть можно ещё "скормить" Qdrant. Собственно навайбкодить скрипт для формирования векторов и косинусного сходства можно уже даже в ленте поисковика, так что опыт.. это уже сейчас поправимо. Вопрос только что это не человеческий язык а нечто напоминающее ассемблер. В этой части и должна быть модификация самих моделей и эмбеддеров. То есть это задача уровня их разработки а не применения.
Например, как сравнить вывод на Паскале и С с результатом в АСД с использованием LLM.
АСД Паскаля
Создаём PasProg.pas, обратите внимание на связку языка программирования и файловой системы в самом начале
unit PasProg; { Name must match the filename PasProg.pas }
interface
function ComputeSum(n: integer): integer;
implementation
function ComputeSum(n: integer): integer;
var
i, result: integer;
begin
result := 0;
for i := 1 to n do
result := (result + i) * 2 - 5;
ComputeSum := result;
end;
end.
устанавливаем fpc (с его генератором дерева, GCC не поддерживается уже) компилируем fpc -vp PasProg.pas
Вывод:
АСД Паскаля, похожее на JSON
after parsing ComputeSum(SmallInt):SmallInt;
(blockn, resultdef = $void = “untyped”, pos = (9,1), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 255 (statementn, resultdef = , pos = (10,14), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 255 (assignn, resultdef = $void = “untyped”, pos = (10,3), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2 (loadn, resultdef = SmallInt = “SmallInt”, pos = (10,3), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_write], cmplx = 1 nil symbol = RESULT ) (ordconstn, resultdef = SmallInt = “SmallInt”, pos = (10,13), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 0 value = 0 ) )
) (statementn, resultdef = , pos = (12,35), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 255 (forn, resultdef = $void = “untyped”, pos = (11,3), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 255 (loadn, resultdef = SmallInt = “SmallInt”, pos = (11,7), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_write], cmplx = 1 nil symbol = I ) (ordconstn, resultdef = SmallInt = “SmallInt”, pos = (11,12), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 0 value = 1 ) (loadn, resultdef = SmallInt = “SmallInt”, pos = (11,17), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 1 nil symbol = N ) (assignn, resultdef = $void = “untyped”, pos = (12,5), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 15 (loadn, resultdef = SmallInt = “SmallInt”, pos = (12,5), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_write], cmplx = 1 nil symbol = RESULT ) (typeconvn, resultdef = SmallInt = “SmallInt”, pos = (12,32), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 13, convtype = tc_int_2_int, convnodeflags = [] (subn, resultdef = LongInt = “LongInt”, pos = (12,32), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 12 (muln, resultdef = LongInt = “LongInt”, pos = (12,28), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 11 (addn, resultdef = LongInt = “LongInt”, pos = (12,15), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 5 (typeconvn, resultdef = LongInt = “LongInt”, pos = (12,16), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2, convtype = tc_int_2_int, convnodeflags = [] (loadn, resultdef = SmallInt = “SmallInt”, pos = (12,16), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 1 nil symbol = RESULT ) ) (typeconvn, resultdef = LongInt = “LongInt”, pos = (12,25), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 2, convtype = tc_int_2_int, convnodeflags = [] (loadn, resultdef = SmallInt = “SmallInt”, pos = (12,25), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 1 nil symbol = I ) ) ) (ordconstn, resultdef = LongInt = “LongInt”, pos = (12,30), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_explicit], cmplx = 0 value = 2 ) ) (ordconstn, resultdef = LongInt = “LongInt”, pos = (12,34), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_explicit], cmplx = 0 value = 5 ) ) ) ) )
) (statementn, resultdef = , pos = (13,23), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 3 (assignn, resultdef = $void = “untyped”, pos = (13,3), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 3 (typeconvn, resultdef = SmallInt = “SmallInt”, pos = (13,3), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_absolute], cmplx = 1, convtype = tc_equal, convnodeflags = [] (loadn, resultdef = SmallInt = “SmallInt”, pos = (13,14), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [nf_write], cmplx = 1 nil symbol = result ) ) (loadn, resultdef = SmallInt = “SmallInt”, pos = (13,17), loc = LOC_INVALID, expectloc = LOC_INVALID, flags = [], cmplx = 1 nil symbol = RESULT ) )
) )
обратить внимание! Имеются элементы для практически готового графического вывода в виде pos - позиция курсора
АСД на С, делающее тоже самое
int compute_sum(int n) {
int result = 0;
for (int i = 1; i <= n; i++) {
result = (result + i) * 2 - 5;
}
return result;
}Компилируем gcc -fdump-tree-original-raw Cprog.c -o Cprog_c
АСД языка С
;; Function compute_sum (null) ;; enabled by -tree-original
@1 bind_expr type: @2 vars: @3 body: @4
@2 void_type name: @5 algn: 8
@3 var_decl name: @6 type: @7 scpe: @8
srcp: Cprog.c:2 init: @9
size: @10 algn: 32 used: 1
@4 statement_list 0 : @11 1 : @12 2 : @13
@5 type_decl name: @14 type: @2
@6 identifier_node strg: result lngt: 6
@7 integer_type name: @15 size: @10 algn: 32
prec: 32 sign: signed min : @16
max : @17
@8 function_decl name: @18 type: @19 srcp: Cprog.c:1
args: @20 link: extern
@9 integer_cst type: @7 int: 0 @10 integer_cst type: @21 int: 32 @11 decl_expr type: @2
@12 bind_expr type: @2 vars: @22 body: @23
@13 return_expr type: @2 expr: @24
@14 identifier_node strg: void lngt: 4
@15 type_decl name: @25 type: @7
@16 integer_cst type: @7 int: -2147483648 @17 integer_cst type: @7 int: 2147483647 @18 identifier_node strg: compute_sum lngt: 11
@19 function_type size: @26 algn: 8 retn: @7
prms: @27
@20 parm_decl name: @28 type: @7 scpe: @8
srcp: Cprog.c:1 argt: @7
size: @10 algn: 32 used: 1
@21 integer_type name: @29 size: @30 algn: 128
prec: 128 sign: unsigned min : @31
max : @32
@22 var_decl name: @33 type: @7 scpe: @8
srcp: Cprog.c:3 init: @34
size: @10 algn: 32 used: 1
@23 statement_list 0 : @35 1 : @36
@24 modify_expr type: @7 op 0: @37 op 1: @3
@25 identifier_node strg: int lngt: 3
@26 integer_cst type: @21 int: 8 @27 tree_list valu: @7 chan: @38
@28 identifier_node strg: n lngt: 1
@29 identifier_node strg: bitsizetype lngt: 11
@30 integer_cst type: @21 int: 128 @31 integer_cst type: @21 int: 0 @32 integer_cst type: @21 int: -1 @33 identifier_node strg: i lngt: 1
@34 integer_cst type: @7 int: 1 @35 decl_expr type: @2
@36 statement_list 0 : @39 1 : @40 2 : @41
3 : @42 4 : @43 5 : @44
6 : @45
@37 result_decl type: @7 scpe: @8 srcp: Cprog.c:1
note: artificial size: @10
algn: 32
@38 tree_list valu: @2
@39 goto_expr type: @2 labl: @46
@40 label_expr type: @2 name: @47
@41 modify_expr type: @7 op 0: @3 op 1: @48
@42 postincrement_expr type: @7 op 0: @22 op 1: @34
@43 label_expr type: @2 name: @46
@44 cond_expr type: @2 op 0: @49 op 1: @50
op 2: @51
@45 label_expr type: @2 name: @52
@46 label_decl type: @2 scpe: @8 srcp: Cprog.c:3
note: artificial @47 label_decl type: @2 scpe: @8 srcp: Cprog.c:3
note: artificial @48 plus_expr type: @7 op 0: @53 op 1: @54
@49 le_expr type: @7 op 0: @22 op 1: @20
@50 goto_expr type: @2 labl: @47
@51 goto_expr type: @2 labl: @52
@52 label_decl type: @2 scpe: @8 srcp: Cprog.c:3
note: artificial @53 mult_expr type: @7 op 0: @55 op 1: @56
@54 integer_cst type: @7 int: -5 @55 plus_expr type: @7 op 0: @3 op 1: @22
@56 integer_cst type: @7 int: 2
Вот мы имеем 2 дерева для простой программы. Берём любой онлайн-ИИ и спрашиваем копипастом.. ответ не заставляет себя долго ждать
Аналогично для Паскаля, чуточку пришлось пнуть промпт-инъекцией
Иными словами, LLM вполне может справиться с синтезом если научить (не дообучить, не fine tuning) на уровне спецификации этому ремеслу. Поэтому на первом этапе будет АСД наиболее подходящее для его понимания. Вообщем надо разработчикам просто скинуть предложение про унификации и стандартизации промежуточного представления для любого языка, нечто более высокоуровневое чем LLVM
Что касается MCP на AST так это ищется первыми же ссылками проекты ast-grep MCP, mcp-server-tree-sitter, ast-grep MCP Server итд - но это всё нужно для автоматизации имеющегося кода. Парсинг - на выбор хоть Bison-Flex, хоть CLang, Python AST что угодно. Но это всё не то - это лишь помощь для агента в точном поиске фрагмента. Примерный поиск за счёт эмбеддера+Qdrant например а точный уже в согласии с выводом компилятора или извлечения структур данных на основе первичных парсеров и препроцессоров. Но это опять-таки поверхностный уровень по сравнению с непосредственным поиском алгоритма и дескриптора данных выраженных унифицированном AST. Активация tool - это примитив, ждём дополнительные аргументы/параметры/фидбэк для этого тула от разработчиков LLM . Спецификация только-только начата, так что будет ещё много нового, есть даже ссылки на типовые RFC. Так что сейчас особого смысла привязываться к конкретной реализации нет. Речь о решении задачи в общем виде минуя костыли, порождённые тоннами легаси и утилит.
Активация tool - это примитив, ждём дополнительные аргументы/параметры/фидбэк для этого тула от разработчиков LLM.
Это всё давно есть.
Так что сейчас особого смысла привязываться к конкретной реализации нет.
Ну если цель — не использовать инструментарий в работе, а просто посотрясать воздух бессмысленными нагромождениями слов — то конечно.
Речь о решении задачи в общем виде минуя костыли, порождённые тоннами легаси и утилит.
Какие еще костыли? Вы понятия не имеете, о чем говорите вообще.
это наличие утилит git, docker, diff для файлов. То есть в новой концепции данный подход исчерпан и осуществляется переход непосредственно на язык предметной области инвариатно к хранилищу и контролю версий на основе простого текста и файловой системы. Что касается tool - где обратный вызов, где идентификаторы сессий, где унификация источников данных, где API или что-то для двоички, что делать с битыми запросами, как вычистить битый контекст, запросы метрики использования модели, это обычный JSON-кофигуратор mimeType но не инструмент пока что в той мере которой хотелось бы, сейчас это выглядит как некий Modbus для 485-го без намёков на параллельную работу. Конечно странно требовать всё и сразу, но пока что цена использования этих инструментов устоялась и делать что либо другое +- упираться в эти ограничения.
Предлагаю более конструктивно, ведь наш диалог будет рано или поздно векторизирован для поиска чего-то хорошего или даже пойдёт как скилл для парсер-генераторов. Если не затруднит, ответьте пожалуйста на комментарии выше с простейшими примерами если возможно.
Не смотрели на Jetbrains MPS? На беглый взгляд идеи показались похожими.
Спасибо за ссылку, практически тоже самое с точки зрения концепции построения визуализации но не более того. Там нет спецификации AST как скелета для всего цикла разработки ПО - от ввода до контроля изменений, интеграции с ИИ-агентами, рефакторинга, окружения итд. То есть там даётся только для какой-то одной мультиязыковой платформы, но она не охватывает полностью указанные расширения. Там нет также прямого редактирования или хотя бы представления АСД как это сделано в программах по 3Д моделированию, и связи с низким уровнем и в обратную сторону. Это особенно важно для отладки например. Также там нет отказа от синтаксиса языка программирования при представлении - опять пресловутый текстовый ввод и импорт в классическом понимании. Фактически это просто визуализатор кодогенерации на некотором мета-языке понятным IDE.
public class... - это воспроизводимые сущности на экране по запросу а не синтаксис языка. Близко, но не то. Синтаксис - это (приближённо) команды IDE а не свойства языка, там этого нет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проектирование на основе абстрактного синтаксического дерева