МЕТА-ИНТЕРПРЕТАТОР "ПАРАДИГМА"

В следующем году вариант ГЛОТЕОНА будет готов. Можно будет начать экспериментировать. Кроме того, наконец, четко сложилась ПАРАДИГМА с помощью Александра Бурдукова, с которым в следующем году, мы наконец, начнём вместе "оформлять её формализацию" со связными комментариями. Есть идея так и назвать проект МЕТА-ИНТЕРПРЕТАТОР как приложение новой дисциплины МЕТАМОДЕЛИРОВАНИЕ + КОДИФИКАЦИЯ. Тот же ГЛОТЕОН и даже модная тенденция генерального или универсального "арт-интеллекта" могут быть рассмотрены с этих позиций как приложения ПАРАДИГМЫ.

1.35 Коучинг 2.35 (Креативность) Кредит 3.35 Кретинизм 4.35 Кризис 5.35 Криминал 6.35 Кристалл 7.35 Критика

1.36 Кронштейн 2.36 Ксило 3.36 Куб 4.36 (Кулуары) Кульминация 5.36 Культ 6.36 Кумулятивизм 7.36 Купон

1.37 (Куранты) Курс 2.37 Лаборатория 3.37 Лакуна 4.37 (Ламинарный, Лампа) Латентность 5.37 (Лафет, Лейбл) Лексика 6.37 Лемма 7.37 (Лента) Лепрозорий

1.38 (Летальность) Лига 2.38 Лидер 3.38 Ликвид 4.37 Лимит 5.38 Лимфа 6.38 (Линк) Лингва 7.38 Линия

1.39 Лист 2.39 Литера 3.39 (Лифт) Лицензия 4.39 Логика 5.39 6.39 Лозунг 7.39 Локация

1.40 Ломбард 2.40 (Луза. Луна) Люк 3.40 (Люмпен) Люстрация (Люфт, Лямбда) 4.40 Маг 5.40 (Мажор, Мазут, Майор) Макет 6.40 (Макулатура) Макро 7.40 Максимум

1.41 Ман 2.41 (Маржа) Марка 3.41 Марш 4.41 Маска 5.41 Масса 6.41 Мастер (Мастика, Мастодонт) 7.41 Материя (Матрац, Матрос)

1.42 Машина 2.42 (Мебель, Мега) Медиа 3.42 Мем 4.42 Мент 5.42 (Меридиан) Мета 6.42 Металл 7.42 Метр

Концепции грамотного и контрактного программирования

Как интерпретировать модель контрактного программирования с точки зрения модели акторов … посылка сообщения от интерпретатора может интерпретироваться как оферта (обязательства), например, публичная, где подписанты, фактически, акцептируют контракт … как-то так … а что касается языково-ориентированного программирования, то конструирование «предметно-ориентированного языка» по сути и есть конструирование интерпретатора … Чтобы не делать акцента на «языковости» можно говорить о лингвистическом программировании или литературном, а ещё лучше грамотном (по Кнуту) * … и, наконец, самое главное, взаимодействуя с компьютером, мы взаимодействуем с конкретной программой, телеграфируя ей свои требования и получая в ответ её реакцию, в роли «пользователей» … Но когда проектируем программы, программируем, то создаем интерпретаторы со специфическим функционалом, своей памятью и даже своим синтаксисом … соответственно существует интерфейс входа (протокол), который по факту диспетчер, дистрибьютор, супервизор, подобно главпочтампу, принимающему сообщения и распределяющему их между подписантами или подходящим интерпретаторам по шаблону (формату) … Для мета-интерпретатора в такой интерпретации не хватает реакции или самообучения любому входу, трансформации и соответствующего интерпретатора и, наконец, генерации каких-то сообщений помимо реакции на другие (при этом, которые не обязательно конвенциональные и найдутся интерпретаторы кроме генератора) … Более того, если подобный мета-интерпретатор будет способен интегрировать в себя все имеющие интерпретаторы, то станет инфраструктурой для взаимодействия и оптимизации этих интерпретаторов «внутри себя», симулируя «самосознание» … И это может быть вариантом конструктивного определения интеллекта … моделью интеллекта, например, в проекции исключительно символьных вычислений без выхода на прагматику внешних физических интерпретаций, без рассмотрения всего спектра потенциальных физических сенсоров … И это не противоречит модели переписывания, в которой общая структура, которую постоянно трансформируют интерпретаторы и есть, не что иное как, внешняя знаковая система, библиотечные фонды текстов и тех же программ, тот же гипертекст в сети …

Эта книжка не об этом, но она крутая … Хорошо бы написать, что-то в таком духе, только проще и соответственно в терминах моделей и интерпретаторов. Это полдела на пути спецификации мета-интерпретатора.

https://telegra.ph/Racket-12-20

UNISON-концепция

Как интерпретировать базовую концепцию проекта UNISON. Есть модель и есть реализация. Глядя на реализацию некоторые программисты обеспокоились хешированием реализации контекстно-адресной памяти, где в роли контекста, а точнее контента в ассоциативном массиве выступает код. Хотя сами авторы проекта позиционируют систему прежде всего как распределенную (а считается, что контекстная адресация этому способствует наряду с решением проблемы зависимостей, поскольку устраняет дублирование), а потом подчеркивают идею структурированного и эволюционного (!) хранения кода, определений и терминов, ну и все вытекающие из этого следствия. Архитектура ассоциируется как аналогия вики, где контентом страниц выступает код. Если бы в практики программирования не существовала линия развития, связанная с концепцией баз данных, а мы бы рассматривали концепцию персистентности просто в рамках развития организации памяти, та же концепция файловой системы могла бы приобрести совершенно новые интерпретации. Например, можно определить некоторые спецификации структуры того же файла как документа со своим адресом, который внутри себя содержит некоторые адресованные части. То есть, это уже наша активная практика в сети (не случайно провалились эксперименты с динамическими страницами), осталось её концептуализировать, конвенционализировать и стандартизовать. Развитие микросервисных и контейнерных архитектур этому способствуют. Необходимо переосмыслить концепцию виртуальных машин и аплетов. Возможно, что должна получить развития практика линейных хранилищ в оперативной памяти и когда-то мы откажемся от фрагментирования и куч в пользу стеков и операций с ними.

V-концепция

Лет 15 назад у меня впервые возникла идея поиска оптимальной системы программирования. И я ещё подумал, как бы я назвал такой проект. Пришло в голову - V как система пятого поколения и как "Виктория!". А с год назад я решил посмотреть проекты языков программирования, названных одной буквой латинского алфавита. Да, уже все буквы заняты. Естественно, что я обнаружил и Vlang, но поскольку не было цели знакомиться, пробежал мимо. И вот звёзды сошлись. Система состоит из модулей. Модуль - папка, в которой модули и файлы с функциями. Вот такая архитектура каталога. Но самое главное, что переменную нельзя объявить вне функции! Глобальных переменных нет. Встроенный модуль, по умолчанию присутствующий во всех других имеет три встроенных структуры - массив, строка и карта (естественно, ассоциативный массив). По умолчанию массивы - динамические. Модель управления памятью активно использует буфер, в котором и происходят все побочные явления при вычислении функций и который освобождается после завершения. Проект надо смотреть дальше! Там присутствует всё необходимое, что есть в других проектах. То есть это явный кандидат на бэкэнд для интерпретатора интерпретаторов! И не смотря, что ещё не существует релиза, уже сразу видно, что это настоящий конкурент мейнстриму и если даже автор проекта вдруг сдаст, то это стоит того, чтобы его подхватить и продолжать. Глубоко продумана и сама цель - система разработки и поддержки приложений!