Wolfram и концептуальное насыщение

Намедни вспомнил про проект в контексте аксиомы Вольфрама и решил попробовать ещё раз погрузиться. Была не одна попытка, в принципе там много естественного и разумного ... включая ту же идею-фикс с клеточными автоматами, которые у меня ассоциируются с метафорой черепашки *. Но понял, что там просто принцип "танка" - "все включено", а большой текст с описанием философии, базового подхода, уже для прикрытия. В результате, имея перед глазами развернутый интерфейс, архитектура системы остается загадкой (!), да и маркетинг проприетарный. Все спрятано под большим слоем информационного мусора, без его аккуратной классификации (не считая конечно классификатора конечных автоматов ...).

Короче, "черепашка" у меня теперь трансформировалась в паука ...  * . (См. Urbit), но главное, это то, что я почувствовал какое-то "интеллектуальное пресыщение" ... или ... "концептуальное насыщение" ... Предел! Сознанание под завязку ... Это или старость и усталость ... или сигнал для очередного рефакторинга, тотальной переоценки. Сосредоточусь на проекте PicoLisp на WASM в формате ASON, а все что касается простанственных рассуждений, развития дисциплины МЕТАМОДЕЛИРОВАНИЯ, то это последний пост без привлечения интеллектуальных ботов. Они стали прекрасными поисковиками. Да, ещё не все знают ... но активно развиваются ... Главное научиться формулировать вопросы, тему ... и тогда они становятся прекрасными соавторами внятных интерпретаций, по сути рефератов. Так что все следующие посты будут новым экспериментом.

Haiku

Чем меня заинтересовало направление BeOS? Не только, что бывшая команда Apple, а прежде всего тем, что это более развитый POSIX. Файл атрибутируется метаинформацией, что фактически, делает файловую систему объектной базой данных. Её открытая версия. 

Сетевой стек работает в режиме ядра ...Одна из отличительных особенностей системы — архитектура трансляторов — системных интерпретаторов файловых форматов. Кроме того, Haiku продолжает традиции BeOS по активному использованию файловых мета-атрибутов, что позволяет реализовать работу с данными простыми и очевидными методами (см. OpenTracker). Файловая система OpenBFS поддерживает расширенные атрибуты файлов, журналирование, 64-разрядные указатели, поддержку хранения мета-тегов, максимальный размер файла — 260 гигабайт, раздела — 2 эксабайта (261 байт или 2 миллиарда гигабайтов).

Интерфейс в пользовательском пространстве, но из-за совместимости с BeOS.

https://www.haiku-os.org 

Мне трудно представить, что я ещё полезу разбираться в ядро ... Но базовые вещи ... , с их документацией познакомиться стоит.

Не "чистые", а "голые" объекты

Круг замкнулся. Не считая нескольких лет, когда я занимался моделированием уравнений матфизики, точнее моделями, описывающимися уравнениями матфизики и компьютерные системы были исключительным инструментом для реализации соответствующх алгоритмов, осознанно, к этим инструментам я стал подходить позднее, когда стал менеджером в разных организациях, требующих автоматизировании их "бизнес-процессов". Так вот, имея навык исключительно с "процедурной" концепцией и немного с реляционной теорией SQL и теорией продукций PROLOG, я попал в самый апогей дискурса между ООП и функциональным программированием. При этом меня тотально окружали приверженцы последнего , а я был типа "белой вороны", отстаивающий объектный подход. Но теперь, я "прошел" путь от полного презрения концепции функций к её пониманию и связи всех концепций, в принципе. Совсем мало анализируются, собственно, архитектуры систем и все сводится, как привило, к обсуждению синтаксиса или интерфейса к этим архитектурам. То, что говорят, когда сравнивают, например, Форт, Лисп ,АПЛ и Смолтолк - совсем не то и совсем не о том, особенно когда это все ещё неявно замешивается с алголо-подобным синтаксисом или сранения, в конечном итоге, с ним. Короче ... тема интересная, хотя может и не важная ... с точки зрения оптимизации, которая, как правило, нужна в последнюю очередь, когда, действительно, "куда-то клюнул петух". А когда все работает и страшно все это менять, а вдруг сломается ... зачем ... то очевидно, что до этого нет никому дело, кроме кучки энтузиастов, которые всегда были и, наверное, будут. Так вот. Экскурс в Self привел к IO, а через автора последнего к СИСТЕМЕ ПРЯМОГО МАНИПУЛИРОВАНИЯ СТРУКТУРИРОВАННЫЗ ДАННЫХ ... Вот так просто и ясно сформулирована коечная цель.

И сразу все встало на свои места! Даже отношения клиент-сервер и хост-домен, не говоря уже о MVP (в обоих смыслах). Теперь надо просто это все осмыслить с позиции модели акторов, где акторы - интерпретаторы ... P2P ... смарт-контракты ... и Web GUI в ядре ... Но ... при этом, все объекты (включая процессы), объекты внимания, где их базовая характеристика, только инкапсуляция, а все остальное факультативно. Объекты-интерпретаторы ... объекты-месседжи ... объекты-ресурсы ... объекты-инструменты ... и т.д. и т.п. Функции - интерпретаторы ... и те же объекты! И, похоже, что двух архитектур, прототипами, которых являются Erlang и Tiddlywiki, вполне достаточно и они универсальны! И вот что надо иметь в виду (может подсматривая за ассоциативнм массивом AWK) при реализации PicoLisp на WASM с базовым форматом ASON. 

Ещё две неожиданные темы

Перечитывал документацию Self. Есть новое текущее понимание как все должно быть и с этим новым пониманием некоторые старые тексты понимаются по-другому и не только глубже, но и шире ... 

А ещё одна тема - концепция local-first, * которая очевидна, но стала модной в прошлом году и по этой причине, была проигнорирована, но случайно авторитетные специалисты обратили внимание ... 

Перевариваю ... параллельное погружение в PicoLisp и WASM создают ментальные перегрузки, заставляют теперь все новые вещи интегрировать и примерять в едином ключе, в некоторой обощенной концепции, а мозг уже стал лениться ... учиться чему-то новому ... которого при внимательном рассмотрении-то и нет, но что тоже требуется понять через призму новых интерпретаций и другой лексики, увидеть аналогии в "разных пространсвах имен".

И по старой привычке зачем-то полез экспериментировать с очердной и новой для меня соцсетью Zulip ... https://metamodelling.zulipchat.com Отказался от твиттера и фейсбука, хотел сузить присутствие в сети, а в результате прибавилось мест в пять раза больше (!) ... В некоторых присутствую только как читатель, подписавшись. Надо думать как это теперь использовать, утверждается, что удобно работать с темами, на что, собственно и купился. В крайнем случае, буду опять же, читателем, поскольку там есть новые проекты компьютерных языков.

Urbit

Инициировал очередной тиддливики файл для анализа архитектуры urbit. Как глубоко заметил deep-econom необходимо проанализировать реализацию их виртуальной машины в сравнение с концепцией EVAL в Lisp. Я бы ещё добавил с экспериментами выделения минимального базиса слов Forth. Вывод минимального количества аппликаторов (комбинаторов, лямбд, стрелок, модификаторов, правил, шаблонов, паттернов, МОДЕЛЕЙ ... что и надо специфицировать как базовые интерпретаторы) - эвристика, потому что эффективность как баланс между скоростью и памятью зависит от аппаратных реализаций. Теоретически достаточно два, комфортнее четыре, а может шесть, восемь, двенадцать ... а то и 16 или даже 18. Надо экспериментировать, как и с размерами базовых фрагментов памяти. Но это того стоит. Получить свой стандарт виртуальной машины, учитывающей операционнцю среду с её пространством имен типа адреса, файлов, директорий, портов, процессов, сервисов, демонов ввода-вывода и так далее, прежде всего, оптимизировав интерфейс с хостом.

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

Ответы на эти вопросы, выработка логической позиции - "розеттский камень" программирования.

Два параметра объекта GLOBAL

С чего стартует спецификация потенциального интерпретатора на WASM, а по пути неколько принципиальных замечаний:

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

2. Отсюда и первый парамтер для типизации связного списка - односвязный, двусвязный ... и может быть и регулярный массив ... MEM-LINK.

3. Второй параметр - MEM-ATOM ... 128 bit, 256, 512, 1024 ... 

4. Все параметры привязаны к объекту, фрейму. "Примитивный параметр" как пара слотов ассоциативного массива принципиально инициируется как фрейм (объект), со всем вытекающими последствиями. "Неизменяемая архитектура" базового объекта интерпретатора в "WASM-песочнице" ... в системе других распределенных "классов объектов" в сети ...

5. Ортогональность как принцип обуславливает прозрачную базовую архитектуру. Динамиеский список над регулярным массивом. Это и есть синтаксис системы, у которой интерфейс синтаксический формат.

6. Термин FUNCTION используется в математичесом смысле. Общий термин для выражения операций, алгоритмов и программ - INTERPRETATOR.

7. При "перписывании" структур, когда на выходе имеет место многопараметрическая структура, интерпретаторы специфицируются как процедуры, команды, инструкции или макросы.

...

Далее будет развертываться данная спецификация, уточнятся, детализироваться ... и так далее ... до очевидной реализацюю. К базовому словарю: ПАРАМЕТР, ФРЕЙМ, ОБЪЕКТ, ИНТЕРПРЕТАТОР, ФУНКЦИЯ, ПРОЦЕДУРА, КОМАНДА, ИНСТРУКЦИЯ, МАКРОС, АССОЦИАТИВНЫЙ МАССИВ, БИТ, БАЙТ, СЛОТ, СТРУКТУРА, СИСТЕМА, АРХИТЕКТУРА, АДРЕС, СИНТАКСИС, СЕМАНТИКА, ИНТЕРФЕЙС, ФОРМАТ ... 

Представление кода на графе

Ищу способы выражение кода на графе. Нет проблем отобразить графом фрагменты "физического пространства", ясно как выражаются переходы от состояния к состоянию (от одной именованной структуры к другой), но вот повторить имя на одном холсте с размещением графа уже проблема. То есть, если повторяется параметр, входящий или выходящий из разных процессов или вызов одной и той же  процедуры (функции) с разными параметрами, то просто "инкаписулировать" одно имя не выходит ... на одном холсте просто имя можно повторить только один раз. И это не рекурсия в классическом понимании. То есть. Кстати, по пути и возникает тема выражение рекурсии на графе. А может и цикла. Указание стрелки, перехода на само имя теряет семантику ... Возможно существуют способы, о которых мне пока не известно. Буду пробовать маневрировать холстами. То есть для описания "имени", а так же вызова имени - отдельный холст для графа. Может в этом даже что-то есть принципиальное. Имя как модель и код модели всегда следует отделять, как и факты представления и реализации.

Экспериментирую с описанием одной из функций PicoLisp, со списком, кодирующим несколько уровней вложенности.

Рассматриваются вопросы построения графа по заданному тексту программы, специфический взгляд на сложность