все убираем и пишем через гото.

Чем тебе не угодили конструкции структурного программирования? Они никогда не зависят от контекста.

Чем тебе не угодили конструкции структурного программирования? Они никогда не зависят от контекста.

Ну как это не зависят? Есть же даже такая штука: «лексический контекст». Так что только хардкор, только глобальные переменные, только один неймспейс/модуль с глобальным скопом. Ну и про присваивание я говорил уже - это же неправильно, что в одном месте у тебя yoba = 1, а в другом - yoba = 2. А когда в одном и том же месте оно то то то это значит - это уже совсем пизда, за такое четвертовать следует.

Да так удачно, что до сих пор нет альтернатив

потому что академики разрабатывали а не прыщавые хаскеленутые борщевики

Мне кажется, ТС просто толсто троллит и набрасывает.

Нет, он на самом деле хуйло.

естественно, флип получает обьект типа (a -> b -> c) и может делать с этим объектом все что позволяет этот тип, если ты хочешь выдавать код/AST выражения, то тогда передавай функции ExpQ (если compile time), или runtime AST (что есть изкоробки в «интерпретируемых» языках, и легко пишется в компилируемых). Конкретно функции flip, которая предположительно меняет аргументы местами, AST не нужно, если ты под функцией flip имел ввиду какое-то общее преобразование, которое должно сделать что-то сложное с выражением, например, заменить значения всех строковых переменных на «loz», то про это можно говорить отдельно.

Разработчик: (пишет программы, учится новым технологиям, совершенствуется в классических, зарабатывает деньги) Лиспер: (бугуртит на ЛОРе)

Дискач.

Анонимус: обсирается с разметкой.

Не можешь возразить по существу — придерись к разметке, лол.

Да господи, Рома, зачем метать бисер перед свиньями? Я сюда захожу по большей части исключительно из желания развлечься, посмотреть на цирк и клоунов.

Это типа как если бы Петрик/Шипов/Акимов зашел «поржать» в CERN.

Все не читал. Просто вопрос возник: DSL-прасер когда-нибудь писали? Имхо, в начале да, тяжело, зато потом все как по маслу. И глаза не текут.

совершенствуется в классических
учится новым технологиям

Лол, лох. Уже не все так глобально и надежно, да? На помоечку пора конъюнктурщика.

В треде не хватает Эрика Наггума.

https://en.wikipedia.org/wiki/Erik_Naggum

http://harmful.cat-v.org/software/xml/s-exp_vs_XML

С ним есть одна маленькая проблемка...

Впрочем, на самом деле, никакой проблемы как раз и нет. Хороший мракобес — мертвый мракобес.

Искренне желаю судьбы Наггума всем местным борщевикам.

Лол, лох. Уже не все так глобально и надежно, да? На помоечку пора конъюнктурщика.

WHY SO BUTTHURT?

Ах, да, вас же из индустрии давно погнали ссаными тряпками.

Как будто грантопилы из CERN чем-то лучше Петрика. Все мошенники, настоящей науки мало осталось.

Это от новости Microsfot жабокодерня повылезала что ли? Борщ на связь вдруг вышел, стивжопс портянки по всему ЛОРу строчит...

Я знаю все эти языки кроме swift, на 3 из них успел поработать, и меня от них все тянет блевать.

ну swift в общем, на Dylan похож. только сильно покоцанный — лисп из него выкинули, а ObjC засунули. REPL там годный, на презентации с WWDC девелопер цельную игру наклепал, в REPL-е.

SQL

тоже говно. MUMPS круче. и вообще.

cast mumpster:

а что, неужто никто ещё не удосужился написать ЛNСП на MUMPS-ах ???

требую продолжения банкѣта!

и вообще, кто тут в цари самый крайний? никого? ну тогда я первый буду.

пупс MUMPS LISP шмисп

читая про дрѣвний и старпёрский MUMPS: 1 2 3, так и хочѣтся смахнуть скупую мужскую слѣзу, и занюхать борщомъ:

Выбор и реализация алгоритма хранения данных в «деревянной» форме привел к грандиозному успеху этой системы обработки данных. Хочу отметить, что кроме «деревянной» структуры MUMPS разительно отличался от систем, принятых в технологиях IBM, простотой (26 команд и 14 функций!), хранением программного кода в виде текста. Последнее обстоятельство позволяло и сами тексты программ хранить так же, как и данные в узлах тех же деревьев. Прекомпиляция тогда не применялась, при исполнении текст программы всякий раз обрабатывался интерпретирующей программой. Добавим к этому многопользовательский и многозадачный режимы работы с базами данных. Система оказалась весьма простой и включала в себя все, что нужно: систему программирования, систему управления базами данных, средства защиты от неавторизованного доступа, средства архивирования, восстановления и прочее и прочее.

Поскольку в моих дневниках имелись записи о расходе календарного времени на реализацию некоторых задач на языке PL/1, мне было интересно, сколько же времени уходит на ту же самую задачу в MUMPS. Соотношение оказалось впечатляющим: то, на что раньше ушло три месяца, в интерактивном режиме на MUMPS реализовалось за три дня! (Замечу, что сравнение не очень корректное – есть разница между первой реализацией проекта и второй – сказывается накопленный опыт понимания прикладной проблемы).

фортMUMPS-система:

Вот из этого микроконтроллера и был исполнен адаптер телетайпного канала, который в сторону MUMPS изображал из телетайпа обычный терминал с параллельным интерфейсом, а в сторону телетайпной линии он изображал из MUMPS обыкновенный телетайпный аппарат. Такой аппарат сам мог набирать нужный номер абонента, проверять по автоответу правильность соединения, передавать из базы данных MUMPS предназначенные данному абоненту сообщения. Данный проект был успешно осуществлен и проработал много лет в системе управления трестом, пока его не вытеснили более современные технологии. В процессе этой работы возникли побочные «детишки»:компилятор на MUMPS ассемблера микропроцессора I8080, загрузчики объектного кода в микроконтроллер и т.д.

don't call'em coders. codemonkeys.

Что же результаты принесла эта встреча на конференции в Кременчуге. Это, на мой взгляд следующее:
<...>
* Пользователи системы обнаружили, что существовавшие тогда в СССР различные ВЦ (вычислительные центры), ПКБ (проектно-конструкторские бюро), НИИАСПУ ( научно-исследовательские институты планирования и управления) и т.д. энергично саботируют продвижение системы MUMPS в СССР. Причина была весьма простой: применение MUMPS позволяло многим пользователям при решении своих несложных информационных задач обходиться без наемных контор-программистов. Большинство этих институтов напирало на использование в информационно-экономических задачах системы ОС-РВ (RSX-11 – системы реального времени для управления технологическими процессами и оборудованием). Причина очевидна – можно было продолжать использовать пакетный режим обработки информации на новейшей технической базе PDP-11. И тем самым обеспечить себе объемы работ и прочие блага.

После конференции продолжился водоворот текущих дел на производстве. Информационная система на MUMPSе встраивалась в существующую систему управления монтажным производством открывая совершенно новые возможности в последней. Это приводило и к изменению системы управления с использованием нового инструмента. Происходил своего рода интерактивный процесс: появление возможности использования точной оперативной информации позволяло отодвинуть горизонты неопределенности в принятии решений и появлению новых идей, реализация которых была немыслимой при традиционной технологии. Строители-монтажники подошли к моделированию вариантов возможных решений в организации производства. Эти варианты можно было просчитывать экономически и модифицировать путем взаимодействия на каждом этапе человека и машины и выбирать наиболее приемлемый вариант. Строительный процесс в реальной производственной обстановке представить фомальной математической моделью просто невозможно: действуют очень многие неформализуемые факторы типа личных отношений субъектов (например, как же в математической модели можно учесть влияние такого мощного фактора как совместное распитие «огненой воды» заказчиком и подрядчиком?). Человек из производственного отдела, сидящий за терминалом и моделирующий варианты воплощения производственного плана, разумеется, неформализуемые факты держал в «уме» и направлял расчеты в нужную сторону не утруждая себя объяснениями, почему им выбран или забракован тот или иной вариант. MUMPS делал весьма податливым информационный материал, новые идеи пузырились в наших головах и стремительно реализовывались. Это было время, когда работа превратилась в захватывающее приключение, причем эта работа происходила по ходу дела – то есть, все делалось на реальных данных, в темпе реальных событий. Не существовало разделения на ЗАКАЗЧИК и ПРОГРАММИСТ, не было технических заданий, проектов и отчетов, на которые в программистских конторах уходила основная энергия персонала. Когда в процессе такой работы рождался новый инструмент, составлялась простая инструкция по его использованию, определялся исполнитель этой работы, ему передавалась инструкция и проводилась небольшая тренировка на терминале в реальной информационной обстановке и все.

По сути дела, эта работа не была работой программиста – сейчас это принято называть работой аналитика системы

В комнате на трех столах установленных посредине в форме буквы «П» стояли три компьютера, на которых и демонстрировались достижения сторон друг другу.

Когда мы присоединились, Рустем Османов заканчивал демонстрацию американцам своего продукта с интерфейсом «а ля Питер Нортон». В те времена на каждом компьютере обязательно стояла MS DOS и весь интерфейс системы с пользователем обычно выполнял Norton Comander (я думаю, что современные пользователи не поймут, о чем это я...). Работа с этим продуктом Нортона была понятной и очевидной для каждого пользователя персонального компьютера, подобно тому, как для современного - работа с Windows. Рустем выдержал экранное оформление, назначение функциональных клавиш, назначение комбинаций одновременно нажатых клавиш в духе Питера Нортона. Но вместо файлов DOS в на панелях Нортона отражались директории программ и глобалей системы MSM. Этот интерфейс работал очень эффективно в смысле скорости. Одновременно он был очень прост для освоения любым пользователем, имевшем опыт работы в MS DOS.

пруфлинк

HIPSTER MUMPSTER ÖLSTER MÜNSTER

lovesan о XML-лисп правиле Гринспуна.

Вообще, расширение этого правила:

* Java программер доходит до лиспа, просветляется и плачет

=>

* л е м м а . интерпретатор MUMPSа это половина глючной реализации CommonLisp-а.
но справедливо и обратное: реализация CL с нормальной персистентностью и корутинами это лишь половина глючной реализации недоMUMPSа.

тут ЛNСП программист доходит до MUMPSа, просветляется и рыдает навзрыд.
затем он изобретает кластер метапарадигм, и его выносят. занавес. овации, переходящие в истерику.

....один мальчик написал на JavaScript операционную систему...
(c)bash.org, эпиграф

Потому что, следите за руками (предыстория болезни) — *ВНЕЗАПНО*, посещает мысль № I: на самом деле XML эквивалентен ЛNСПу. А простая среда сборки типа ant с плагинами — это и есть простой расширяемый «интерпретатор XML» — нам не нужон «парсер XML» или там схема, достаточно плагина.
То есть, Ant с плагинами + «семантически толстый» XML метамодели (сшитой из лоскутков отдельных моделей и XML-ей) — это и есть «менее простой, более составной» интерпретатор ЛNСПа, где вместо универсальных и однородных S-выражений имеем много различных интерпретаторов семантически (и даже синтаксически, лол) толстых XML-ей.
следовательно :-> вместо всего сонмища ad-hoc недоинтерпретаторов XML можно изобретать только ЛNСП,ЛNСПЛ,ЛNСП один только ЛNСПЪ (некий универсальный металиспъ как ЛNСПЪ всея ЛNСПовъ).

Опосля чего неизбывно воспоследуют — чтение Че Гевары; осмысление дневников велосипедиста; правило Гринспуна; ЛNСП ; перманентная научно-техническая революция VSM, deep learning, strong AI и Artifical Life => и, непременно — катарсис.

Но, ведь(ремиссия): читая про древний и старпёрский MUMPS, или натыкаясь на тексты посвежее: (например, здесь про установку и настройку GT.M — там в модной, молодёжной,хипсторской Java-обёртке коннектора, а также про обычные структуры данных через М-глобалы (например, вот здесь ), и даже картинку вот отсюда про эквивалентность массива — М-глобала и дерева ) ,
и вот,
ВНЕЗАПНО нашего сумрачного гения посещает вот такая вот шизамуза, и приносит на своих крылах мысль № II (рецидив: прорыв матрицы замечены остаточные следы киклопной мысли, а также нескольких цукербринов) :

на самом деле, не только XML — это S-выражения, а даже более того: S-выражения — это M-кубы и глобалы (как впрочем, и наоборот).

ПЫЩЬ!ПЫЩЬ!!!111 ϫϫϫ ОТАКЕ

истѣна где-то вон вот там.

Потому что вот есть S-выражѣния — это универсальные, однородные формы для представления данных: атомов, а также деревьев, структур и списков. В виде сферических в вакууме списков списками через списки, из одних токмо conscell-ов.

Но есть же в дикой природе и многомѣрныя М-гипѣркубы (глобалы) — а это тоже универсальныя, однородныя формы для прѣдставления данныхъ.

Составленныя из — уже многомерных conscell-ов. умеющих в блокировки и конкурентный доступ, в отличие от одномерныхъ лиспъ-объектов conscell.

следовательно, существует оптимальное универсальное (гомоморфное?) отображение лисп-объектов на мумпс-объекты(глобалы). и наоборот.
при этом, конкрѣтный вид (смысѣлъ и сѣмантика такихъ глобаловъ) — разный в разныхъ случаяхъ: наиболее много ограничений в семантике тамъ, где вмѣстно сиё.

(то есть, возможны и «более прямые отображения» из глобалов в конкретную ad-hoc семантику на «каждый случай»;

допустим, за реализацией лиспа на мумпсе неизбывно воспоследует некая более прямая семантика таких отображений глобалов на Х-объекты на некоем новомодном недоязычке X-lang;

так что же, следует ли намъ бросить всё, и оставить вѣдический православный лисп (на мумпсе), реализованный в соответствии с заветами предковъ нашихъ, отцовъ и дедовъ и веры в старыхъ богов перуновичей по заветамъ нашего рода?

потдаццо ли на искушѣние сѣго архонта новомодного — распятого бога христьянскога вѣры правовѣрной: греческой, ортодоксальной  — или быть вѣрнымъ вѣре прадѣдовъ, дѣдовъ и отцовъ нашихъ — вѣдической, православьной?


вовсѣ нѣтЪ! нужно искать более оптимальныя, гомоморфныя, ковариантныя и конформныя прѣобразования нашего истиннаго мѣталиспа в «конкретный» недолисп (не исключая осознанно выбираемого подмножества нѣдолисп-объѣктовъ конкретной рѣализации; конформность и ковариантность гомоморфизму должна обеспечиваться и для такого подмножества протокола нѣдолиспа «конкретной» реализации, сохраняя вѣрность завѣтам прѣдков нашихъ, в сѣмантике мѣталиспа завѣщанныхъ и родовую мудрость предков) ;

такия общия заповѣди и метаобъектныя протоколы могут попоспешѣствовать улучшению рѣализаций друг друга, и мѣталиспа и «конкрѣтного» недолиспа, образуя бутстрап-систему за счётъ гомоморфизьму метаобъектных протоколов ; гомоморфизьм же позволяет ворочать мегалитаме управляя магическим девайсом аналогично механизьму гомоморфного шифрования, а не закатывая солнце вручную )

(например, не исключаю варианта, когда такой глобал может транслироваться в С++-объект аналогичным тому образом, какъ в Qt moc, метаобъектный конпелятор транслирует из «гибких» Qt-объектов, умеющих в сигналы и слоты в «ж0сткия» C++-объекты, в оные непотрѣбства не умеющих;

выходитъ, и из С++ иногда бывает польза; впрочемъ: не исключено, что в новом С++11 и бусте от *более другого отображения* на порталы и корутины с махровой асинхронщиной может быть и поболе, пользы-то ; так что и отображения в «конкретный C++» тоже неоднозначны.

стало быть, и сигналы и слоты Qt-объектов в асинхронщину не умеющих подобным образом — есть лишь прообраз некоих «метаобъектов», умеющих более эффективно сконпѣлироваться в конкрѣтныя async/await объекты ;
также пѣрспективною идѣею видѣтся: строить не из метаобъектов «конкретныя, железобетонныя объекты», а наоборот: из конкретных — к общему
тогда новая реализация таких конкретных объектов может и улучшить кодъ нашъ вѣдический православный в мѣтаобъектах завѣщанный, и саму мумпс-срѣду новомодной асинхронщиной обогащённую ).


при этом мумпс-объекты (сиречъ глобалы, ибо все они суть многомѣрное отображѣния)  — универсальны также, как и лисп-объекты (всё — это conscell списками чѣрез списки на списки).

простыми словами

положим, некто написал бы реализацию mumps-лиспа (лиспа на М, в некоторой М-среде). а некто другой написал бы реализацию лисп-mumps-а, то есть: M-среду на CL.

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

например: берём старый мумпс в исходниках, прикручиваем CL через Z-функции (многие М-среды позволяют произвольно расширять себя библиотеками на Си). и вызываем CL как dll-ку.

в CL среде тоже: берём alien интерфейс, и пишем обёртки к Си функциям. которые вызывают мумпс-машину.

бутстрап:

1. теперь, в М-среде пишем лисп на мумпсе. он покамест будет гораздо более кривой, чем полноценная реализация CL через Z-функции. но, он уже «из коробки» сможет уметь в персистентность.

потому что если реализовать его на глобалах (которые аналогичны S-выражениям и также универсальны), он уже становится персистентным.

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

и проиграть её задом наперёд, например.

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

затем:

2. пишем мумпс на лиспе. изначально на CL, это тоже будет более кривая реализация чем годный продакшен мумпс. но эта реализация тоже сможет эволюционировать — если лисп, на котором она написана (некий условный абстрактный «металисп») вдруг станет не CL, а мумпслисп из пункта 1.

затем, можно будет переписать на таком «металиспе» свою реализацию мумпса, на которой переписать свою реализацию лиспа. на которой опять переписать реализацию мумпса. в итоге эта новая реализация — будет улучшенной версией старой, и можно переписывать их друг друга до бесконечности, улучшая.

3. в какой-то момент реализации встретятся. то есть, этот «мумпслисп» станет достаточно годным по сравнению с исходной реализацией CL-на-Сишечке, а «лиспмумпс» — достаточно годной М по сравнению с исходной «М-средой-на-сишке».

4. как именно они будут эволюционировать.

тащем-то, развитие семантики языков программировния идёт в сторону ограничения.

например если взять, BCPL => C => C++ => ML, Haskell => D => Rust

то есть: если исходный BCPL содержал бестиповые переменные, то в сишечке уже есть статическая типизация. правда, все указатели одного типа и их можно присваивать друг другу. в С++ уже есть полиморфизм, проверяется при присваивании. правда, есть косяки с транзитивностью константности (пофикшено в D). есть и расширение с полиморфизмом типов классов (пофикшено в Haskell). и кривые шаблоны вместо нормальных CTFE макросов (пофикшено в D). и кривой контроль времени жизни переменных, что вкупе с косяками транзитивностью константности приводит к граблям конкурентного кода. можно изобретать костыли типа «порталов» на бусте (фактически, каналы и сопрограммы + свой велосипед). а можно задуматься над семантикой, как её ещё годнее ограничить. и получить Rust, в котором каналы и корутины реализованы на стандартной библиотеке, а GC отстреливается благополучно из-за семантики владения и одалживания.

то есть: ограничение семантики приводит к улучшению производительности.

вот и тут из нашего обще-абстрактного «металиспа» мы можем постепенно ограничить семантику в «конкретный лисп», уже более производительный. который можно лучше соптимизировать, потому что «все ходы записаны» — в М-кубах и глобалах; и за счёт персистентности можно их крутить до бесконечности, попытки что-то лучше соптимизировать (например, суперкомпиляцией и сворачиванием графа конфигураций).

при этом набор ограничений и семантика ограничений тоже может быть не жёстко задана, а определяться оптимизационным поиском, пытаясь подобрать разные варианты «достаточно умным компилятором» (или скорее, связкой «компилятор+суперкомпилятор», у которой возможностей для оптимизации и сворачивания всяко больше).

потому что это бутстрап система из 2х самоподдерживающих элементов, эволюционирующая.

такая вот идея. а теперь лирика.

Къ примѣру: Въ видѣ массивовъ, где атомъ или символъ или перемѣнная — это массивъ 0-ёвой (нулёвой) размерности. Далее, массив 1 размѣрности — это хѣш-таблица, словарь (если и индексы, и значения только допустимых, ограниченных типов). Получаем ассоциативную память ключ-значение (или мапа символ-скаляр и денотат). Массив 2й размѣрности — это разреженная таблица с отображением ключа-вектора на значениѣ. То есть, символъ — становится векторнымъ (и гипертекстовымъ, лолЪ). а значениѣ может быть и глобаломъ. То есть, символом и денотатом, или — 2-й и выше размѣрности. Получается, что массив 2-й размѣрности — это метод — заданный таблично, и задающий распознаваниѣ символовъ черезъ символъ. Это уже функторъ. Массив 3-й размерности — это парадигма, опрѣделённая на методахъ. Монада, извиняюсь, ивановна. Массив 4-й размерности — это метапарадигма, или парадигма парадигмъ. Алгебры и коалгебры Калвина Элгота, наконецъ. и наконѣц-таки, воспоследуетъ самоорганизующася крѣтиничность бутстрапъ системъ из гипермножеств Гёнзеля: Массив 5-й , и выше, N-ой размѣрности --- это уже вот он, сам-как-есть, M-гиперкубовый КЛАСТЕР МЕТАПАРАДИГМ. -=[ ДЫК ИШЬ, ВОНА ВОТ ОНО КАК ВЫХОДИТ. И ГДЕ-ТО ВНУТРЕ У НЕГО ТАМА — АНАЛИЗАТОР & ДУМАТЕЛЬ™ ]=-

НО! Мы не станем останавливаться на достигнутом N.

И даже K. M для нас тоже *маловато будет*.

Перейдём сразу на бесконечность (чего уж мелочиться-то).

Помимо того что М-куб, глобал — это массив, он же — заодно и дерево.

Смотрим картинку вот здесь про эквивалентность массива — М-глобала и дерева, а также про обычные структуры данных через М-глобалы вот здесь .

Выходит, М-куб и глобал — эквивалентен S-выражениям ???

(правда, покамест, конечным — но как будет показано далее, это несущѣственное ограничѣниѣ: ибо ДВА воистѣну мѣтациклических интерпрѣтатора с легкостию могут интерпрѣтировать друг друга до бѣсконечности, и дажѣ большѣ — такъ же, как для танца нужны двое, без чукчи-читателя нѣтъ чукчи-писателя;
объяснения — без разсказсчика-объяснятора и втыкателя-понимателя; без Евала-грѣховодника — святога Апплая функционально прѣчистаго, а без ЛИСПа — лиспера MUMPSа полноцѣннаго, и наоборотъ)

(отседа следствие мумпстора из правил Гринспуна — «любая реально сложная программа содержит в себе куски как ЛNСПа, так и MUMPSа»)

Что же умеет простая обыкновенная хреновина MUMPSовая даза банных?


Помимо того, как просто хранить глобалы?

О, оказывается много чего: сопрограммы (кто там сказал goroutines?), процессы, и прочую махровую синхронщину (асинхронщины,порталы — однако, оная не умеетъ). Ещё лочить дерево с графом зависимостей, с понтом такой pipeline node scene graph.

Каналов типизированных, правда нѣтути — но зато у нас есть глобалы с локами, транзакциями, блокировками. впрочем, шины сообщений заместо них.

Ещё есть сопрограммы — рутины с несколькими точками входа, лексическими замыканиями.

И переменные процессов. И сами процессы.
И компилируемые рутины плагинами — в стандартной библиотеке, или в своей.
Закат солнца вручную в рутинах.

И вся вселенная в ZZ-функциях.

И даже Будда. И даже аллах. И киклоп.

И дважды косвенность (indirection).

SET @CODE=$$VIEWASDATA^%EVAL(DATA) @DATA=$$VIEWASCODE^%APPLY(CODE)

 set @symbol=$$hypertext^%link(^denotat(name,plist,object,metaobject))[br]
 set @metaproto=%metaparadigm(^cluster(object,metaobject,method)) @symbol=$$(@metaproto)^%link(^denotat(name,plist,object,metaobject)) [br]
 ;^^^ this didn't suppose to have a sense if you're not too drunk yet[br]
 set @metacode=$$mc^%metacircullareval(codedata) @metadata=$$md^%metacircullarapply(codedata)
 MERGE ^GLOBAL1alCaaba(metacode,metadata)=^%RustLang1BorrowSemki(LOCAL1codedata) LOCAL1codedata=^%RustLang1BorrowSemki(^%EVAL(^GLOBAL1alCaaba)) 
 ; ^^^ ПЫЩЬ. на самом деле он многомерный глобал, этот ваш КЛАСТЕР МЕТАПАРАДИГМ
 

кластиръ метапарадигмъ

Что же это получится, ежели написать на таком MUMPS-е ЛNСП?

О, много чего интересного: движок СУБД становится движком ЛNСПа, а S-выражения и символы и plist и alist  — глобалами, глобалами и глобалами.

Во-первых, глобалы и локалы выглядят одинаково  — только одни персистентные, а другие нет.

То есть: а) все данные становятся прозрачно персистентными и MUMPS-лисп  — это символы символами через символы, вычисляющиеся в СУБД, в которой живут персистентные символы, сопрограммы и процессы б) при большой нужде можно вынести глобалы в локалы(или наоборот), пересадив поддерево стандартным MUMPS-овским merge — реализовав через merge fork/join (или там, map/reduce).

И ещё, во-вторых в) локалы могут быть как переменными процесса, так и рутины (привет, лексические замыкания), или рутины, вызванной из рутины (реализуемой в разделяемой библиотеке, so/dll-ке)

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

объекты (которых, впрочем, в классическом MUMPS-е нет, и надо реализовывать отображения CLOS-ного MOP-а на MUMPS-платформенные глобалы-переменные процесса-локалы-интринсинки) и процессы(аналогично, на процессы-сопроцессы-сорутины-конечные автоматы) и локи(«локки против одина» и «иггдрасил с поддеревьями», блокировки поддеревьев, транзакции, наколхозить свой STM костылями, либо чудовище заморское, аленький цветочек и т.п. «пойдём по длинному пути» извращения)

мѣтапарадигмы, тащем-то, как они есть. они самыя.

метапарадигмы, как они есть

где все эти элементы «КЛАСТЕРА МЕТАПАРАДИГМ» можно двигать туда-сюда в ядро, из ядра и наружу (как намъ подсказывает топология, налево и направо, вверх и вниз — и в другия стороны, по направлениям ана и ката-морфизмов — в общем, на все 4D стороны):

в реализацию мѣталисп-интерпрѣтатора
а) MUMPS-рутинами на MUMPS-интерпретаторе, на чистом MЪ
б) на лиспе
в) на CTFE метаязыке.
Здесь в качестве такого CTFE мѣтаязыка интересны модульные, с поддержкой макросов, легкие, прозрачные: 1> RustLang 2> Dlang + ldc 3> GoLang (в гораздо меньшей степени. тогда уж лучше Erlang и Erlisp, лол).

Здесь некая хрень, компилирующаяся в LLVM с нормальной модульностью и 0 затратами на рантайм — зѣло интересна. Например, в Ржавчине внезапно выясняется, что и корутины и каналы можно реализовать в библиотеках, а вот последовательное ограничение семантик в виде семантики одалживания и времени жизне — годная весч.

Вообче, ежели последовательно рассмотреть семантики BCPL O-code => C указатели => C++ полиморфизм объектов => тайптеги лNспега => тайпклассы хачкелля => (...где-то здесь будут порталы из махровой асинхронщины с хабра ...) => контроль времени жизне посредством сборщика мусора => ARC в огрызке => одолженные объекты в ржавчине и контроль времени жизне посредством регионов => .... ... => новое, неведомое нечто

-> то видно, что бОльшая эффективность «конкретного лиспа» по сравнению с абстрактым «металиспом» возможна только за счёт ещё более ж0сткого ограничения семантики.

чем больше ограничений, тем эффективнее конечный результат.

Поинт в том, что ежели было бы представление в виде металиспа (возможно, гиперкубами-глобалами) — то такие оптимизации можно было бы не делать руками, а ВЫВОДИТЬ АВТОМАТИЧЕСКИ.

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

Затем, можно прикрутить сахарок в виде того же PEG (на таком лиспе), который CTFE макросами раскрутится в металисп. Поскольку PEG может описать сам себя, остальной сахарок достаточно написать на нём самом.

Металисп же CTFE макросами раскрутится в этот нормальный модульный-прозрачный движок времени компиляции. В идеале с 0 затратами на рантайм, не платите за то, что не используете. Движок в свою очередь раскручивается из всего подо всё, ибо LLVM.

То есть, мѣталиспъ — это не 1 реализация «конкретного» недоЛNСПа, а сразу всё сѣмейство чохом: а MUMPSе, на CTFE, на себе самом, вот это всё.

Поѣнт в том, что можно раскручивать одну реализацию из другой. ПУПС-МУМПС-ЛNCП реализует хранение и персистентность, и пишется на самоЛNСПе, который пишется на себе самом и минималистичном CTFE ЛNСПЪ-ядре.

(тащем-та, на таком б) можно написать а), как и наоборот. при этом можно раскрутить конпелятор из а)->б) в сторону б)->а), отталкиваясь от готовых сишных MUMPS-сов и заменяя ихнея ведро на в) реализацию на более годном (с зелёными нитками, замыканиями и каналами) языке с асинхронщиной.

например, на RustLang. тащем-то, берётся MUMPS/II или там MDH Toolkit от Kevin C.O'Kane и портируеццо с С++ на RustLang, GoLang, или там Dlang — CTFE конпеляцией )

файло, коммандиръ, суть лишь вьюшка к глобалам

Затем, пишем обёртки из металисп-MUMPS-системы во внешний мир ОС-среды.

Например, плагин FUSE, который реализует нечто подобное Plan9FS или REST API.

То есть, является файловой обёрткой к М-глобалам (они же деревья, они же списки, они же массивы, они же символы, они же метапарадигмы).

точнее — Псевдофайловой (как и /proc/PID/fd/N, это всего лишь точка view; карта, а не территория).

Далее, используем идею из org-mode babel или Literate Programming.

Пусть сниппеты из org-mode babel — это «метапарадигмы», то есть, связки «объект+метаобъект». У них есть параметры (метапеременные и метафункции для вычисления сниппета-шаблона, они же метаклассы и метаобъектный протокол, они же метасимволы метапарадигм).

И они же — псевдофайлы.

Теперь, реализуем запекание текстур в pipeline, когда из hipoly + метамодели метапарадигм кластера нашим inference engine генерируется толпа частных метамоделей+конкретных парадигм, уплоть до конкретной lopoly и карты из процедурных генераторов метавселенной создание метапарадигм через псевдофайлы и наоброт.

То есть: есть документ-контейнер (конверт в виде грамотного документа), и «расконверчиватель». Расконверчиватель из метапарадигм в мумпс-гиперкубах генерует файлы, а конверт — из текстовых файлов генерит метапарадигмы в пупс-мумпс-гиперкубах и глобалах.

например — только в gnu skribillo более верное направление.

То есть, это будет такой weave/tangle из грамотного программирования  — только более продвинутый, ибо типизирован объектами и метаобъектами.

Потому как при этом для расплетённого раскручиваются макросы макросами через макросы, то в есть результате метапарадигма конперилует абстрактную сферическую метамодель в конкретную частную посредством металиспа (также как ant делает build/test/run/deploy; при заплетении же конпелирование моделей в модели через модели получается в обратном направлении).

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

При сохранении и изменении псевдофайла «чукчей-писателем» выполняется один триггер-метапарадигма, при обновлении — другой (и уведомление подписанных на обновление псевдофайла «чукчей-читателей»).

Свечка с канделябром превращается в снежную лавину (snowcrash(c)N.Stivenson) триггер хэппи со-бытий (сл. «Всё хорошо, прекрасная маркиза» а также см. «Формализация со-бытийности: бутстрап-системы в биологии, биосферологии, кибернетике и физике.» А.Б.Казанский).

То есть, достаточно одного неосторожного квантового кота Шрёддингёра (ЯЩИК-ТО МЕТАПАРАДИГМ УНУТРЕ У НЕЁ, ДА С НЕОНКОЙ), чтобы попытко наблюдения за ним через щелочку псевдофайлов запустило цепную реакцию — фунцикляция метапарадигмов АНАЛИЗАТОР & ДУМАТЕЛЬ™ и дажѣ конпѣляция цѣльного КЛАСТЕРа МЕТАПАРАДИГМ из металиспа в конкретный недолисп.

А XMLную метамодель в частную модель через лисп можно и на самом таком вот металиспе сконпелировать.

//эксадрон моих мыслей шальных: бутстрап системы и кибернетика второго порядка

Достаточно тѣперь прикрутить к ящику MMO фритуплей объѣкты+мѣтаобъѣкты из «компилируѣмой сѣмантической вики», Jabbѣr-(или juick) интѣрфейс к MUD-ам с deep learning и инференс с майнингом и возможность эволюционировать синергетически на гипермножествах и бутстрап системах — и всё заверте... нас ужо не догонят.

воистѣну такъ.

к примеру, помимо Казанского с его гипермножествами и со-бытийностию можно также запрограммировать и Хренникова А. Ю. «Моделирование процессов мышления в p-адических системах координат» — использовать адели для адресации гиперкубов.
Конечно, настоящий прорыв будет когда метакомпилятор на MUMPSе можно будет реализовать аппаратно, на базе FPGA — а чо такого, вот попытки реализовать ассемблер контроллера были, а чем тут хуже?

Получится такой dataflow engine.

«Программируемый шизик», который умеет реконфигурироваться, то есть делать слияние и расщепление «волн сознания» как суперпозицию квантово-эверетической волновой функции мозга цельного феномена «волн сознания» из отдельных «волн мозга».

то есть, «расщепление» и «слияние» волновых функций отдельных «сознательных субличностей» (киклопов)

Получаются дубли у Стругацих в понедельнике — или аппаратный fork/join в терминах процессов или map/reduce в терминах данных.

причомъ на энтой машине не исполняются питушение регистров вручную в АЛУ, вовсе нетъ!
бери уровнем выше — там исполняются потоки и процессы (также, как на уровне мумпсовой вирт. машины исполняются мумпс-$JOBS и мупс-процессы). в ржавчине это будет отдельный spawn в отдельном АЛУ, создаваемом «по требованию». и все они такие асинхронно связаны, без общего тактогениратыря.

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

один асинхронный самоконфигурируемый узел (look ma, no кварц) — один процесс недолиспа.

и металисп для объединения отдельных недолиспов-процессов(на своих асинхронных процессорах) в общий лисп. аппаратный, на FPGA+MUMPS.

уже рассчитанные гиперкубы глобалов можно ж0стко зашить в FPGA (поцчитанную в CTFE макросах табличку глобалов, а не yield процедурную генерацию этой таблички)

получаются многостадийные вычисления :

процедурная генерация в рантайме при запуске -> CTFE в макросах при конпеляции -> TBFE в многомерных табличках (М-кубах) при суперкомпиляции

здесь поскольку S-выражения изоморфны M-кубам, и программы представляют собой деревья (как conscell-ы в рантайме/компайлтайме или как М-кубы и оффлайн, ибо персистентная структура)

=> суперкомпиляция на таких М-кубах позволяет сохранять всю существенную информацию для возможности дальнейшей оффлайновой оптимизации.
при этом способ выполнения такой суперкомпиляции задаёт модель ограничений семантики (как конкретно универсальный абстрактный персиситентный металисп отображается на «конкретный лисп»)

Вот как-то так-то вот оно, ишь вона оно как. Так вон он какой, КЛАСТNРЪ МѣТАПАРАДИГМЪ мѣталиспа, выискался. Нечто подобное, ЕМНNП изобрёл однажды последний программист в рассказе НАЖМNТЕ EИTЫRЪ. после чего наспех скомпелированный КЛАСТЕР МЕТАПАРАДИГМ досрочно осознал себя. тут скомпелировавшиеся через внутренний eval/apply близнецы брахман с атманом наконец-то рассмотрели свой пупок, после чего довольно хрюкнув и сказав на прощание 12309 «Оом!» —
и матрица ВНЕЗАПНО перезагрузилась.

ещё у него про гиперкомплексные подборка интересная.

это вчерашний день - сейчас новый вид высокоточного: достаточно сформировать правильную и достойную мыслеформу.

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

В психиатрическую клинику будут водить программистов которые после тебя будут читать твои программы на xml

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

Но зачем MUMPS? Ведь можно просто метаклассами прикрутить персистентность к лиспу? Или лучше зделоть лисп с встроенной возможностью к персистентности(я бы тут не брал мумпс за основу, потому что зделон тупо, бате не понравилось, говорил можно лушче - массивы как основа ето это тупо зделоли), чтобы персистить консы и символы, и даже буковки, и даже метациклические интерпретаторы, и даже аллаха.

последний программист

нажмите ENTER

вообще-то перепутал, сорри: Герберт В. Франке «Последний программист» Der letzte Programmierer Рассказ, 1981 год

или вообще я бы зделол ето на уровне ядра, нечто похожее на ФантомОС(простите уж за референс), чтобы вообще не думать а чтобы само(как GC)

пойнт в том, что одного метациклического интертрепатора недостаточно: нужно 2, чтобы получился бутстрап. а персистентность в CLOS, слава MOPу и так в 2 строчки прикручивается.

мумпс здесь позволяет сделать персистентными вообще всё, даже аллаха: все S-выражения, которые становятся M-кубами. а не только объекты. спецформы например, макросы и т.п.

а если чего не надо персистить — так можно глобал сделать локалом, переменной мумпс процесса.

а чего ещё бате не понравилось? массивы это сила. фортран до77 и SSA в LLVM подтверждае.

другое дело, что в MUMPS нет нормальной асинхронности и строки ограничены кусками по 32к, емнип, надо чанками обёртки делать.

ну сам недоязычок М вообще, это конечно, нечто. тащем-та Okane правильно говорит, что его надо выкинуть, а какой-то MUMPS/II запилить. или вообще выкинуть, оставить чистый Btree C++ объектами. только без С++, а с более годным языком (например, ржавчиной).

вообще да, если уже указатели и так 64-битные, пихай туда тайптеги и персистентность на уровне подкачки — не хочу.

Ты чего, прочитал все его портянки?

Жесть... У Булгакова рассказ похожий был.

Борщехлеб в терминальной стадии.

допилить рантайм лиспа на дотнете

зачем если есть Clojure? Он же и под .Net стабильно развивается.