фикус

_backup/2015-07-17-го.md

@@ -0,0 +1,10 @@
+---
+published: true
+layout: post
+---
+ 
+
+
+## Старт
+
+Ок, работает.

_backup/2015-07-17-лола.md

@@ -0,0 +1,45 @@
+---
+published: true
+layout: post
+---
+
+ 
+## Изучая Lola
+
+Поизучал описание языка [Lola](http://www.inf.ethz.ch/personal/wirth/Lola/index.html), в итоге понял, что MODULE это такая радиодеталь с ножками, вход/выход, внутренние преобразования по заданным функциям, вот это всё.
+Подумал над применением в программировании акторов или агентов, ведь агент это та же радиодеталь, датчики как входы, манипуляторы, как выходы. На программном урове, это всё, конечно, укладывается в понятия направленного канала сообщений и сообщения. Сообщением в LEAF можно сделать любой тип данных, передавать можно значения, или даже указатели, если они будут защищены от записи.
+
+Придумалось тут:
+
+	UNIT Fib
+		VAR res+, n- INTEGER
+		VAR f Fib
+	PROCESS
+		f.n <- n - 1
+		res <- IF n # 0 THEN n + f.res ELSE 1 END
+	END Fib
+	
+	UNIT Fact
+		VAR res+, n- INTEGER
+		REG x INTEGER
+	INIT
+		x <- 1
+	PROCESS
+		res <- IF n = 0 THEN x END
+		x <- IF n # 0 THEN x*n ELSE 1 END
+		n <- IF n # 0 THEN n - 1 END
+	END Fact
+	
+	UNIT Top
+		REG x, y INTEGER
+		VAR fi Fib
+		VAR fa Fact
+	PROCESS
+		fi.n <- 10
+		x <- IF x = 0 THEN fi.res END
+		fa.n <- 10
+		y <- IF y = 0 THEN fa.res END
+	END Top
+
+В целом, как и в Lola, есть только инструкция присваивания. Точнее даже не присваивания, а ожидания. Вся активность модулей определяется итерациями инструкций внутри секции PROCESS. Формально, это статичное описание состояния, а не итерации, но исполнять иначе не получится. По завершению первой итерации модуль `Top` ожидает от `Fib` и `Fact` сообщений из выходного канала `res`, так как условие `x = 0` истинно.
+Наверное, так устроены все декларативные языки.

_backup/2015-07-17-подробнее.md

@@ -0,0 +1,44 @@
+---
+published: true
+layout: post
+---
+
+ 
+
+## Подробнее про придумку
+
+Конечно, вокруг модели акторов построена нехилая математика, точнее, физика. Так что в среде агентов должны соблюдаться физические принципы распространения и последовательности сигналов. Но они почти все интуитивно понятны, и кажется, что читаешь всякое капитанство.
+
+Попробую описать будущую модель среды и агентов. Напомню, есть агенты, у них есть входные и выходные каналы сообщений, в которые могут быть переданы собственно сообщения. 
+
+Изначально нет никого, в какой-то момент поступает команда на создание первого агента известного типа. Этот агент (Топ) может создать конечное число других агентов, а может и не создать. Создание агента равносильно объявлению переменной c типом -- идентификатором модуля.
+
+Создавая агентов, Топ посылать им сообщения во входные каналы и может производить запрос на значения из выходных каналов этих агентов. Но недостаточно сделать запрос на значение, надо дождаться ответа, таким образом, если после итерации есть запросы на значения, они должны быть удовлетворены. При этом очередная итерация Топа не может начаться без окончания всех вызванных ожиданий (не совсем ясно насчет дедлоков). 
+
+***
+
+Ситуация, когда Топ создает агентов, и не ожидает от них сообщений тоже возможна, при этом дальнейшей судьбой этих агентов Топ может не интересоваться, или интересоваться на общих основаниях, широковещательно (продумать этот момент)
+
+Пока рассмотрим случай когда мы создаем агента для выполнения работы с результатом.
+
+***
+
+В свою очередь созданные агенты (Фиб, Факт) реально вступают в действие после того, как возник запрос на их данные в итерации Топа, после ее окончания. Эти агенты получают так же сообщение во входные каналы `n`. 
+
+Фиб проверяет значение `n` и решает, что необходимо запросить значение для выходного канала у другого агента, попутно Фиб инициирует другого агента Фибi, которому передает значение входного параметра, уменьшенное на 1. Так как возник запрос, и больше нет действий, итерация завершается и переходит в состояние ожидания. Однако, если условие `n # 0` становится ложным, ожидание значения для `res` реализуется по месту, константой, и следовательно, итерация Фибi завершается, одновременно с этим отправляя сообщение Фибi-1, который тоже завершает ожидание. В итоге, в первоначальный Фиб придет значение n-го числа Фибоначчи.
+
+Факт поступает по другому. Он не инициирует своих собратьев, но вместо этого каждый раз передает нужное значение в собственный регистр `x`, который сохраняет значение между итерациями одного агента Факт (после завершения итераций регистр всё же пропадает). Так как выходное значение, которое требуется от агента не передано в выходной канал, итерация повторяется. Здесь возникает странный момент, что считать завершающей итерацией агента? Удовлетворение всех выходных сообщений, всех ожиданий и отсутствие выполняемых действий? И опять проблема дедлоков.
+
+Временной график
+
+|↓шаг|агент→|Top|Fib|Fact|Fib...|
+|:---:|---|---|---|---|---|
+|0||NEW||||
+|1||<-Fib, <-Fact||||
+|2|||NEW|NEW||
+|3|||<-Fib|@||
+|4||||@|NEW|
+|..||здесь порождаются Fib i-ые|..|..res<-|..|
+|N-3|||||res<-|
+|N-2|||res<-|||
+|N-1||x<-, y<-|||

_backup/2015-07-17-чо-тут.md

@@ -0,0 +1,19 @@
+---
+published: true
+layout: post
+---
+
+
+
+
+## Что это такое?
+
+Практикуюсь в изобретении бессмысленных вещей. После проекта [fw](https://github.com/kpmy/fw "fw"), в котором интерпретировался выхлоп уже готового компилятора, написание своего компилятора было неизбежным. Вот он и реализовался. Проект компилятора и интерпретатора. Все довольно упростилось, язык `LEAF` структурно даже проще обычного Оберона. Система типов банальная. Хотя есть комплексные числа. Но это простой тип, он не усложняет систему вообще. Зато списки есть, и множества для любых значений, и ассоциативные массивы. Все довольно примитивное. 
+
+Основная особенность в том, что все статическое. И передается по значению. Есть пара обобщенных типов: значение вообще и указатель на значение вообще, вот по указателю уже динамическое значение будет, в куче. Работа с ними (с значениями вообще) получилась неудобной,  ведь язык строго типизированный. 
+
+Зато структурно в языке всё очень по Дейкстре. Хотя он бы не одобрил такое обращение со сложными структурами (я про передачу по значению). Процедуры, два вида циклов (и никаких `FOR`), ветвление. Модульность уже по Вирту, почти как в Обероне. А пользовательских типов нет. Да и зачем, основная идея в том, что пользовательский тип это обязательно либо `RECORD` либо `ARRAY OF`, `RECORD` хорошо ложится на ассоциативный массив, а `ARRAY` на простой список. Дальше возникает кагбэ "проблема": тип полей и элементов массива не указать, в `LEAF` значение в списке всегда `ANY`. 
+
+Ну что тут поделаешь, язык `LEAF` как раз и нужен чтобы проверить, как оно вообще, жизнеспособна ли такая идея или нет. Первая версия компилятора и рантайма написана на `golang` где-то за месяц. Теперь надо остановиться и подумать, как это сделать эффективным и не глючным. 
+
+P.S. Этак можно и лолу переписать на `golang`, где бы только время взять.

_backup/2015-07-19-lomo.md

@@ -0,0 +1,16 @@
+---
+published: true
+layout: post
+---
+
+## Про LOMO
+
+Приступил к реализации [LOMO](https://github.com/kpmy/lomo), language of message objects, такой себе наследник LoLa, только вместо радиодеталей будут программные агенты.
+
+Язык декларативный, попроще чем LEAF в каком-то смысле, пока двигаюсь интуитивно, без EBNF и даже смутного понимания, как оно устроено в декларативных языках.
+
+![](http://s00.yaplakal.com/pics/pics_original/3/5/4/398453.jpg)
+
+Компилятор развиваю из наработок LEAF, только стараюсь переосмыслять и делать попроще и понадежнее, все же написание компилятора не является одной из основных целей, как в LEAF.
+
+

_backup/2015-07-20-to-ast-or-not-to-ast.md

@@ -0,0 +1,11 @@
+---
+published: true
+layout: post
+---
+
+
+## AST или не AST?
+Каждый раз возникает проблема, где хранить AST, хранить ли его вообще и если не хранить, то как быть?
+Однозначно хранить. Во-первых, изучать вывод компилятора в лог утомительно, лучше сразу сохранить структуру AST и поизучать ее на предмет ошибок. Во-вторых, AST должна быть слегка независима от модулей компилятора, поэтому лучше будет, если на момент передачи AST в интерпретатор/кодогенератор контекст компиляции уже будет потерян. И в-третьих, для экспериментальных языков выводом в AST все может и закончиться, ибо дешевле и проще проинтерпретировать AST, нежели писать кодогенератор для птичьих IR типа llvm.
+
+Для хранения AST уже перепробовал много разных форматов. Видимо, самый удобный все-таки XML, несмотря на общую многословность.

_backup/2015-07-21-добавил-вики.md

@@ -0,0 +1,7 @@
+---
+published: true
+layout: post
+---
+
+Вики-статьи проекта LOMO лежать будут [тут](https://github.com/kpmy/lomo/wiki).
+Тем временем, продвигаются работы по осмысливанию методом тыка параллельной модели работы агентов. Надо соблюдать осторожность с параллелизмом в Go. Иногда очень неприятные моменты проявляются.

_backup/2015-07-23-Работа-кипит.md

@@ -0,0 +1,20 @@
+---
+published: true
+layout: post
+---
+
+При работе над компилятором LOMO проявляются тонкие моменты, которые не были очевидны на бумаге. 
+
+Например, регистру присваивают значение и в следующей инструкции используют в качестве значения в выражении. Какое значение регистра должно быть использовано? 
+
+    UNIT Top
+    	REG x INTEGER
+    	VAR z INTEGER
+    PROCESS
+    	x := x = 0 ? 1 :: x = 1 ? 2 :: 0
+    	z := x
+    END Top
+
+При последовательном исполнении должно быть использовано обновленное значение. Но при параллельном исполнении такое поведение приведет к неявной ошибке, если вдруг инструкция чтения выполнится раньше инструкции записи. Поэтому регистр получает обновленное значение, которое будет доступно только в следующем такте. Проблема в том, что последовательная запись инструкций присваивания может сбить с толку.
+
+Такие вот тонкие моменты.

_backup/2015-07-25-Концепции-LOMO.md

@@ -0,0 +1,25 @@
+---
+published: true
+layout: post
+---
+
+Многие решения касаемо синтаксиса взяты из LEAF. Минимум разделителей, прямые заимствования из Оберона.
+
+Агентные системы тоже уже много где описаны. 
+В данном случае агенту соответствует одна программная единица - модуль. Модуль может содержать набор переменных и правила вычисления их значений (инструкции).
+
+Так как язык декларативный, инструкций существует ровно одна - присвоение. При этом присвоение каждой переменной может быть выполнено лишь один раз. Неважен и порядок следования присвоений, так как предполагается, что они будут выполнены по сути одновременно. 
+
+При этом, конечно, на реальных машинах будет задействована блокировка чтения значений из переменных до момента записи вычисленных значений, однако в работе с LOMO не стоит учитывать на этот факт, так как нарушается абстракция.
+
+При таком подходе иначе выглядит модульность. Модули всё так же представляют клиентам переменные для чтения и записи, но при этом все модули исполняются параллельно, а для клиентов модули представлены как экземпляры объектов, хранящиеся в переменных. Работа всех модулей начинается одновременно, и здесь действует то же правило доступа к переменным, что и внутри одного модуля, чтение значения возможно только после записи. 
+
+Таким образом реализуется принцип *передачи сообщений* между агентами. В явном виде описывать передачу сообщений нет смысла, присвоение значения конкретной переменной конкретного модуля и есть передача сообщения. Такой способ также способствует унификации инструкций - передача вовне и локальное присвоение становятся единой инструкцией.
+
+При этом существенно разделяют переменные только для чтения и переменные только для записи. 
+
+Таким образом реализуется *восприятие* и *активность* агента. Агент воспринимает входящие значения и порождает новых агентов и исходящие сообщения.
+
+Отдельным видом переменных является регистр. Если обычные переменные возникают при старте агента и пропадают при его исчезновении, то регистры способны запомнить информацию между циклами жизни агента. При этом принцип единственного присвоения распространяется и на регистры. А так же значение, присвоенное регистру станет доступно для чтения только в следующей жизненном цикле агента. 
+
+Таким образом реализуется внутреннее состояние агента/системы агентов.

_backup/2015-07-29-Интеграция.md

@@ -0,0 +1,14 @@
+---
+published: true
+layout: post
+---
+
+Как и следовало ожидать, после того как я полностью скопировал фичи типов данных из LEAF, идея интегрировать LEAF в LOMO в качестве особого агента не заставила себя долго ждать. Так как LEAF-машина однопоточная, то никаких трудностей не возникло, выполнение работы обертывается в формат правила, входное сообщение передается псевдоагенту, а выходное поступает на запись в переменную обычного агента.
+
+    UNIT Top
+    	VAR x ANY
+    PROCESS
+    	<<"type": "ping">> \LEAF "TestEcho"  -> x
+    END Top
+
+Типа того.

_backup/2015-08-01-Применение.md

@@ -0,0 +1,8 @@
+---
+published: true
+layout: post
+---
+
+По прошествии некоторого времени после окончания периода активной разработки проектов LEAF и LOMO становится понятно, что примеров применения языков не найти. Возможно, Вирт изначально поcтупал более верно и разрабатывал язык общего назначения под конкретный проект, в котором язык проходил "крещение огнем" и дальше уже жил взрослой жизнью. Для новых языков, особенно концептуальных и минималистичных, как `lomo`, так просто проекта не найти.
+
+Одно из применений связке LEAF + LOMO мне видится в создании систем построения веб-страниц. Аналог HTML, но с большим уклоном именно в программирование всего подряд, тюринг-полноту каждой сущности, а не в text markup, как это видели в 90-х.

_backup/2015-09-28-Ад-концепций.md

@@ -0,0 +1,30 @@
+---
+published: true
+layout: post
+---
+
+Что если всё это время понятие *жизнь программы* недооценивали? *Жизнь*, а точнее, *жизненный цикл* программы можно описать повторяющейся последовательностью конечных процессов. Обязательно конечных, в каком-то разумном временном отрезке.
+
+Когда появляется программа? Скорее всего, программа появляется в голове у проектировщика/разработчика, можно назвать это *design-time*. Но так как этот момент не поддаётся контролю компьютера (пока), то предположим, что моментом появления программы является момент создания минимального запускаемого (о подробном смысле этого термина стоит поговорить отдельно) исходного кода. В контексте Оберона - программа рождается, когда появляется минимальный модуль.
+
+Затем, после этапа написания некоторого программного кода, программа передается компилятору. Компилятор обеспечивает т.н. *compile-time* - *время компиляции*. В результате выполнения процесса компиляции мы получаем компилят (то есть непосредственный результат обработки нашего исходного кода). 
+
+Во время компиляции наш исходный код влияет на работу компилятора по определенным законам, которые выражены в коде компилятора. В то же самое время, никто не мешает уже на этапе компиляции управлять действиями компилятора (точнее, исполнителя в целом) не опосредованно, через написание текста нашей программы, а непосредственно, через *написание кода общего назначения, который будет выполнен компилятором*, то есть такого кода, который хоть и относится к задуманной программе, но не переводится компилятором в компилят непосредственно. Так называемый [CTFE](https://en.wikipedia.org/wiki/Compile_time_function_execution), но в более общем смысле. 
+
+Понятно, что нахождение в контексте процесса работы компилятора может накладывать некоторые ограничения на *код времени компиляции*, однако может и не накладывать. 
+
+Здесь мы можем заметить, что выполнение любого процесса жизненного цикла предполагает наличие результата, в явном или неявном виде. 
+
+После получения компилята, над ним, сразу или отложенно должен быть исполнен процесс связывания или линковки. Так как компилят обычно хранится в файле, то возникает *время загрузки* - *load-time*. В это время над компилятом могут быть произведены дополнительные преобразования в код целевой платформы, и в это время может быть выполнен код времени загрузки, например, обработка компилята оптимизирующим компилятором. На данный момент известна только одна технология, **slim-binaries**, поздняя кодогенерация на целевой платформе, которая хоть как-то описывает время загрузки. 
+
+Обычно, линковка необходима, так как компилятор всегда производит компилят для одного модуля для непосредственного исполнения на целевой машине. Однако в реальной модульной системе на машине одновременно будут исполнены несколько модулей. Эта ситуация в многомодульной системе приводит к необходимости связывания. В старых системах связывание могло производиться непосредственно после компиляции, но этот вырожденный случай мы не рассматриваем. Итак, возникает *время связывания*, или *link-time*. 
+
+Мало что известно про выполнение кода во время связывания, однако понятно, что в момент связывания возможно выполнение кода, например, Dependency Injection и динамического наследования, как это может быть реализовано в рамках работы внутри jvm. Такой контроль над еще не запущенным в действие, но уже готовым к исполнению кодом программы позволяет реализовывать автоматизированную настройку и так далее. После связывания и настройки код непосредственно готов к запуску.
+
+Запуск и дальнейшая работа. Представлены *временем инициализации* (init-time) и *временем исполнения* (run-time). В сущности, результат работы этого этапа жизненного цикла и является обычно непосредственной целью написания программы. Можно дополнительно выделить *время завершения* работы программы (close-time). Однако сейчас все три времени работы обычно принято называть *run-time*, а логическое деление на три этапа реализовывать уже в рамках клиентского программного кода. Такой подход снижает требования к среде исполнения (run-time environment) но не дает гарантий исполнения того или иного этапа в нужной последовательности из-за возможных ошибок исполнения (run-time error) после которых исполнение, обычно, должно завершиться аварийно.
+
+Отдельным важным временем жизни программы является *посмертное время* (death-time), в которое, вопреки распространенным представлениям тоже является частью жизненного цикла программы. Объяснение тут простое, так как целью работы программы обычно является некий результат, обычно зависящий от входных данных, которых может быть очень много, программы строятся с применением методов, позволяющих итеративно обрабатывать входные данные и производить выходные данные, которые могут быть поданы на вход следующей итерации. Обычно такие данные структурированы (БД), версионны и их содержимое и интерпретация зависит от реализации работающей программы. То есть, программа это алгоритмы и данные, в том числе внешние и степень связанности этих внешних данных с программой никак не влияет на сам факт наличия такой связанности на любом этапе жизненного цикла.
+
+Проще говоря, программа запущенная вновь будет работать по разному, в зависимости от результата, который был ею же получен на прошлом этапе жизненного цикла. И если внести в эти данные изменения во время, которое программа не запущена, программа тоже будет работать иначе, то есть, внося изменения в данные мы программируем программу работать иначе. Что есть этап жизненного цикла программы.
+
+Итак, рассмотрены этапы жизненного цикла программы: *compile-time* -> *load-time* -> *link-time* -> *init-time* -> *run-time* -> *close-time* -> *death-time*. 

_backup/2015-09-29-Больше-ада-концепций.md

@@ -0,0 +1,8 @@
+---
+published: true
+layout: post
+---
+
+В [дополнение](http://b.ocsf.in/2015/09/28/%D0%90%D0%B4-%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D0%B9/) необходимо отметить, что можно обоснованно выделить *design-time* в отдельную категорию, но не как процесс в голове разработчика, а чисто утилитарно, опираясь на процесс кодирования. Здесь можно описать автокомплит, автоподсветку (как уже реализованные программы), программирование макросов ide, генерацию схем БД и ДРАКОН-схем, и так далее. То есть, уточненная последовательность одной итерации жизненного цикла программы будет представлена как: *design-time* -> *compile-time* -> *load-time* -> *link-time* -> *init-time* -> *run-time* -> *close-time* -> *death-time*.
+
+![](https://raw.githubusercontent.com/kpmy/kpmy.github.io/master/_posts/code-life-line.png)

_backup/2015-10-04-Шаблонизатор.md

@@ -0,0 +1,63 @@
+---
+published: true
+layout: post
+---
+
+Вернулся к обдумыванию применения `LOMO` и `LEAF` в качестве языка для описания объектов и процесса их построения, проще говоря, в качестве шаблонизатора.
+
+Основная идея такая. Определяется некий контекст. Пока неважно какой, главное, в нем возможно создание объектов и их сохранение после завершения работы условного шаблонизатора.
+
+Объекты представляют собой суть ссылку на класс и любое пользовательское содержимое, выраженное в форме составных типов `MAP`, `LIST` и, возможно, `SET`. Это даёт возможность описывать всевозможные отношения объектов и их свойства.
+
+Важным свойством шаблонизатора будет возможность обращения к данным, которые размещены в контексте.
+
+А еще более важным свойством будет являться возможность описывать императивный и декларативный код (на `LEAF` и `LOMO`, соответственно) непосредственно в теле шаблона, и такой код будет полностью легально создавать куски шаблона, менять свойства объектов и обращаться к данным в контексте.
+
+Долго пришлось подумать над базовой концепцией шаблонизатора, которая позволила бы реализовать подобные возможности. Эта концепция, в общем, проста. Шаблон будет компилируемым. А вариация синтаксиса для описания объектов будет представлять собой то, что могло бы получиться у авторов XML, если бы они знали про Оберон.
+
+    core.template(my-perfect-page):
+        core.import! context html;
+        html.body(root):
+        	br: enhanced;
+        	br
+        	br:
+        		type: page;
+        		fp = 344H;
+        	;
+        	`ffe`
+        	para(see-my-text):
+        		`first i was like`
+        		bold: `smth`;
+        		`, but then i `
+        		italic: `lol'd`;
+        	;
+        	table:
+        		len = context.len;
+        		do!
+        		var i integer
+        		begin
+        			while i < context.len do
+        				this:
+      					tr: hidden;
+                          text = @see-my-text;
+        				;
+        				parent:
+    					   count = i + 1;
+
+        				;
+        			end
+        		end;
+        	;
+        ;
+      ;
+
+Вполне вероятно, это будет выглядеть вот так. Капс скорее всего тоже будет применён (хотя кто знает).
+
+Итак, что мы видим: шаблон представляет собой вариацию на тему модуля Оберона. Базовые правила описания объектов: класс (существующий, импортированный, стандартный или вновь созданный) (core.template, core.import, html.body, br и т.д.), затем опциональный идентификатор конкретного объекта (для модуля обязательный), потом модификатор доступа к содержимому: `:` - обычное содержимое, `!` - специальное (мета)содержимое, `=` - уникальное (в рамках родительского объекта) содержимое. Возможно также описывать объекты заданного класса без содержимого. Особенностью будет необязательная квалификация классов внутри объекта с классом, импортированным из других шаблонов. Для html-шаблонов это будет немаловажным фактом.
+
+Внутреннее содержимое объекта определяется как перечисление идентификаторов классов объектов и управление содержимым этих объектов. Кроме этого, содержимым объектов может быть любая константа текстового, числового или любого другого допустимого в `LEAF`/`LOMO` простого типа. Возможно имеет смысл непосредственно представлять любой объект как аналог модуля `LOMO`, но непонятно, как быть с императивными вставками. Отдельно рассматривается возможность использования в качестве содержимого ссылок на объекты по идентификатору.
+
+Данный пример технической части является лишь наброском и возможно будет изменен, но базовая концепция постепенно формируется в прототип. Так, исполнение кода внутри шаблона будет доступно при его генерации. В принципе, этот код будет ничем не ограничен, но в нем будут доступны объекты, внутри которых он был вызван таким образом внутри кода будет возможность создания объектов контекста.
+
+В примере был выбран шаблон html как наиболее шаблонизируемого языка, так как создание html из шаблонов это довольно важная часть работы шаблонизаторов вообще.
+Результатом работы шаблонизатора над примером будет дерево объектов, которое может быть легко оттранслировано в html, провалидировано по требуемым правилам и так далее.

_backup/2015-10-05-Некоторые дополнительные мысли.md

@@ -0,0 +1,40 @@
+---
+published: true
+layout: post
+---
+
+* *Почему сначала класс объекта, а потом необязательный идентификатор (имя)?*
+  * Потому что шаблон принципиально работает с объектом еще до его создания, то есть, на самом деле шаблон для разработчика и для шаблонизатора должен формировать новый объект из заданного класса. Зачастую, этого достаточно, а если недостаточно, то уже можно обращаться к конкретному объекту.
+* *Как будет обеспечиваться модульность шаблонов?*
+  * Скорее всего, модульность шаблонов будет обеспечиваться таким же образом, как и в `LOMO`, то есть, вложенных шаблонов не будет, один шаблон - одна импортируемая сущность. Что не исключает возможности группировки шаблонов в подсистемы чисто организационно, на уровне файловой системы и полного квалификатора имени. Так же возможно будут экспортированные константы и объекты внутри сущностей (например, стандартные аттрибуты html).
+* *Шаблоны декларативные или императивные?*
+  * Описание шаблона мультипарадигменное, тут и декларативная часть, и императивная часть и работа с контекстом, который каждый раз меняется под действием самого шаблона.
+* *Процедуры и модульность внутри `LEAF`, импорт юнитов в `LOMO`?*
+  * Так как менять языки не хочется, скорее всего импорт из любого модуля будет возможен на этапе выполнения шаблона. Допустим это будет выглядеть так:
+
+        CORE.TEMPLATE(my-little-tree):
+          CHESS:
+            DO! IMPORT Strings
+
+              PROCEDURE Invert
+                VAR i+, o- STRING
+              BEGIN
+                o := i[\LEN i .. 0] (* range-нотации пока нет в LEAF *)
+              END Invert
+
+            VAR s STRING
+            BEGIN
+              Invert(o: "K F G", i -> s)
+              THIS: move = s;
+            END;
+            CALC!
+              VAR x INTEGER
+            PROCESS
+              2 -> x
+              x ^ 2 -> THIS number;
+            END;
+          ;
+        ;
+
+* *Громоздко!*
+  * императивный код -> декларативный код -> шаблонный код, чем дальше тем хуже. Но попробовать стоит. Конечно, для поддержки инструкций шаблонов внутри встраиваемых языков их компиляторы придётся доработать, но формально это останутся те же языки с полным набором фич. Заодно можно попробовать наконец-то сделать обобщенную кодовую базу для всех языков.

_backup/2015-10-12-Первый-прототип.md

@@ -0,0 +1,29 @@
+---
+published: true
+layout: post
+---
+
+Первый прототип языка, парсера и объектной модели готов, подробности в [вики](https://github.com/kpmy/ot/wiki). 
+По результату тестов можно отметить, что неявная квалификация даже в контексте текстовых человекочитаемых шаблонов есть фича неоднозначная. 
+
+В остальном всё довольно просто прошло, парсер -> объектная модель -> контекст. Даже немного боязно, не упустил ли чего за кажущейся простотой. 
+Сомнения вызывает точка, как разделитель в квалификаторе, она не позволяет использовать точку, как часть идентификатора, хотя в роли квалификатора точка довольно органично смотрится. 
+Сегодняшний формат выглядит примерно так:
+
+    module.class(id): content;
+
+Куча вариантов было отброшено:
+
+    module>class(id)
+    [module]class(id)
+    module:class(id)
+    
+В последнем варианте двоеточие смотрится неплохо, как в xml namespace, но это сразу убивает возможность использования двоеточия, как негромоздкого символа, открывающего содержимое объекта.
+
+*UPD:* Всё же не смог пожертвовать точкой в идентификаторе и на свежую голову придумал разделитель вместо точки: `~`.
+
+    module~class(id): content;
+
+Конечно, пока никаких языков программирования встроить не требовалось, да и задача постепенно усложняется, так как встраивание требует модификации парсера, что может серьёзно повредить его, простой как сапог, сути. 
+Возможно, встраивание ЯП должно выглядеть иначе, чем задумывалось в посте с рассуждениями.
+

_backup/2015-10-21-Застрял.md

@@ -0,0 +1,22 @@
+---
+published: true
+layout: post
+---
+
+После первого прототипа дело o.t. застопорилось и неспроста.
+Я начал повторять шаги, по которым до меня прошло уже много людей и коллективов, а с коллективами тягаться смысла нет.
+Поэтому всякие плюшки типа аналога xpath или применения relaxng теперь кажутся неинтересными.
+
+Со встраиванием языков программирования тоже проблема. Получается, что нет возможности встроить языки в шаблонизатор на уровне библиотеки и необязательного компонента.
+Уже на уровне сканнера символов сталкиваемся с необходимостью двух различных обработчиков одного и того же символа, что само по себе лишает сканнер обероновской простоты.
+Возможно на этом этапе стоит оформить сканнер и парсер по-другому.
+
+Что тут можно предложить?
+
+* Первой на ум приходит мысль о модели производитель-потребитель. Сканнер становится нерасширяемым и монолитным и потребляет любой символ, даже тот, который ему незнаком. Минус очевиден, вся работа по осознанию семантики прочитанного становится задачей потребителя, что не очень хорошо с точки зрения разделения ответственности.
+
+* Второй способ довольно банален, монолитный парсер со сменными стратегиями разбора символов. Сканнер включает в себя сразу все возможные символы и предопределенные идентификаторы. Минус очевиден, возможные интерференции между синтаксисами языков внутри сканнера. Сложный компилятор с кучей дублирующегося по сути кода для разных режимов разбора, что почти не решается шаблонизацией или обобщением. Просто чуть разный, но однообразный код.
+
+* Третий способ полностью противоречит исходному желанию органично встроить исполняемый код в шаблон, мне придётся реализовать код в шаблонах как полностью отдельную сущность и разделять их с шаблоном уже на уровне текстового представления. Удобный, но антиконцептуальный способ.
+
+Одно понятно, задача нетривиальная и малой кровью переиспользования существующих компиляторов `leaf/lomo` как мне кажется нерешаема. Может быть, для начала стоит перевести на общие рельсы имеющиеся системы, что в целом равносильно их переписыванию.

_backup/2015-10-28-Очередной-язычок.md

@@ -0,0 +1,28 @@
+---
+published: true
+layout: post
+---
+И снова от безделья появляются идеи написать очередной (да) язык. Оглядев `LEAF`, `LOMO` и `o.t.` для себя понял, что многие идеи хоть и звучат разумно, но выглядят при этом совершенно отвратительно.
+
+Чего стоит хотя бы вызов процедур, обязательно указывать именование входного параметра это конечно хорошо, но во-первых, их не всегда помнишь, а во-вторых, конструкция получается очень сложной.
+
+    Call(x: 1, y <- my.y, res -> x)
+
+Сложновато, как не крути. Получается, что порядок аргументов процедуры важен.
+Из этого вытекает необходимость в сигнатуре процедуры описывать всё именно так, как в Обероне `PROCEDURE Call(x: INTEGER; IN y: INTEGER; OUT x: INTEGER)`, что конечно неплохо (в очередной раз удивляюсь продуманности Оберона), но не оставляет пространства для маневра. И еще в этой форме записи всего полшага остаётся для признания процедуры функцией, со всеми вытекающими последствиями.
+
+И таких моментов много. Навигация внутри `MAP` требует постоянного разыменования значения. Так как цепочки селекторов я не реализовал, навигация требует ещё и кучи временных переменных.
+
+Сами селекторы, как показал `LOMO`, тоже могут быть довольно нетривиальной сущностью. Тут проходит трудноуловимая грань между строгой и нестрогой типизацией, когда цепочки селекторов должны неявно разыменовывать значение. А это значит, что на каждом этапе разыменования внутри может оказаться `UNDEF`-значение или вообще примитивный тип.
+
+Плюс к этому, сама идея разных языков с очень похожей (очень) системой типов намекает на то, что по факту это как будто один язык, мультипарадигменный, но при этом принципиально по-разному обращающийся с рантаймом и переменными. А ведь иногда действительно декларативный подход выглядел бы лучше и проще даже внутри полностью императивного кода. Но смешение парадигм это довольно опасная дорожка.
+
+А тут ещё и язык шаблонов сам собой нарисовался. Простой способ описывать всякие объекты, произвольной природы, но при этом человекотипизированные (то есть человек понимает семантику чисто из описания, из текстового представления шаблона объекта). Интересные возможности открываются.
+
+При этом недостатков в `o.t.` тоже хватает, например, необходимость закрывающего элемента, обозначающего конец содержимого. Никак я не придумал способ обнаруживать конец содержимого автоматически.
+Так же плохой идеей было переиспользование объектов. Точнее, идея хорошая, но по факту получилось слишком сложно, как в разборе, так и в понимании.
+А еще я не реализовал программирование внутри шаблонов, не осилил. Отсюда, в общем, и мысли о новом язычке, в котором, ну правда-правда, всё будет идеально продумано и реализовано.
+
+Главное не перечитывать пост про жизненный цикл программы, а то можно до конца года так и сидеть, продумывая каждый этап.
+
+В общем, пройдя по пути создания императивного языка, декларативного языка и языка разметки я снова оказался в начале пути.

_backup/2015-11-01-Непонятно.md

@@ -0,0 +1,7 @@
+---
+published: true
+layout: post
+---
+Сильно интересный вопрос, какой выбрать язык и платформу для реализации очередного язычка, а заодно и опять думаю, надо ли вообще этим заниматься...
+
+Вопрос не праздный. 

_backup/2015-11-04-Такая-мысль.md

@@ -0,0 +1,18 @@
+---
+published: true
+layout: post
+---
+
+Так как прошлые язычки в основном про алгоритмы (декларативные/императивные), и только чуть-чуть про данные (в виде dom), то логично предположить, что надо расширить эксперименты на системы типов и прочее.
+
+Проблема в целом известная, любой пользовательский тип данных почти всегда лишён возможности описать для этого типа литерал в пользовательском формате, операции тоже зачастую неприменимы. Перегрузка операторов и прочее это конечно зло. Но что может быть концептуальным решением этой проблемы?
+
+В Оберонах выбран путь классического наследования. В КП добавлены абстрактные и полу-абстрактные типы, разделение доступа к методам при переопределении. В go вообще наследования нет, как такового. Множество вариантов.
+
+Отдельным пунктом можно отметить псевдонимы и/или расширение пользователем примитивных типов, базовых сложных типов.
+
+Так же встаёт вопрос о необходимости встроенных в язык сложных типов данных, типа `MAP` в `LEAF`.
+
+Если программы, это алгоритмы + структуры данных, и с алгоритмами мы уже разобрались, надо переходить к структурам данных.
+
+Решил начать издалека и как-то обобщить предыдущий опыт разработки компиляторов в виде [универсального сканнера/полупарсера](https://github.com/kpmy/tier) для будущего проекта.

_backup/2015-11-05-Не-всё-так-просто.md

@@ -0,0 +1,14 @@
+---
+published: true
+layout: post
+---
+
+Довольно быстро выяснилось, что, так скажем, обобщить парсер невозможно. Есть возможность выделить в парсерах похожих языков некоторые одинаковые части, но на этом обобщение и закончится. Потому что даже разбор выражений зависит от определенной конкретной грамматики. Беглый поиск не дал информации о каком-то способе обобщения любых выражений (expressions) хотя бы арифметики. И это 2015-й год. Каждый лепит что-то своё, у кого `OR`, у кого `||`, у кого `or`, у кого `^`, у кого `**`, `=`, `->`, `:=`, и так далее, про целочисленное деление вообще молчу. Позорище вселенского масштаба. Никакой возможности обобщить и унифицировать.
+
+Не зря Н. Вирт не стеснялся дублировать код компилятора от проекта к проекту, раз за разом, жестоко нарушая принцип DRY, чем очень злил вчерашних школьников, угоревших по всяким красивым принципам, манифестам, высерам Макконелла и так далее.
+
+Ну ничего, даже в варианте с частичным обобщением уже нарисовался один важный паттерн потоковой обработки текста исходника. Его я и описал в соответствующем интерфейсе. Ещё из того, что я помню из разработки компиляторов, всегда было костыльно-проблематично описать результат работы компилятора.
+
+У Вирта это был непосредственно генератор маш.кодов, минимальный объект с кучей полей, сразу видно, автор выделил минимум и его держался. У меня это превратилось в набор билдеров и холдеров, билдер содержит непосредственный результат разбора исходника и производит внутренние трансформации, холдер принимает на хранение результат работы билдера, часто это AST и вспомогательные индексы переменных, полей, параметров и модулей. Довольно странная структура, возможно, она тоже никак не обобщается.
+
+В итоге получится инструментальный набор юного компиляторщика, не иначе. 

_backup/2015-11-15-ПЕАР.md

@@ -0,0 +1,6 @@
+---
+published: true
+layout: post
+---
+
+[![IMAGE ALT TEXT](http://img.youtube.com/vi/R-QBqT9RQAM/0.jpg)](http://www.youtube.com/watch?v=R-QBqT9RQAM "28 панфиловцев")

_backup/2015-12-08-Плюгавые-пйоки.md

@@ -0,0 +1,7 @@
+---
+published: true
+layout: post
+---
+Это будто записная книжка. Всё равно никто не видит. Скука одолевает, ничего невозможно придумать, удержать мысль трудно. Вычислители уже делают всё, что нужно, сомнительно, что придумается что-то новое. Даже этот пост уже давно потерял связь с собственной причиной. Что-то хотелось описать, разложить. Что?
+
+Блоки.

_backup/2015-12-30-Люстрировали.md

@@ -0,0 +1,51 @@
+---
+published: true
+layout: post
+---
+*Написал тут статью на хабр. Она долго лежала в песочнице. Потом я её вроде хотел поредактировать. Сохранил заново, видимо, она попалась на глаза модератору. Он её сначала пропустил на сайт, там её, конечно, заминусовали. А потом удалили вообще, сказали, что ошибка модератора. Такой день.*
+
+*Текст статьи, раз уж на хабре её не ждут*
+
+Оригинал тут:
+[http://habrahabr.ru/post/274355/](http://habrahabr.ru/post/274355/)
+
+
+## Бессилие умнейших или habralang...
+
+Сколько стоит разработка инфраструктуры разработки? Чем собрать сборочный цех? Как запустить систему запуска? На все эти интересные вопросы приходится отвечать, когда приступаешь к очередному проекту. Когда ТЗ утверждено, наступает мучительный период выбора подходящих технологий. Кто-то выбирает фреймворк, кто-то прочёсывает каталоги расширений, кому-то нужны шаблоны. Всех этих людей объединяет одно — они не создают уже существующих фреймворков, не реализуют расширения, аналогичные зарегистрированным в каталоге, новых шаблонов тоже не пишут. Не плодят велосипеды. Не повторяют себя других. Решает задачи бизнеса оптимальным образом.
+
+Работа в таком стиле неизбежно влияет на общие профессиональные навыки. Схожие профессиональные навыки многих людей формируют критерии оценки. Критерии становятся основой запросов индустрии к внешнему миру, к системе образования, к соискателям и даже к заказчикам.
+
+Вполне нормальной считается ситуация, при которой знание определённых фреймворков (даже в отрыве от понимания их внутреннего устройства) выглядит преимуществом соискателя, а знание теории никак не влияет на успехи в поиске работы.
+
+Можно привести пример многих ситуаций, каждый из которых только будет подтверждать нашу гипотезу о том, что удивительный мир программирования в своей основе почти всегда содержит массовые инфраструктурные продукты, проверенные временем. Это касается языков программирования, фреймворков и так далее.
+
+И возвращаясь к началу рассуждения, постараемся дать ответ, кто же стоит за этими инфраструктурными продуктами? Две, три, десять компаний? Несколько консорциумов, в составе которых те же десять компаний? Да, стоит признать, что понятие монополий применимо не только к рыночным игрокам. Дальше больше. Так как технологии работают непосредственно, их нельзя юридически извратить, к ним нельзя применить процедуру банкротства или реорганизации, получается, что степень привязки ваших продуктов к инфраструктурным продуктам крайне высока. А где привязка, там и контроль. Влияние экосистемы на ваш продукт, ваш стиль работы, ваш разум, в конце концов.
+
+Влияние экосистем нельзя было не заметить, и в какой-то момент это стало настолько очевидным, что даже холивары сошли на нет, так как зачастую люди из разных экосистем одинаковые слова интерпретируют по-своему. Особым образом смотрят на мир. Возникает несовместимость не только бинарных протоколов и объектно-реляционных моделей. Возникает несовместимость мировоззрений, и устранять её никто не намерен. Разделяй и управляй. При этом производители инфраструктурных продуктов готовы их даже бесплатно раздавать. Потому что понимают. Асимметрия информации работает на благо десяти компаний.
+
+Ну и что плохого, спросите вы, это лишь разделение труда. Тут очевидный ответ один. Инфраструктурный проект не является целью работы компании. Целью работы компании является зарабатывание денег. А инфраструктурный проект это просто способ превратить много денег в средство привязки и контроля. К конкретной компании. Которая может пойти на дно. Которая может перестать вас любить. Google больше не против зла.
+
+Ответной мерой, как многим кажется, является опенсурс-движение. Однако его возможности ограничены уже на уровне определений. Сложные многолетние проекты просто не потянуть. Никак. Ядро Linux? А сколько коммитов, в процентах, исходит всё от тех же корпораций. По сути, весь опенсурс это соглашение о влиянии корпораций в нейтральных водах. Специальная матрица для врагов матрицы. Выхода нет.
+
+А ведь есть ещё и государства. Пока не устарели, не ушли в прошлое, как многим хочется. Государства имеют интересы, часто противоположные. А корпорации, возможно вопреки своему желанию, всё ещё существуют в рамках конкретных государств и волей-неволей, подчиняются законам этих государств. Следовательно, в какой-то момент международный бизнес и ИТ-шники всей планеты могут оказаться прежде всего лишь гражданами совершенно чужих государств. И поток уже существующих шаблонов, библиотек и фреймворков может прекратиться. Речь тут даже не о патриотизме и оппозиционности к власти государств, это банальный расчёт, если есть зависимость, разрешение которой зависит от факторов, которые вы не контролируете, то в один прекрасный момент зависимость просто не разрешится, проект не соберется и зарплату не выплатят.
+
+Решений много, прежде всего предложат — «валить». Власть или в Америку. Неважно. Мы тут про ИТ. Наукоёмкие проекты. Веб-магазины в конце концов. Инфраструктура не зародится от сквозняка, даже если вы умнейший человек в стране и решили остаться ради принципа.
+
+Исходя из всего этого лично мне с течением времени всё меньше понятны высказывания о ненужности существования в рамках отдельно взятой страны проживания, в великой и могучей Российской Федерации своей операционки, своих телефонов, своих языков программирования для разных сфер деятельности. Своё просто необходимо. А нету. А что есть? А есть смешки, шуточки и презрительный взгляд. «Опять болгенос, фуфу йоптафон, хахаха язык Дракон». И это понятно. Но непонятно, а на что же вы расчитываете?
+
+Уйдут инженеры, программисты, забросят свои болгеносы, будут писать на этой вашей джаве, пока её не отключат. Все же пишут, вы что, самые умные чтоли? Интеллектуальное производство, напряжение ума. Думающие люди со светлыми лицами и европейским мировоззрением в свободное от работы время занимаются тем, что отговаривают коллег по цеху пилить РеактОС? Способы отговаривания тоже заслуживают внимания. Бери чужое, свой велосипед — это удел неразумных людей. Всё равно не получится так же качественно.
+
+Конечно не получится, ребята. Ведь «там» люди делают своё. «Там» первородство. А «здесь» не делают своё. И не научатся. А кто умел, те разучатся. Или разучат. Это мы можем, с этим у нас всё просто. А ну, ребята, навались на выскочек и недоучек.
+
+Даже стране уже не нужно воспитывать фанатов чужого. Она сама об этом говорит. Через обмуд омбуд одбум через своих глашатаев. Скоро и программистов своих не станет.
+
+А заголовок ведь как раз про это? Кажется, целое поколение мировоззренчески не желает иметь ничего своего. И это объяснимо, это нормально. Но разумные люди должны уже наконец сделать выбор. Удручающая картина, тридцатилетние покорители ИТ-вершин бесплодно завершают своё творческое существование в Этой Стране, где место проклято и ничего не растёт, кроме коррупционеров. Но даже им нужно что-то своё, а вам?
+
+А, ну «Эльбрусы», да. С компилятором американских язычков программирования Си/Си++.
+
+На основании всех входных параметров алгоритм вычисления того, как нам дальше жить, должен дать ответ. Где habralang? Где продукт вашего ума сделанный так, как это нужно лично вам? В «Долине»? В Цюрихе? В Амстердаме? Может, в Чехии (где там jetBrains зарегистрированы вместе со своим Котлином)? Нужно нам своё или не нужно? Да или нет? 1 или 0? true или false? Или может, вспомним троичную логику?
+
+Где habra language? Хотя бы в виде обсуждения? На гитхабе, на их площадке, ну и что? Где проекты, предложения? Никого, ничего, пустота и функциональное программирование, на хаскелле. На каком языке говорил автор Хаскелля?
+
+*В комментариях сказали, что это ксенофобская хуйня. Ну вот и всё.*

_backup/2016-03-23-По-Чапаеву.md

@@ -0,0 +1,9 @@
+---
+published: true
+layout: post
+---
+*"Ты, Петька, прежде чем о сложных вещах говорить, разберись с простыми."*
+
+А ведь с простыми вещами ещё Дейкстра разобрался. А потом умники начали говорить, что надо прогресс и усложнили всё. Теперь только умный человек может понять подавляющее большинство концепций computer science.
+
+А я не могу. 

_backup/2016-04-28-Про-WebAssebly.md

@@ -0,0 +1,12 @@
+---
+published: true
+layout: post
+---
+Wasm это значит такая технология, которая как бы slim-binaries, но в 2016-м.
+И оно конечно даже клёво выглядит, подумать только, кто-то додумался наконец-то объединить идею AST и доставки исполняемого кода клиенту.
+
+В сегодняшнем варианте у wasm нет даже устоявшегося текстового представления, но в целом, технология мне нравится, даже сделал для неё смешной демо-проект: [brainfuck2wasm](https://github.com/kpmy/tiss/tree/master/demo/bf)
+
+Конечно, в РФ сегодня не найти людей, серьёзно устремлённых на построение собственной экосистемы. Поэтому остаётся следить, чем же там заняты зарубежные прогрессивные личности. Вот, М. Франца копируют.
+
+Разработчик wasm обещает смену текстового представления в ближайшие месяцы, поэтому наверное подожду этого этапа, там и созрею до построения компилятора очередного обероноподобного языка для wasm. Хотя, кому это надо.

_backup/2016-04-30-Монополист-то-голый.md

@@ -0,0 +1,9 @@
+---
+published: true
+layout: post
+---
+
+Подумал тут, что Habrahabr как объединение умов русскоязычных программистов уже давно стал монополистом, то есть никто другой уже не сможет вырасти рядом до конкурентноспособных размеров.
+Вместе с этим, внутри таких сообществ, как показали исследования, формируется своеобразная олигархия, в полном соответствии с железным правилом. Стало быть, и внутри сообщества монополизирована социальная мощь, следовательно, никакой движухи внутри быть не может, выбившихся со своей социальной роли тут же порешат богатые кармовладельцы. Порешат показательно, не взирая на нарушение мыслимых и немыслимых норм приличия в интеллектуальной и околонаучной среде.
+
+Войлок, что и говорить. 

_backup/2016-05-09-Изобретая-велосипед.md

@@ -0,0 +1,18 @@
+---
+published: true
+layout: post
+---
+
+Пришло время вспомнить про концепцию жизненного цикла программы. Вот его этапы:
+
+![](https://raw.githubusercontent.com/kpmy/kpmy.github.io/master/_posts/code-life-line.png)
+
+В ситуации недостаточных ресурсов для полноценной проработки этих этапов на уровне хорошей годной бинарной кроссплатформенности ничего не остаётся кроме как загнать всё это дело в эмулятор, виртуальную машину, которую можно реализовать для любой подходящей по возможностям экосистемы. А потом уже раскрутиться до полноценного продукта.
+
+В ожидании релиза webassebmbly можно выработать набор собственных примитивов, сводимых к wasm-примитивам, благо не нужно работать для бизнеса, на надёжность и окупаемость.
+
+Возможно ли минимальными выразительными средствами обеспечить приемлимую реализацию всего этого великолепия, пока не ясно.
+
+Плюс ко всему остался нерешённым вопрос совмещения декларативного и императивного подхода, многопоточного и однопоточного кода, возможности выполнения кода на разных вычислительных платформах (гетерогенные вычисления) и так далее.
+
+Короче, надо обозначить ближайшую цель: получить виртуализированную программную платформу, в которой возможна реализация и исполнение программных модулей, отвечающих концепции жизненного цикла программы.

_backup/2016-05-09-Про-Electron.md

@@ -0,0 +1,6 @@
+---
+published: true
+layout: post
+---
+
+Лет пять назад уже всем было понятно, что развитие отобразительных средств браузера идёт, а развитие отобразительных средств десктопного гуя остановилось. Не спасло даже Windows Modern UI. А теперь вот, совсем хорошо, гуй десктопного приложения строится в браузерном движке с помощью html/css/js. Такой мир. Этим мог стать BlackBox. Но не стал.

_backup/2016-05-13-Первые-результаты.md

@@ -0,0 +1,9 @@
+---
+published: true
+layout: post
+---
+За пару дней, с большой осторожностью, накидал прототип own2js-компилятора по мотивам lomo/leaf [тут](https://github.com/kpmy/own).
+Конечно, он пока больше завязан на nodejs, нежели на electron в целом, но получается, что electron, как устройство вывода должен появиться чуть позже.
+Язык `own` пока ничего из себя не представляет, концепцию я пока не придумал, но модуль описать/транспилировать/загрузить динамически уже можно. Ура!
+
+Если позиционировать этот продукт, как собственный вариант BlackBox, то нужно глубже погружаться в систему типов КП, так как управляющих инструкций в КП не так много, и они не самые важные (ну, кроме эффективного WITH). С другой стороны, кому нужен будет Оберон, всегда смогут взять `oberonjs`, тут почти ничего делать не потребуется, `own` же в целом должен быть в чём-то концептуальным, так что надо изучить системы типов народов мира :D

_backup/2016-05-25-Язык-твой-враг-твой.md

@@ -0,0 +1,22 @@
+---
+published: true
+layout: post
+---
+Конечно же, новый язычок не мог обойтись без гибкой концепции процедурных блоков. 
+
+````
+  BLOCK Add 
+  	VAR x, y, res INTEGER
+  	PAR x, y, res* FUNC res(x, y) 
+  BEGIN
+  	a + b -> res
+  END Add
+  
+  Add[1, 2, fx]
+  Add[x: 1, y: 2, res::fx]
+  Add(1, 2) -> fx
+  Add(x: 1, y: 2) -> fx
+  1 \Add 2 -> fx
+````
+
+Тут тебе и процедура, и процедура с переменным числом параметров, и функция, и наличие именованных параметров, и даже, не может быть, инфиксный вызов (надо ограничить его только для одного и двух операндов)!

_backup/2016-05-29-О-системе-типов.md

@@ -0,0 +1,27 @@
+---
+published: true
+layout: post
+---
+
+Развитие `Own/L` встало на стабильные рельсы. Каждый элемент цепочки (компилятор, кодогенератор, рантайм) сейчас позволяют в рабочем режиме добавить новую фичу языка без проблем.
+
+Появилось время подумать, куда двигаться дальше. Наибольшие опасения вызывает этап выбора системы типов. Про системы типов написано много умных слов, чем дальше, тем сильнее все эти слова сводятся к описанию имплементации системы типов в языке haskell, как будто ничего лучше человечество не придумало.
+
+Если не брать от безысходности готовую систему типов Оберона, а немного подумать, то ситуация ещё больше ухудшается. Во-первых, есть определённый провал между простым определением типа и его математическим развитием, все эти декартовы произведения, мощности и прочее.
+Отдельная проблема это обратный переход, так как математику развили хорошо, уже непонятно, как спуститься на землю, к числам, спискам и объектам.
+Взять, например, дескрипционную логику, которая является формальной основой для систем онтологий.
+Да, концепции, роли, индивиды, это похоже на типы, свойства и объекты. Но как именно перейти к тому, что будет понятно говнокодеру - не сказано.
+
+Опять же, Вирт в AD предлагает простые понятия, но он это всё предлагает с послезнанием, он уже знает всё это и говорит сразу правду, что не оставляет шанса дойти до всего самому.
+
+Надо думать.
+
+Пока что принимаем за отправную точку определение: *тип данных — допустимое множество значений объекта*.
+
+Данное определение сразу предъявляет ряд требований ко всей системе - наличие объектов и значений, возможность определить множество этих значений.
+
+Допустим, объекты это переменные и параметры процедур. Значения - это литералы и результат вычисления выражений, а так же константы (пока отсутствуют в языке).
+
+Первый вывод - могут быть объекты, которые принимают любое значение, точнее, значение любого типа. То есть, формально это будет объект с нулевым типом, без типа, но в языке со строгой типизацией это будет объект с типом `ANY`. При этом, предполагается, что значение так же может быть не установлено, чему соответствует значение `NONE`.
+
+Пока всё :(

_backup/2016-06-12-Типы-будут.md

@@ -0,0 +1,11 @@
+---
+published: true
+layout: post
+---
+
+Долго пришлось думать насчёт системы типов, в итоге решил сделать шаг в бесконечность и хотя бы что-то реализовать.
+Получилось странно, сначала пришлось добавить ТИП как встроенный тип данных, затем добавить АТОМ как идентификатор-значение, затем расширить АТОМ до структурированного значения из идентификаторов и констант (тут пригодился язык разметки o.t. имени меня), и только потом я дошёл до этапа описания пользовательского типа. В итоге пользовательский тип данных это интерпретируемое в compile-time и run-time значение структурного атома.
+
+Дальше основная работа пойдёт уже внутри структурного описания, это будет работа над какой-то моделью знаний, например, онтологическими предикатами и способом их описания.
+
+Будем посмотреть.

_backup/2016-07-01-Статейка-про-OT.md

@@ -0,0 +1,167 @@
+Неделя самописных языков разметки на Habrahabr. Статья про AXON напомнила мне про мой проектик `o.t` - object template language. В нём я соединил интересные идеи из XML, yaml и прочих.
+
+### Что, ещё один?
+
+Велосипеды бывают разные. Мне например, было интересно попробовать создать именно язык описания данных и в какой-то степени язык разметки.
+
+<cut text="что из этого получилось" />
+
+### TL;DR
+````xml
+<note status="saved">
+  <to>Tove</to>
+  <from>Jani</from>
+  <heading>Reminder</heading>
+  <body>Don't forget me this weekend!</body>
+</note>
+````
+
+````
+note:
+  status :: saved;
+  to: "Tove";
+  from: "Jani";
+  heading: 'Reminder';
+  body: `Don't forget me this weekend!`;
+;
+````
+
+### Концепция
+Изначально, хотелось что-то типа языка программирования внутри DOM, чтобы код всегда выполнялся в контексте того или иного узла, чтобы можно было осуществлять навигацию по DOM управляющими инструкциями языка, переменные и объекты рантайм маппит в DOM-узел контекста и т.д. и т.п. В итоге, первый вариант концепции успешно вылетел из памяти.
+
+Второй вариант намного проще, и вообще не про программирование, как таковое. Он скорее про шаблоны, в том виде, в котором они представлены в технологии JSP, когда xhtml перемешивается с управляющими элементами. При этом замечено, что jsp неплохо подходит для чистой шаблонизации, без программирования. Но там же XML, великий и ужасный.
+
+А что есть кроме, JSON, YAML и TOML (.ini на стероидах). Первый описывает примитивные типы, объекты и массивы javascript, второй делает то же самое, но без курли-скобочек, а третий вообще не о том. От XML их всех отличает только одно, они описывают объект через его свойства, предполагается при этом, что при необходимости, пользователь добавит объекту поле `type` и опишет класс объекта.
+В xml объект описывается непосредственно как экземпляр класса, и потом при необходимости могут быть указаны дополнительные поля, типа идентификатора.
+
+Что же будет, если объединить простоту YAML и концепцию объектов из xml? Правильно - object template language, экспериментальный человекочитаемый язык описания данных, структур и шаблонов..
+
+### O.T.
+Схематически, весь OT можно описать одной строчкой `module~class(id): content;` то есть это модульный язык рекурсивных объектных шаблонов. Кроме этого, присутствуют дополнительные типы данных помимо строк, и отсуствуют ассоциативные массивы, которые типа объекты из json, как неконцептуальная сущность.
+
+Помимо текстовых идентификаторов, строковых, булевых, целочисленных и вещественных констант присутствуют некоторые символы, позволяющие описывать древовидные структуры объектов (object model). Так же присутствует ссылочный тип для построения других видов структур-графов.
+
+Любое пустое пространство между идентификаторами, группами идентификаторов, символами разметки и константами игнорируется и используется для разделения значимых символов, но не включается в содержимое объекта. Внутри символов-кавычек любое пустое пространство учитывается.
+
+### Объектная модель
+
+Любой шаблон представляет собой один объект, который является корневым. Любой объект, в т.ч. корневой представляется как минимум идентификатором класса объекта, и опционально идентификаторами модуля и уникальным идентификатором объекта:
+
+    module~class(id)
+
+Например, для html-страницы существует объект класса `body`, который может быть предварен идентификатором модуля, из которого взят этот класс (`html~body`). Этот объект наделяется идентификатором `index-page`, по которому можно установить связь с объектом через ссылку `@index-page`.
+
+    body
+    html~body
+    html~body(index-page)
+    @index-page
+
+Объекты могут быть вложены друг в друга, таким образом первый объект будет содержать в себе второй объект, устанавливается связь родитель-потомок.
+
+    html:
+      body
+    ;
+
+Внутреннее содержимое объекта начинается после символа `:`. Всё содержимое вплоть до соответствующего символа `;` будет считаться принадлежащим объекту-родителю. Если объект не предполагает содержимого, символы `:;` не указываются.
+
+При этом важно помнить, что обязательным для любого объекта является идентификатор класса объекта, то есть, два и более одинаковых идентификатора класса в шаблоне будут соответствовать двум и более экземплярам класса.
+
+    html:
+      body: br br br;
+    ;
+
+#### Повторное использование
+
+Для объектов, содержимое которых может быть описано в нескольких местах шаблона, возможно указать такой режим описания содержимого, при котором создание нового экземпляра класса не будет производиться, и всё содержимое будет принадлежать одному экземпляру данного класса в рамках родительского объекта. Это достигается использованием символа `::` открывающего содержимое.
+
+    xml:
+      attr ::
+        id: "my-xml";
+      ;
+      attr ::
+        xmlns: "urn:oberon:ot";
+      ;
+    ;
+
+В режиме повторного использования учитываются не только класс но и другие параметры объекта, его модуль и идентификатор.
+
+### Другое содержимое
+
+Помимо объектов-потомков, в родительский объект могут быть включены различные константы и ссылки на объекты. При этом для разделения отдельных элементов содержимого используется пустое пространство.
+
+    html:
+      head:
+        title: "Привет, Мир!";
+      ;
+      body:
+        p: 2 "+" 2 "=" 4.0;
+        concat: "Hello":':':"World":"!";
+      ;
+    ;
+
+Текстовое содержимое указывается в кавычках разных типов: `'`, `"`, и \`, при этом возможно указание отдельного символа текста в одинарных кавычках `'` и с помощью шестнадцатеричного кода (например `0DU`) с модификатором `U` на конце. Текст может содержать переносы строки и любые другие символы unicode. Есть возможность конкатенации строки и символов с помощью символа `:` расположенного между двумя и более частями строк. Результирующая строка будет представлена в объектной модели как одна строка.
+
+### Модульность
+
+Модульность в самом простом виде позволяет визуально разделять одноименные классы объектов различной природы. Например, `html~body` и `human~body`. Модульность в объектной модели предполагает так же наличие поддержки контекстом некоторых модулей, расширенная функциональность которых позволяет расширить возможности работы с шаблоном в рантайме.
+
+#### Стандартные модули и классы
+
+Стандартные модули предоставляют дополнительные возможности рантайма для объектной модели.
+
+##### core
+
+Модуль `core` является встроенным модулем, а так же базовым модулем. Для начала использования модуля `core` необходимо создать экземпляр класса `core~template` как корневой объект шаблона. Тем самым всё содержимое корневого элемента сможет обращаться к классам модуля `core`. В других случаях функциональность модуля `core` отключена.
+
+    core~template:
+      (* ваше содержимое *)
+    ;
+
+Модуль `core` предоставляет класс `import`, который позволяет описывать зависимости шаблона от сторонних шаблонов (стандартных, пользовательских, виртуальных и  т.д.).
+
+    core~template:
+      import: context;
+    ;
+
+Внутри объекта типа `core~template` действует неявное указание модуля для известных классов, таких как `import` и для импортированных классов действует такое же правило, поэтому нет необходимости (но возможность остаётся) указывать модуль `core` и другие импортированные модули каждый раз.
+
+Например:
+
+    core~template:
+      import: html;
+      html: body: p: "Привет, Мир!";;;
+    ;
+
+Классы `html`, `body` и `p` принадлежат модулю `html` и их принадлежность контролируется рантаймом, но при этом указывать их модуль явно не требуется.
+
+
+### Шаблонизация и пользовательские данные
+
+#### context
+Модуль `core` предоставляет класс `context` который является идентификатором модуля `context`.
+Модуль `context` предоставляет доступ к данным контекста существования объектной модели. Обращение к объектам модели через специальные классы модуля `context` позволит размещать в содержимом шаблона данные из рантайма.
+
+Например, класс `context~$` позволяет обратиться к данным контекста по идентификатору или иерархическому набору идентификаторов.
+
+    core~template:
+      import: context;
+      $(hello-world-text)`, `$(user-names/hello-world-user)`!`
+    ;
+
+Таким образом, в зависимости от данных, размещенных в контексте каким-либо образом и доступных по заданным идентификаторам, после обработки текста шаблона и построения объектной модели мы получим итоговый объект с заданными значениями.
+
+    core~template:
+      import: context;
+      `Здравствуй` `, ` `Дружок` `!`
+    ;
+
+### Реализация
+
+Первый прототип парсера был написан на golang, рядом были реализованы некоторые шаблонные модули, `core` конечно, и ещё модуль хранения бинарной информации в виде zbase32-строки, отличный формат, заслуживает отдельного упоминания дизайн-документ этого формата, как тщательно люди анализировали ситуацию с форматами baseXXX.
+В дальнейшем, был реализован неполный прототип парсера OT для javascript, который стал основой для языка описания структурных атомов в языке... а впрочем это уже другая история.
+
+### Ссылки
+
+* Репозиторий https://github.com/kpmy/ot
+* Дополнительные примеры в виде недотестов https://github.com/kpmy/ot/blob/master/ot_test.go
+* Обсуждение zbase32 http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt

_backup/code-life-line.svg

@@ -0,0 +1,49 @@
+<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill-opacity="1" color-rendering="auto" color-interpolation="auto" text-rendering="auto" stroke="black" stroke-linecap="square" width="206" stroke-miterlimit="10" shape-rendering="auto" stroke-opacity="1" fill="black" stroke-dasharray="none" font-weight="normal" stroke-width="1" height="797" font-family="'Dialog'" font-style="normal" stroke-linejoin="miter" font-size="12" stroke-dashoffset="0" image-rendering="auto">
+  <!--Generated by ySVG 2.5-->
+  <defs id="genericDefs"/>
+  <g>
+    <defs id="defs1">
+      <clipPath clipPathUnits="userSpaceOnUse" id="clipPath1">
+        <path d="M0 0 L206 0 L206 797 L0 797 L0 0 Z"/>
+      </clipPath>
+      <clipPath clipPathUnits="userSpaceOnUse" id="clipPath2">
+        <path d="M417 -151 L623 -151 L623 646 L417 646 L417 -151 Z"/>
+      </clipPath>
+    </defs>
+    <g fill="white" text-rendering="geometricPrecision" shape-rendering="geometricPrecision" transform="translate(-417,151)" stroke="white">
+      <rect x="417" width="206" height="797" y="-151" clip-path="url(#clipPath2)" stroke="none"/>
+    </g>
+    <g text-rendering="geometricPrecision" stroke-miterlimit="1.45" shape-rendering="geometricPrecision" font-family="sans-serif" transform="matrix(1,0,0,1,-417,151)" stroke-linecap="butt">
+      <text x="489.2363" xml:space="preserve" y="-93.2861" clip-path="url(#clipPath2)" stroke="none">design-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="-135.5" clip-path="url(#clipPath2)"/>
+      <text x="486.2422" xml:space="preserve" y="5.4639" clip-path="url(#clipPath2)" stroke="none">compile-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="-36.75" clip-path="url(#clipPath2)"/>
+      <text x="495.5732" xml:space="preserve" y="104.2139" clip-path="url(#clipPath2)" stroke="none">load-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="62" clip-path="url(#clipPath2)"/>
+      <text x="497.9141" xml:space="preserve" y="202.9639" clip-path="url(#clipPath2)" stroke="none">link-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="160.75" clip-path="url(#clipPath2)"/>
+      <text x="499.2471" xml:space="preserve" y="301.7139" clip-path="url(#clipPath2)" stroke="none">init-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="259.5" clip-path="url(#clipPath2)"/>
+      <text x="498.2451" xml:space="preserve" y="400.4639" clip-path="url(#clipPath2)" stroke="none">run-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="358.25" clip-path="url(#clipPath2)"/>
+      <text x="492.9102" xml:space="preserve" y="499.2139" clip-path="url(#clipPath2)" stroke="none">close-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="457" clip-path="url(#clipPath2)"/>
+      <text x="491.9023" xml:space="preserve" y="597.9639" clip-path="url(#clipPath2)" stroke="none">death-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="555.75" clip-path="url(#clipPath2)"/>
+      <path fill="none" d="M520.25 -60.5 L520.25 -44.75" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 -36.75 L525.25 -48.75 L520.25 -45.75 L515.25 -48.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 38.25 L520.25 54" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 62 L525.25 50 L520.25 53 L515.25 50 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 137 L520.25 152.75" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 160.75 L525.25 148.75 L520.25 151.75 L515.25 148.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 235.75 L520.25 251.5" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 259.5 L525.25 247.5 L520.25 250.5 L515.25 247.5 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 334.5 L520.25 350.25" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 358.25 L525.25 346.25 L520.25 349.25 L515.25 346.25 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 433.25 L520.25 449" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 457 L525.25 445 L520.25 448 L515.25 445 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 532 L520.25 547.75" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 555.75 L525.25 543.75 L520.25 546.75 L515.25 543.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
+    </g>
+  </g>
+</svg>

_layouts/post.html

@@ -7,19 +7,6 @@ layout: default
   <time datetime="{{ page.date | date_to_xmlschema }}" class="post-date">{{ page.date | date_to_string }}</time>
   {{ content }}
 </article>
-<div id="disqus_thread"></div>
-<script type="text/javascript">
-    /* * * CONFIGURATION VARIABLES * * */
-    var disqus_shortname = 'nobodyhere';
-
-    /* * * DON'T EDIT BELOW THIS LINE * * */
-    (function() {
-        var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
-        dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';
-        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
-    })();
-</script>
-<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript" rel="nofollow">comments powered by Disqus.</a></noscript>
 
 {% if site.related_posts != empty %}
 <aside class="related">

_posts/2015-07-17-го.md

@@ -1,10 +1,10 @@
----
-published: true
-layout: post
----
- 
-
-
-## Старт
-
-Ок, работает.
+---
+published: true
+layout: post
+---
+ 
+
+
+## Старт
+
+Ок, работает.

_posts/2015-07-17-лола.md

@@ -1,45 +1,45 @@
----
-published: true
-layout: post
----
-
- 
-## Изучая Lola
-
-Поизучал описание языка [Lola](http://www.inf.ethz.ch/personal/wirth/Lola/index.html), в итоге понял, что MODULE это такая радиодеталь с ножками, вход/выход, внутренние преобразования по заданным функциям, вот это всё.
-Подумал над применением в программировании акторов или агентов, ведь агент это та же радиодеталь, датчики как входы, манипуляторы, как выходы. На программном урове, это всё, конечно, укладывается в понятия направленного канала сообщений и сообщения. Сообщением в LEAF можно сделать любой тип данных, передавать можно значения, или даже указатели, если они будут защищены от записи.
-
-Придумалось тут:
-
-	UNIT Fib
-		VAR res+, n- INTEGER
-		VAR f Fib
-	PROCESS
-		f.n <- n - 1
-		res <- IF n # 0 THEN n + f.res ELSE 1 END
-	END Fib
-	
-	UNIT Fact
-		VAR res+, n- INTEGER
-		REG x INTEGER
-	INIT
-		x <- 1
-	PROCESS
-		res <- IF n = 0 THEN x END
-		x <- IF n # 0 THEN x*n ELSE 1 END
-		n <- IF n # 0 THEN n - 1 END
-	END Fact
-	
-	UNIT Top
-		REG x, y INTEGER
-		VAR fi Fib
-		VAR fa Fact
-	PROCESS
-		fi.n <- 10
-		x <- IF x = 0 THEN fi.res END
-		fa.n <- 10
-		y <- IF y = 0 THEN fa.res END
-	END Top
-
-В целом, как и в Lola, есть только инструкция присваивания. Точнее даже не присваивания, а ожидания. Вся активность модулей определяется итерациями инструкций внутри секции PROCESS. Формально, это статичное описание состояния, а не итерации, но исполнять иначе не получится. По завершению первой итерации модуль `Top` ожидает от `Fib` и `Fact` сообщений из выходного канала `res`, так как условие `x = 0` истинно.
-Наверное, так устроены все декларативные языки.
+---
+published: true
+layout: post
+---
+
+ 
+## Изучая Lola
+
+Поизучал описание языка [Lola](http://www.inf.ethz.ch/personal/wirth/Lola/index.html), в итоге понял, что MODULE это такая радиодеталь с ножками, вход/выход, внутренние преобразования по заданным функциям, вот это всё.
+Подумал над применением в программировании акторов или агентов, ведь агент это та же радиодеталь, датчики как входы, манипуляторы, как выходы. На программном урове, это всё, конечно, укладывается в понятия направленного канала сообщений и сообщения. Сообщением в LEAF можно сделать любой тип данных, передавать можно значения, или даже указатели, если они будут защищены от записи.
+
+Придумалось тут:
+
+	UNIT Fib
+		VAR res+, n- INTEGER
+		VAR f Fib
+	PROCESS
+		f.n <- n - 1
+		res <- IF n # 0 THEN n + f.res ELSE 1 END
+	END Fib
+	
+	UNIT Fact
+		VAR res+, n- INTEGER
+		REG x INTEGER
+	INIT
+		x <- 1
+	PROCESS
+		res <- IF n = 0 THEN x END
+		x <- IF n # 0 THEN x*n ELSE 1 END
+		n <- IF n # 0 THEN n - 1 END
+	END Fact
+	
+	UNIT Top
+		REG x, y INTEGER
+		VAR fi Fib
+		VAR fa Fact
+	PROCESS
+		fi.n <- 10
+		x <- IF x = 0 THEN fi.res END
+		fa.n <- 10
+		y <- IF y = 0 THEN fa.res END
+	END Top
+
+В целом, как и в Lola, есть только инструкция присваивания. Точнее даже не присваивания, а ожидания. Вся активность модулей определяется итерациями инструкций внутри секции PROCESS. Формально, это статичное описание состояния, а не итерации, но исполнять иначе не получится. По завершению первой итерации модуль `Top` ожидает от `Fib` и `Fact` сообщений из выходного канала `res`, так как условие `x = 0` истинно.
+Наверное, так устроены все декларативные языки.

_posts/2015-07-17-подробнее.md

@@ -1,44 +1,44 @@
----
-published: true
-layout: post
----
-
- 
-
-## Подробнее про придумку
-
-Конечно, вокруг модели акторов построена нехилая математика, точнее, физика. Так что в среде агентов должны соблюдаться физические принципы распространения и последовательности сигналов. Но они почти все интуитивно понятны, и кажется, что читаешь всякое капитанство.
-
-Попробую описать будущую модель среды и агентов. Напомню, есть агенты, у них есть входные и выходные каналы сообщений, в которые могут быть переданы собственно сообщения. 
-
-Изначально нет никого, в какой-то момент поступает команда на создание первого агента известного типа. Этот агент (Топ) может создать конечное число других агентов, а может и не создать. Создание агента равносильно объявлению переменной c типом -- идентификатором модуля.
-
-Создавая агентов, Топ посылать им сообщения во входные каналы и может производить запрос на значения из выходных каналов этих агентов. Но недостаточно сделать запрос на значение, надо дождаться ответа, таким образом, если после итерации есть запросы на значения, они должны быть удовлетворены. При этом очередная итерация Топа не может начаться без окончания всех вызванных ожиданий (не совсем ясно насчет дедлоков). 
-
-***
-
-Ситуация, когда Топ создает агентов, и не ожидает от них сообщений тоже возможна, при этом дальнейшей судьбой этих агентов Топ может не интересоваться, или интересоваться на общих основаниях, широковещательно (продумать этот момент)
-
-Пока рассмотрим случай когда мы создаем агента для выполнения работы с результатом.
-
-***
-
-В свою очередь созданные агенты (Фиб, Факт) реально вступают в действие после того, как возник запрос на их данные в итерации Топа, после ее окончания. Эти агенты получают так же сообщение во входные каналы `n`. 
-
-Фиб проверяет значение `n` и решает, что необходимо запросить значение для выходного канала у другого агента, попутно Фиб инициирует другого агента Фибi, которому передает значение входного параметра, уменьшенное на 1. Так как возник запрос, и больше нет действий, итерация завершается и переходит в состояние ожидания. Однако, если условие `n # 0` становится ложным, ожидание значения для `res` реализуется по месту, константой, и следовательно, итерация Фибi завершается, одновременно с этим отправляя сообщение Фибi-1, который тоже завершает ожидание. В итоге, в первоначальный Фиб придет значение n-го числа Фибоначчи.
-
-Факт поступает по другому. Он не инициирует своих собратьев, но вместо этого каждый раз передает нужное значение в собственный регистр `x`, который сохраняет значение между итерациями одного агента Факт (после завершения итераций регистр всё же пропадает). Так как выходное значение, которое требуется от агента не передано в выходной канал, итерация повторяется. Здесь возникает странный момент, что считать завершающей итерацией агента? Удовлетворение всех выходных сообщений, всех ожиданий и отсутствие выполняемых действий? И опять проблема дедлоков.
-
-Временной график
-
-|↓шаг|агент→|Top|Fib|Fact|Fib...|
-|:---:|---|---|---|---|---|
-|0||NEW||||
-|1||<-Fib, <-Fact||||
-|2|||NEW|NEW||
-|3|||<-Fib|@||
-|4||||@|NEW|
-|..||здесь порождаются Fib i-ые|..|..res<-|..|
-|N-3|||||res<-|
-|N-2|||res<-|||
-|N-1||x<-, y<-|||
+---
+published: true
+layout: post
+---
+
+ 
+
+## Подробнее про придумку
+
+Конечно, вокруг модели акторов построена нехилая математика, точнее, физика. Так что в среде агентов должны соблюдаться физические принципы распространения и последовательности сигналов. Но они почти все интуитивно понятны, и кажется, что читаешь всякое капитанство.
+
+Попробую описать будущую модель среды и агентов. Напомню, есть агенты, у них есть входные и выходные каналы сообщений, в которые могут быть переданы собственно сообщения. 
+
+Изначально нет никого, в какой-то момент поступает команда на создание первого агента известного типа. Этот агент (Топ) может создать конечное число других агентов, а может и не создать. Создание агента равносильно объявлению переменной c типом -- идентификатором модуля.
+
+Создавая агентов, Топ посылать им сообщения во входные каналы и может производить запрос на значения из выходных каналов этих агентов. Но недостаточно сделать запрос на значение, надо дождаться ответа, таким образом, если после итерации есть запросы на значения, они должны быть удовлетворены. При этом очередная итерация Топа не может начаться без окончания всех вызванных ожиданий (не совсем ясно насчет дедлоков). 
+
+***
+
+Ситуация, когда Топ создает агентов, и не ожидает от них сообщений тоже возможна, при этом дальнейшей судьбой этих агентов Топ может не интересоваться, или интересоваться на общих основаниях, широковещательно (продумать этот момент)
+
+Пока рассмотрим случай когда мы создаем агента для выполнения работы с результатом.
+
+***
+
+В свою очередь созданные агенты (Фиб, Факт) реально вступают в действие после того, как возник запрос на их данные в итерации Топа, после ее окончания. Эти агенты получают так же сообщение во входные каналы `n`. 
+
+Фиб проверяет значение `n` и решает, что необходимо запросить значение для выходного канала у другого агента, попутно Фиб инициирует другого агента Фибi, которому передает значение входного параметра, уменьшенное на 1. Так как возник запрос, и больше нет действий, итерация завершается и переходит в состояние ожидания. Однако, если условие `n # 0` становится ложным, ожидание значения для `res` реализуется по месту, константой, и следовательно, итерация Фибi завершается, одновременно с этим отправляя сообщение Фибi-1, который тоже завершает ожидание. В итоге, в первоначальный Фиб придет значение n-го числа Фибоначчи.
+
+Факт поступает по другому. Он не инициирует своих собратьев, но вместо этого каждый раз передает нужное значение в собственный регистр `x`, который сохраняет значение между итерациями одного агента Факт (после завершения итераций регистр всё же пропадает). Так как выходное значение, которое требуется от агента не передано в выходной канал, итерация повторяется. Здесь возникает странный момент, что считать завершающей итерацией агента? Удовлетворение всех выходных сообщений, всех ожиданий и отсутствие выполняемых действий? И опять проблема дедлоков.
+
+Временной график
+
+|↓шаг|агент→|Top|Fib|Fact|Fib...|
+|:---:|---|---|---|---|---|
+|0||NEW||||
+|1||<-Fib, <-Fact||||
+|2|||NEW|NEW||
+|3|||<-Fib|@||
+|4||||@|NEW|
+|..||здесь порождаются Fib i-ые|..|..res<-|..|
+|N-3|||||res<-|
+|N-2|||res<-|||
+|N-1||x<-, y<-|||

_posts/2015-07-17-чо-тут.md

@@ -1,19 +1,19 @@
----
-published: true
-layout: post
----
-
-
-
-
-## Что это такое?
-
-Практикуюсь в изобретении бессмысленных вещей. После проекта [fw](https://github.com/kpmy/fw "fw"), в котором интерпретировался выхлоп уже готового компилятора, написание своего компилятора было неизбежным. Вот он и реализовался. Проект компилятора и интерпретатора. Все довольно упростилось, язык `LEAF` структурно даже проще обычного Оберона. Система типов банальная. Хотя есть комплексные числа. Но это простой тип, он не усложняет систему вообще. Зато списки есть, и множества для любых значений, и ассоциативные массивы. Все довольно примитивное. 
-
-Основная особенность в том, что все статическое. И передается по значению. Есть пара обобщенных типов: значение вообще и указатель на значение вообще, вот по указателю уже динамическое значение будет, в куче. Работа с ними (с значениями вообще) получилась неудобной,  ведь язык строго типизированный. 
-
-Зато структурно в языке всё очень по Дейкстре. Хотя он бы не одобрил такое обращение со сложными структурами (я про передачу по значению). Процедуры, два вида циклов (и никаких `FOR`), ветвление. Модульность уже по Вирту, почти как в Обероне. А пользовательских типов нет. Да и зачем, основная идея в том, что пользовательский тип это обязательно либо `RECORD` либо `ARRAY OF`, `RECORD` хорошо ложится на ассоциативный массив, а `ARRAY` на простой список. Дальше возникает кагбэ "проблема": тип полей и элементов массива не указать, в `LEAF` значение в списке всегда `ANY`. 
-
-Ну что тут поделаешь, язык `LEAF` как раз и нужен чтобы проверить, как оно вообще, жизнеспособна ли такая идея или нет. Первая версия компилятора и рантайма написана на `golang` где-то за месяц. Теперь надо остановиться и подумать, как это сделать эффективным и не глючным. 
-
-P.S. Этак можно и лолу переписать на `golang`, где бы только время взять.
+---
+published: true
+layout: post
+---
+
+
+
+
+## Что это такое?
+
+Практикуюсь в изобретении бессмысленных вещей. После проекта [fw](https://github.com/kpmy/fw "fw"), в котором интерпретировался выхлоп уже готового компилятора, написание своего компилятора было неизбежным. Вот он и реализовался. Проект компилятора и интерпретатора. Все довольно упростилось, язык `LEAF` структурно даже проще обычного Оберона. Система типов банальная. Хотя есть комплексные числа. Но это простой тип, он не усложняет систему вообще. Зато списки есть, и множества для любых значений, и ассоциативные массивы. Все довольно примитивное. 
+
+Основная особенность в том, что все статическое. И передается по значению. Есть пара обобщенных типов: значение вообще и указатель на значение вообще, вот по указателю уже динамическое значение будет, в куче. Работа с ними (с значениями вообще) получилась неудобной,  ведь язык строго типизированный. 
+
+Зато структурно в языке всё очень по Дейкстре. Хотя он бы не одобрил такое обращение со сложными структурами (я про передачу по значению). Процедуры, два вида циклов (и никаких `FOR`), ветвление. Модульность уже по Вирту, почти как в Обероне. А пользовательских типов нет. Да и зачем, основная идея в том, что пользовательский тип это обязательно либо `RECORD` либо `ARRAY OF`, `RECORD` хорошо ложится на ассоциативный массив, а `ARRAY` на простой список. Дальше возникает кагбэ "проблема": тип полей и элементов массива не указать, в `LEAF` значение в списке всегда `ANY`. 
+
+Ну что тут поделаешь, язык `LEAF` как раз и нужен чтобы проверить, как оно вообще, жизнеспособна ли такая идея или нет. Первая версия компилятора и рантайма написана на `golang` где-то за месяц. Теперь надо остановиться и подумать, как это сделать эффективным и не глючным. 
+
+P.S. Этак можно и лолу переписать на `golang`, где бы только время взять.

_posts/2015-07-19-lomo.md

@@ -1,16 +1,16 @@
----
-published: true
-layout: post
----
-
-## Про LOMO
-
-Приступил к реализации [LOMO](https://github.com/kpmy/lomo), language of message objects, такой себе наследник LoLa, только вместо радиодеталей будут программные агенты.
-
-Язык декларативный, попроще чем LEAF в каком-то смысле, пока двигаюсь интуитивно, без EBNF и даже смутного понимания, как оно устроено в декларативных языках.
-
-![](http://s00.yaplakal.com/pics/pics_original/3/5/4/398453.jpg)
-
-Компилятор развиваю из наработок LEAF, только стараюсь переосмыслять и делать попроще и понадежнее, все же написание компилятора не является одной из основных целей, как в LEAF.
-
-
+---
+published: true
+layout: post
+---
+
+## Про LOMO
+
+Приступил к реализации [LOMO](https://github.com/kpmy/lomo), language of message objects, такой себе наследник LoLa, только вместо радиодеталей будут программные агенты.
+
+Язык декларативный, попроще чем LEAF в каком-то смысле, пока двигаюсь интуитивно, без EBNF и даже смутного понимания, как оно устроено в декларативных языках.
+
+![](http://s00.yaplakal.com/pics/pics_original/3/5/4/398453.jpg)
+
+Компилятор развиваю из наработок LEAF, только стараюсь переосмыслять и делать попроще и понадежнее, все же написание компилятора не является одной из основных целей, как в LEAF.
+
+

_posts/2015-07-20-to-ast-or-not-to-ast.md

@@ -1,11 +1,11 @@
----
-published: true
-layout: post
----
-
-
-## AST или не AST?
-Каждый раз возникает проблема, где хранить AST, хранить ли его вообще и если не хранить, то как быть?
-Однозначно хранить. Во-первых, изучать вывод компилятора в лог утомительно, лучше сразу сохранить структуру AST и поизучать ее на предмет ошибок. Во-вторых, AST должна быть слегка независима от модулей компилятора, поэтому лучше будет, если на момент передачи AST в интерпретатор/кодогенератор контекст компиляции уже будет потерян. И в-третьих, для экспериментальных языков выводом в AST все может и закончиться, ибо дешевле и проще проинтерпретировать AST, нежели писать кодогенератор для птичьих IR типа llvm.
-
-Для хранения AST уже перепробовал много разных форматов. Видимо, самый удобный все-таки XML, несмотря на общую многословность.
+---
+published: true
+layout: post
+---
+
+
+## AST или не AST?
+Каждый раз возникает проблема, где хранить AST, хранить ли его вообще и если не хранить, то как быть?
+Однозначно хранить. Во-первых, изучать вывод компилятора в лог утомительно, лучше сразу сохранить структуру AST и поизучать ее на предмет ошибок. Во-вторых, AST должна быть слегка независима от модулей компилятора, поэтому лучше будет, если на момент передачи AST в интерпретатор/кодогенератор контекст компиляции уже будет потерян. И в-третьих, для экспериментальных языков выводом в AST все может и закончиться, ибо дешевле и проще проинтерпретировать AST, нежели писать кодогенератор для птичьих IR типа llvm.
+
+Для хранения AST уже перепробовал много разных форматов. Видимо, самый удобный все-таки XML, несмотря на общую многословность.

_posts/2015-07-21-добавил-вики.md

@@ -1,7 +1,7 @@
----
-published: true
-layout: post
----
-
-Вики-статьи проекта LOMO лежать будут [тут](https://github.com/kpmy/lomo/wiki).
+---
+published: true
+layout: post
+---
+
+Вики-статьи проекта LOMO лежать будут [тут](https://github.com/kpmy/lomo/wiki).
 Тем временем, продвигаются работы по осмысливанию методом тыка параллельной модели работы агентов. Надо соблюдать осторожность с параллелизмом в Go. Иногда очень неприятные моменты проявляются.

_posts/2015-07-23-Работа-кипит.md

@@ -1,20 +1,20 @@
----
-published: true
-layout: post
----
-
-При работе над компилятором LOMO проявляются тонкие моменты, которые не были очевидны на бумаге. 
-
-Например, регистру присваивают значение и в следующей инструкции используют в качестве значения в выражении. Какое значение регистра должно быть использовано? 
-
-    UNIT Top
-    	REG x INTEGER
-    	VAR z INTEGER
-    PROCESS
-    	x := x = 0 ? 1 :: x = 1 ? 2 :: 0
-    	z := x
-    END Top
-
-При последовательном исполнении должно быть использовано обновленное значение. Но при параллельном исполнении такое поведение приведет к неявной ошибке, если вдруг инструкция чтения выполнится раньше инструкции записи. Поэтому регистр получает обновленное значение, которое будет доступно только в следующем такте. Проблема в том, что последовательная запись инструкций присваивания может сбить с толку.
-
-Такие вот тонкие моменты.
+---
+published: true
+layout: post
+---
+
+При работе над компилятором LOMO проявляются тонкие моменты, которые не были очевидны на бумаге. 
+
+Например, регистру присваивают значение и в следующей инструкции используют в качестве значения в выражении. Какое значение регистра должно быть использовано? 
+
+    UNIT Top
+    	REG x INTEGER
+    	VAR z INTEGER
+    PROCESS
+    	x := x = 0 ? 1 :: x = 1 ? 2 :: 0
+    	z := x
+    END Top
+
+При последовательном исполнении должно быть использовано обновленное значение. Но при параллельном исполнении такое поведение приведет к неявной ошибке, если вдруг инструкция чтения выполнится раньше инструкции записи. Поэтому регистр получает обновленное значение, которое будет доступно только в следующем такте. Проблема в том, что последовательная запись инструкций присваивания может сбить с толку.
+
+Такие вот тонкие моменты.

_posts/2015-07-25-Концепции-LOMO.md

@@ -1,25 +1,25 @@
----
-published: true
-layout: post
----
-
-Многие решения касаемо синтаксиса взяты из LEAF. Минимум разделителей, прямые заимствования из Оберона.
-
-Агентные системы тоже уже много где описаны. 
-В данном случае агенту соответствует одна программная единица - модуль. Модуль может содержать набор переменных и правила вычисления их значений (инструкции).
-
-Так как язык декларативный, инструкций существует ровно одна - присвоение. При этом присвоение каждой переменной может быть выполнено лишь один раз. Неважен и порядок следования присвоений, так как предполагается, что они будут выполнены по сути одновременно. 
-
-При этом, конечно, на реальных машинах будет задействована блокировка чтения значений из переменных до момента записи вычисленных значений, однако в работе с LOMO не стоит учитывать на этот факт, так как нарушается абстракция.
-
-При таком подходе иначе выглядит модульность. Модули всё так же представляют клиентам переменные для чтения и записи, но при этом все модули исполняются параллельно, а для клиентов модули представлены как экземпляры объектов, хранящиеся в переменных. Работа всех модулей начинается одновременно, и здесь действует то же правило доступа к переменным, что и внутри одного модуля, чтение значения возможно только после записи. 
-
-Таким образом реализуется принцип *передачи сообщений* между агентами. В явном виде описывать передачу сообщений нет смысла, присвоение значения конкретной переменной конкретного модуля и есть передача сообщения. Такой способ также способствует унификации инструкций - передача вовне и локальное присвоение становятся единой инструкцией.
-
-При этом существенно разделяют переменные только для чтения и переменные только для записи. 
-
-Таким образом реализуется *восприятие* и *активность* агента. Агент воспринимает входящие значения и порождает новых агентов и исходящие сообщения.
-
-Отдельным видом переменных является регистр. Если обычные переменные возникают при старте агента и пропадают при его исчезновении, то регистры способны запомнить информацию между циклами жизни агента. При этом принцип единственного присвоения распространяется и на регистры. А так же значение, присвоенное регистру станет доступно для чтения только в следующей жизненном цикле агента. 
-
-Таким образом реализуется внутреннее состояние агента/системы агентов.
+---
+published: true
+layout: post
+---
+
+Многие решения касаемо синтаксиса взяты из LEAF. Минимум разделителей, прямые заимствования из Оберона.
+
+Агентные системы тоже уже много где описаны. 
+В данном случае агенту соответствует одна программная единица - модуль. Модуль может содержать набор переменных и правила вычисления их значений (инструкции).
+
+Так как язык декларативный, инструкций существует ровно одна - присвоение. При этом присвоение каждой переменной может быть выполнено лишь один раз. Неважен и порядок следования присвоений, так как предполагается, что они будут выполнены по сути одновременно. 
+
+При этом, конечно, на реальных машинах будет задействована блокировка чтения значений из переменных до момента записи вычисленных значений, однако в работе с LOMO не стоит учитывать на этот факт, так как нарушается абстракция.
+
+При таком подходе иначе выглядит модульность. Модули всё так же представляют клиентам переменные для чтения и записи, но при этом все модули исполняются параллельно, а для клиентов модули представлены как экземпляры объектов, хранящиеся в переменных. Работа всех модулей начинается одновременно, и здесь действует то же правило доступа к переменным, что и внутри одного модуля, чтение значения возможно только после записи. 
+
+Таким образом реализуется принцип *передачи сообщений* между агентами. В явном виде описывать передачу сообщений нет смысла, присвоение значения конкретной переменной конкретного модуля и есть передача сообщения. Такой способ также способствует унификации инструкций - передача вовне и локальное присвоение становятся единой инструкцией.
+
+При этом существенно разделяют переменные только для чтения и переменные только для записи. 
+
+Таким образом реализуется *восприятие* и *активность* агента. Агент воспринимает входящие значения и порождает новых агентов и исходящие сообщения.
+
+Отдельным видом переменных является регистр. Если обычные переменные возникают при старте агента и пропадают при его исчезновении, то регистры способны запомнить информацию между циклами жизни агента. При этом принцип единственного присвоения распространяется и на регистры. А так же значение, присвоенное регистру станет доступно для чтения только в следующей жизненном цикле агента. 
+
+Таким образом реализуется внутреннее состояние агента/системы агентов.

_posts/2015-07-29-Интеграция.md

@@ -1,14 +1,14 @@
----
-published: true
-layout: post
----
-
-Как и следовало ожидать, после того как я полностью скопировал фичи типов данных из LEAF, идея интегрировать LEAF в LOMO в качестве особого агента не заставила себя долго ждать. Так как LEAF-машина однопоточная, то никаких трудностей не возникло, выполнение работы обертывается в формат правила, входное сообщение передается псевдоагенту, а выходное поступает на запись в переменную обычного агента.
-
-    UNIT Top
-    	VAR x ANY
-    PROCESS
-    	<<"type": "ping">> \LEAF "TestEcho"  -> x
-    END Top
-
-Типа того.
+---
+published: true
+layout: post
+---
+
+Как и следовало ожидать, после того как я полностью скопировал фичи типов данных из LEAF, идея интегрировать LEAF в LOMO в качестве особого агента не заставила себя долго ждать. Так как LEAF-машина однопоточная, то никаких трудностей не возникло, выполнение работы обертывается в формат правила, входное сообщение передается псевдоагенту, а выходное поступает на запись в переменную обычного агента.
+
+    UNIT Top
+    	VAR x ANY
+    PROCESS
+    	<<"type": "ping">> \LEAF "TestEcho"  -> x
+    END Top
+
+Типа того.

_posts/2015-08-01-Применение.md

@@ -1,8 +1,8 @@
----
-published: true
-layout: post
----
-
-По прошествии некоторого времени после окончания периода активной разработки проектов LEAF и LOMO становится понятно, что примеров применения языков не найти. Возможно, Вирт изначально поcтупал более верно и разрабатывал язык общего назначения под конкретный проект, в котором язык проходил "крещение огнем" и дальше уже жил взрослой жизнью. Для новых языков, особенно концептуальных и минималистичных, как `lomo`, так просто проекта не найти.
-
-Одно из применений связке LEAF + LOMO мне видится в создании систем построения веб-страниц. Аналог HTML, но с большим уклоном именно в программирование всего подряд, тюринг-полноту каждой сущности, а не в text markup, как это видели в 90-х.
+---
+published: true
+layout: post
+---
+
+По прошествии некоторого времени после окончания периода активной разработки проектов LEAF и LOMO становится понятно, что примеров применения языков не найти. Возможно, Вирт изначально поcтупал более верно и разрабатывал язык общего назначения под конкретный проект, в котором язык проходил "крещение огнем" и дальше уже жил взрослой жизнью. Для новых языков, особенно концептуальных и минималистичных, как `lomo`, так просто проекта не найти.
+
+Одно из применений связке LEAF + LOMO мне видится в создании систем построения веб-страниц. Аналог HTML, но с большим уклоном именно в программирование всего подряд, тюринг-полноту каждой сущности, а не в text markup, как это видели в 90-х.

_posts/2015-09-28-Ад-концепций.md

@@ -1,30 +1,30 @@
----
-published: true
-layout: post
----
-
-Что если всё это время понятие *жизнь программы* недооценивали? *Жизнь*, а точнее, *жизненный цикл* программы можно описать повторяющейся последовательностью конечных процессов. Обязательно конечных, в каком-то разумном временном отрезке.
-
-Когда появляется программа? Скорее всего, программа появляется в голове у проектировщика/разработчика, можно назвать это *design-time*. Но так как этот момент не поддаётся контролю компьютера (пока), то предположим, что моментом появления программы является момент создания минимального запускаемого (о подробном смысле этого термина стоит поговорить отдельно) исходного кода. В контексте Оберона - программа рождается, когда появляется минимальный модуль.
-
-Затем, после этапа написания некоторого программного кода, программа передается компилятору. Компилятор обеспечивает т.н. *compile-time* - *время компиляции*. В результате выполнения процесса компиляции мы получаем компилят (то есть непосредственный результат обработки нашего исходного кода). 
-
-Во время компиляции наш исходный код влияет на работу компилятора по определенным законам, которые выражены в коде компилятора. В то же самое время, никто не мешает уже на этапе компиляции управлять действиями компилятора (точнее, исполнителя в целом) не опосредованно, через написание текста нашей программы, а непосредственно, через *написание кода общего назначения, который будет выполнен компилятором*, то есть такого кода, который хоть и относится к задуманной программе, но не переводится компилятором в компилят непосредственно. Так называемый [CTFE](https://en.wikipedia.org/wiki/Compile_time_function_execution), но в более общем смысле. 
-
-Понятно, что нахождение в контексте процесса работы компилятора может накладывать некоторые ограничения на *код времени компиляции*, однако может и не накладывать. 
-
-Здесь мы можем заметить, что выполнение любого процесса жизненного цикла предполагает наличие результата, в явном или неявном виде. 
-
-После получения компилята, над ним, сразу или отложенно должен быть исполнен процесс связывания или линковки. Так как компилят обычно хранится в файле, то возникает *время загрузки* - *load-time*. В это время над компилятом могут быть произведены дополнительные преобразования в код целевой платформы, и в это время может быть выполнен код времени загрузки, например, обработка компилята оптимизирующим компилятором. На данный момент известна только одна технология, **slim-binaries**, поздняя кодогенерация на целевой платформе, которая хоть как-то описывает время загрузки. 
-
-Обычно, линковка необходима, так как компилятор всегда производит компилят для одного модуля для непосредственного исполнения на целевой машине. Однако в реальной модульной системе на машине одновременно будут исполнены несколько модулей. Эта ситуация в многомодульной системе приводит к необходимости связывания. В старых системах связывание могло производиться непосредственно после компиляции, но этот вырожденный случай мы не рассматриваем. Итак, возникает *время связывания*, или *link-time*. 
-
-Мало что известно про выполнение кода во время связывания, однако понятно, что в момент связывания возможно выполнение кода, например, Dependency Injection и динамического наследования, как это может быть реализовано в рамках работы внутри jvm. Такой контроль над еще не запущенным в действие, но уже готовым к исполнению кодом программы позволяет реализовывать автоматизированную настройку и так далее. После связывания и настройки код непосредственно готов к запуску.
-
-Запуск и дальнейшая работа. Представлены *временем инициализации* (init-time) и *временем исполнения* (run-time). В сущности, результат работы этого этапа жизненного цикла и является обычно непосредственной целью написания программы. Можно дополнительно выделить *время завершения* работы программы (close-time). Однако сейчас все три времени работы обычно принято называть *run-time*, а логическое деление на три этапа реализовывать уже в рамках клиентского программного кода. Такой подход снижает требования к среде исполнения (run-time environment) но не дает гарантий исполнения того или иного этапа в нужной последовательности из-за возможных ошибок исполнения (run-time error) после которых исполнение, обычно, должно завершиться аварийно.
-
-Отдельным важным временем жизни программы является *посмертное время* (death-time), в которое, вопреки распространенным представлениям тоже является частью жизненного цикла программы. Объяснение тут простое, так как целью работы программы обычно является некий результат, обычно зависящий от входных данных, которых может быть очень много, программы строятся с применением методов, позволяющих итеративно обрабатывать входные данные и производить выходные данные, которые могут быть поданы на вход следующей итерации. Обычно такие данные структурированы (БД), версионны и их содержимое и интерпретация зависит от реализации работающей программы. То есть, программа это алгоритмы и данные, в том числе внешние и степень связанности этих внешних данных с программой никак не влияет на сам факт наличия такой связанности на любом этапе жизненного цикла.
-
-Проще говоря, программа запущенная вновь будет работать по разному, в зависимости от результата, который был ею же получен на прошлом этапе жизненного цикла. И если внести в эти данные изменения во время, которое программа не запущена, программа тоже будет работать иначе, то есть, внося изменения в данные мы программируем программу работать иначе. Что есть этап жизненного цикла программы.
-
-Итак, рассмотрены этапы жизненного цикла программы: *compile-time* -> *load-time* -> *link-time* -> *init-time* -> *run-time* -> *close-time* -> *death-time*. 
+---
+published: true
+layout: post
+---
+
+Что если всё это время понятие *жизнь программы* недооценивали? *Жизнь*, а точнее, *жизненный цикл* программы можно описать повторяющейся последовательностью конечных процессов. Обязательно конечных, в каком-то разумном временном отрезке.
+
+Когда появляется программа? Скорее всего, программа появляется в голове у проектировщика/разработчика, можно назвать это *design-time*. Но так как этот момент не поддаётся контролю компьютера (пока), то предположим, что моментом появления программы является момент создания минимального запускаемого (о подробном смысле этого термина стоит поговорить отдельно) исходного кода. В контексте Оберона - программа рождается, когда появляется минимальный модуль.
+
+Затем, после этапа написания некоторого программного кода, программа передается компилятору. Компилятор обеспечивает т.н. *compile-time* - *время компиляции*. В результате выполнения процесса компиляции мы получаем компилят (то есть непосредственный результат обработки нашего исходного кода). 
+
+Во время компиляции наш исходный код влияет на работу компилятора по определенным законам, которые выражены в коде компилятора. В то же самое время, никто не мешает уже на этапе компиляции управлять действиями компилятора (точнее, исполнителя в целом) не опосредованно, через написание текста нашей программы, а непосредственно, через *написание кода общего назначения, который будет выполнен компилятором*, то есть такого кода, который хоть и относится к задуманной программе, но не переводится компилятором в компилят непосредственно. Так называемый [CTFE](https://en.wikipedia.org/wiki/Compile_time_function_execution), но в более общем смысле. 
+
+Понятно, что нахождение в контексте процесса работы компилятора может накладывать некоторые ограничения на *код времени компиляции*, однако может и не накладывать. 
+
+Здесь мы можем заметить, что выполнение любого процесса жизненного цикла предполагает наличие результата, в явном или неявном виде. 
+
+После получения компилята, над ним, сразу или отложенно должен быть исполнен процесс связывания или линковки. Так как компилят обычно хранится в файле, то возникает *время загрузки* - *load-time*. В это время над компилятом могут быть произведены дополнительные преобразования в код целевой платформы, и в это время может быть выполнен код времени загрузки, например, обработка компилята оптимизирующим компилятором. На данный момент известна только одна технология, **slim-binaries**, поздняя кодогенерация на целевой платформе, которая хоть как-то описывает время загрузки. 
+
+Обычно, линковка необходима, так как компилятор всегда производит компилят для одного модуля для непосредственного исполнения на целевой машине. Однако в реальной модульной системе на машине одновременно будут исполнены несколько модулей. Эта ситуация в многомодульной системе приводит к необходимости связывания. В старых системах связывание могло производиться непосредственно после компиляции, но этот вырожденный случай мы не рассматриваем. Итак, возникает *время связывания*, или *link-time*. 
+
+Мало что известно про выполнение кода во время связывания, однако понятно, что в момент связывания возможно выполнение кода, например, Dependency Injection и динамического наследования, как это может быть реализовано в рамках работы внутри jvm. Такой контроль над еще не запущенным в действие, но уже готовым к исполнению кодом программы позволяет реализовывать автоматизированную настройку и так далее. После связывания и настройки код непосредственно готов к запуску.
+
+Запуск и дальнейшая работа. Представлены *временем инициализации* (init-time) и *временем исполнения* (run-time). В сущности, результат работы этого этапа жизненного цикла и является обычно непосредственной целью написания программы. Можно дополнительно выделить *время завершения* работы программы (close-time). Однако сейчас все три времени работы обычно принято называть *run-time*, а логическое деление на три этапа реализовывать уже в рамках клиентского программного кода. Такой подход снижает требования к среде исполнения (run-time environment) но не дает гарантий исполнения того или иного этапа в нужной последовательности из-за возможных ошибок исполнения (run-time error) после которых исполнение, обычно, должно завершиться аварийно.
+
+Отдельным важным временем жизни программы является *посмертное время* (death-time), в которое, вопреки распространенным представлениям тоже является частью жизненного цикла программы. Объяснение тут простое, так как целью работы программы обычно является некий результат, обычно зависящий от входных данных, которых может быть очень много, программы строятся с применением методов, позволяющих итеративно обрабатывать входные данные и производить выходные данные, которые могут быть поданы на вход следующей итерации. Обычно такие данные структурированы (БД), версионны и их содержимое и интерпретация зависит от реализации работающей программы. То есть, программа это алгоритмы и данные, в том числе внешние и степень связанности этих внешних данных с программой никак не влияет на сам факт наличия такой связанности на любом этапе жизненного цикла.
+
+Проще говоря, программа запущенная вновь будет работать по разному, в зависимости от результата, который был ею же получен на прошлом этапе жизненного цикла. И если внести в эти данные изменения во время, которое программа не запущена, программа тоже будет работать иначе, то есть, внося изменения в данные мы программируем программу работать иначе. Что есть этап жизненного цикла программы.
+
+Итак, рассмотрены этапы жизненного цикла программы: *compile-time* -> *load-time* -> *link-time* -> *init-time* -> *run-time* -> *close-time* -> *death-time*. 

_posts/2015-09-29-Больше-ада-концепций.md

@@ -1,8 +1,8 @@
----
-published: true
-layout: post
----
-
-В [дополнение](http://b.ocsf.in/2015/09/28/%D0%90%D0%B4-%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D0%B9/) необходимо отметить, что можно обоснованно выделить *design-time* в отдельную категорию, но не как процесс в голове разработчика, а чисто утилитарно, опираясь на процесс кодирования. Здесь можно описать автокомплит, автоподсветку (как уже реализованные программы), программирование макросов ide, генерацию схем БД и ДРАКОН-схем, и так далее. То есть, уточненная последовательность одной итерации жизненного цикла программы будет представлена как: *design-time* -> *compile-time* -> *load-time* -> *link-time* -> *init-time* -> *run-time* -> *close-time* -> *death-time*.
-
-![](https://raw.githubusercontent.com/kpmy/kpmy.github.io/master/_posts/code-life-line.png)
+---
+published: true
+layout: post
+---
+
+В [дополнение](http://b.ocsf.in/2015/09/28/%D0%90%D0%B4-%D0%BA%D0%BE%D0%BD%D1%86%D0%B5%D0%BF%D1%86%D0%B8%D0%B9/) необходимо отметить, что можно обоснованно выделить *design-time* в отдельную категорию, но не как процесс в голове разработчика, а чисто утилитарно, опираясь на процесс кодирования. Здесь можно описать автокомплит, автоподсветку (как уже реализованные программы), программирование макросов ide, генерацию схем БД и ДРАКОН-схем, и так далее. То есть, уточненная последовательность одной итерации жизненного цикла программы будет представлена как: *design-time* -> *compile-time* -> *load-time* -> *link-time* -> *init-time* -> *run-time* -> *close-time* -> *death-time*.
+
+![](https://raw.githubusercontent.com/kpmy/kpmy.github.io/master/_posts/code-life-line.png)

_posts/2015-10-04-Шаблонизатор.md

@@ -1,63 +1,63 @@
----
-published: true
-layout: post
----
-
-Вернулся к обдумыванию применения `LOMO` и `LEAF` в качестве языка для описания объектов и процесса их построения, проще говоря, в качестве шаблонизатора.
-
-Основная идея такая. Определяется некий контекст. Пока неважно какой, главное, в нем возможно создание объектов и их сохранение после завершения работы условного шаблонизатора.
-
-Объекты представляют собой суть ссылку на класс и любое пользовательское содержимое, выраженное в форме составных типов `MAP`, `LIST` и, возможно, `SET`. Это даёт возможность описывать всевозможные отношения объектов и их свойства.
-
-Важным свойством шаблонизатора будет возможность обращения к данным, которые размещены в контексте.
-
-А еще более важным свойством будет являться возможность описывать императивный и декларативный код (на `LEAF` и `LOMO`, соответственно) непосредственно в теле шаблона, и такой код будет полностью легально создавать куски шаблона, менять свойства объектов и обращаться к данным в контексте.
-
-Долго пришлось подумать над базовой концепцией шаблонизатора, которая позволила бы реализовать подобные возможности. Эта концепция, в общем, проста. Шаблон будет компилируемым. А вариация синтаксиса для описания объектов будет представлять собой то, что могло бы получиться у авторов XML, если бы они знали про Оберон.
-
-    core.template(my-perfect-page):
-        core.import! context html;
-        html.body(root):
-        	br: enhanced;
-        	br
-        	br:
-        		type: page;
-        		fp = 344H;
-        	;
-        	`ffe`
-        	para(see-my-text):
-        		`first i was like`
-        		bold: `smth`;
-        		`, but then i `
-        		italic: `lol'd`;
-        	;
-        	table:
-        		len = context.len;
-        		do!
-        		var i integer
-        		begin
-        			while i < context.len do
-        				this:
-      					tr: hidden;
-                          text = @see-my-text;
-        				;
-        				parent:
-    					   count = i + 1;
-
-        				;
-        			end
-        		end;
-        	;
-        ;
-      ;
-
-Вполне вероятно, это будет выглядеть вот так. Капс скорее всего тоже будет применён (хотя кто знает).
-
-Итак, что мы видим: шаблон представляет собой вариацию на тему модуля Оберона. Базовые правила описания объектов: класс (существующий, импортированный, стандартный или вновь созданный) (core.template, core.import, html.body, br и т.д.), затем опциональный идентификатор конкретного объекта (для модуля обязательный), потом модификатор доступа к содержимому: `:` - обычное содержимое, `!` - специальное (мета)содержимое, `=` - уникальное (в рамках родительского объекта) содержимое. Возможно также описывать объекты заданного класса без содержимого. Особенностью будет необязательная квалификация классов внутри объекта с классом, импортированным из других шаблонов. Для html-шаблонов это будет немаловажным фактом.
-
-Внутреннее содержимое объекта определяется как перечисление идентификаторов классов объектов и управление содержимым этих объектов. Кроме этого, содержимым объектов может быть любая константа текстового, числового или любого другого допустимого в `LEAF`/`LOMO` простого типа. Возможно имеет смысл непосредственно представлять любой объект как аналог модуля `LOMO`, но непонятно, как быть с императивными вставками. Отдельно рассматривается возможность использования в качестве содержимого ссылок на объекты по идентификатору.
-
-Данный пример технической части является лишь наброском и возможно будет изменен, но базовая концепция постепенно формируется в прототип. Так, исполнение кода внутри шаблона будет доступно при его генерации. В принципе, этот код будет ничем не ограничен, но в нем будут доступны объекты, внутри которых он был вызван таким образом внутри кода будет возможность создания объектов контекста.
-
-В примере был выбран шаблон html как наиболее шаблонизируемого языка, так как создание html из шаблонов это довольно важная часть работы шаблонизаторов вообще.
-Результатом работы шаблонизатора над примером будет дерево объектов, которое может быть легко оттранслировано в html, провалидировано по требуемым правилам и так далее.
+---
+published: true
+layout: post
+---
+
+Вернулся к обдумыванию применения `LOMO` и `LEAF` в качестве языка для описания объектов и процесса их построения, проще говоря, в качестве шаблонизатора.
+
+Основная идея такая. Определяется некий контекст. Пока неважно какой, главное, в нем возможно создание объектов и их сохранение после завершения работы условного шаблонизатора.
+
+Объекты представляют собой суть ссылку на класс и любое пользовательское содержимое, выраженное в форме составных типов `MAP`, `LIST` и, возможно, `SET`. Это даёт возможность описывать всевозможные отношения объектов и их свойства.
+
+Важным свойством шаблонизатора будет возможность обращения к данным, которые размещены в контексте.
+
+А еще более важным свойством будет являться возможность описывать императивный и декларативный код (на `LEAF` и `LOMO`, соответственно) непосредственно в теле шаблона, и такой код будет полностью легально создавать куски шаблона, менять свойства объектов и обращаться к данным в контексте.
+
+Долго пришлось подумать над базовой концепцией шаблонизатора, которая позволила бы реализовать подобные возможности. Эта концепция, в общем, проста. Шаблон будет компилируемым. А вариация синтаксиса для описания объектов будет представлять собой то, что могло бы получиться у авторов XML, если бы они знали про Оберон.
+
+    core.template(my-perfect-page):
+        core.import! context html;
+        html.body(root):
+        	br: enhanced;
+        	br
+        	br:
+        		type: page;
+        		fp = 344H;
+        	;
+        	`ffe`
+        	para(see-my-text):
+        		`first i was like`
+        		bold: `smth`;
+        		`, but then i `
+        		italic: `lol'd`;
+        	;
+        	table:
+        		len = context.len;
+        		do!
+        		var i integer
+        		begin
+        			while i < context.len do
+        				this:
+      					tr: hidden;
+                          text = @see-my-text;
+        				;
+        				parent:
+    					   count = i + 1;
+
+        				;
+        			end
+        		end;
+        	;
+        ;
+      ;
+
+Вполне вероятно, это будет выглядеть вот так. Капс скорее всего тоже будет применён (хотя кто знает).
+
+Итак, что мы видим: шаблон представляет собой вариацию на тему модуля Оберона. Базовые правила описания объектов: класс (существующий, импортированный, стандартный или вновь созданный) (core.template, core.import, html.body, br и т.д.), затем опциональный идентификатор конкретного объекта (для модуля обязательный), потом модификатор доступа к содержимому: `:` - обычное содержимое, `!` - специальное (мета)содержимое, `=` - уникальное (в рамках родительского объекта) содержимое. Возможно также описывать объекты заданного класса без содержимого. Особенностью будет необязательная квалификация классов внутри объекта с классом, импортированным из других шаблонов. Для html-шаблонов это будет немаловажным фактом.
+
+Внутреннее содержимое объекта определяется как перечисление идентификаторов классов объектов и управление содержимым этих объектов. Кроме этого, содержимым объектов может быть любая константа текстового, числового или любого другого допустимого в `LEAF`/`LOMO` простого типа. Возможно имеет смысл непосредственно представлять любой объект как аналог модуля `LOMO`, но непонятно, как быть с императивными вставками. Отдельно рассматривается возможность использования в качестве содержимого ссылок на объекты по идентификатору.
+
+Данный пример технической части является лишь наброском и возможно будет изменен, но базовая концепция постепенно формируется в прототип. Так, исполнение кода внутри шаблона будет доступно при его генерации. В принципе, этот код будет ничем не ограничен, но в нем будут доступны объекты, внутри которых он был вызван таким образом внутри кода будет возможность создания объектов контекста.
+
+В примере был выбран шаблон html как наиболее шаблонизируемого языка, так как создание html из шаблонов это довольно важная часть работы шаблонизаторов вообще.
+Результатом работы шаблонизатора над примером будет дерево объектов, которое может быть легко оттранслировано в html, провалидировано по требуемым правилам и так далее.

_posts/2015-10-05-Некоторые дополнительные мысли.md

@@ -1,40 +1,40 @@
----
-published: true
-layout: post
----
-
-* *Почему сначала класс объекта, а потом необязательный идентификатор (имя)?*
-  * Потому что шаблон принципиально работает с объектом еще до его создания, то есть, на самом деле шаблон для разработчика и для шаблонизатора должен формировать новый объект из заданного класса. Зачастую, этого достаточно, а если недостаточно, то уже можно обращаться к конкретному объекту.
-* *Как будет обеспечиваться модульность шаблонов?*
-  * Скорее всего, модульность шаблонов будет обеспечиваться таким же образом, как и в `LOMO`, то есть, вложенных шаблонов не будет, один шаблон - одна импортируемая сущность. Что не исключает возможности группировки шаблонов в подсистемы чисто организационно, на уровне файловой системы и полного квалификатора имени. Так же возможно будут экспортированные константы и объекты внутри сущностей (например, стандартные аттрибуты html).
-* *Шаблоны декларативные или императивные?*
-  * Описание шаблона мультипарадигменное, тут и декларативная часть, и императивная часть и работа с контекстом, который каждый раз меняется под действием самого шаблона.
-* *Процедуры и модульность внутри `LEAF`, импорт юнитов в `LOMO`?*
-  * Так как менять языки не хочется, скорее всего импорт из любого модуля будет возможен на этапе выполнения шаблона. Допустим это будет выглядеть так:
-
-        CORE.TEMPLATE(my-little-tree):
-          CHESS:
-            DO! IMPORT Strings
-
-              PROCEDURE Invert
-                VAR i+, o- STRING
-              BEGIN
-                o := i[\LEN i .. 0] (* range-нотации пока нет в LEAF *)
-              END Invert
-
-            VAR s STRING
-            BEGIN
-              Invert(o: "K F G", i -> s)
-              THIS: move = s;
-            END;
-            CALC!
-              VAR x INTEGER
-            PROCESS
-              2 -> x
-              x ^ 2 -> THIS number;
-            END;
-          ;
-        ;
-
-* *Громоздко!*
-  * императивный код -> декларативный код -> шаблонный код, чем дальше тем хуже. Но попробовать стоит. Конечно, для поддержки инструкций шаблонов внутри встраиваемых языков их компиляторы придётся доработать, но формально это останутся те же языки с полным набором фич. Заодно можно попробовать наконец-то сделать обобщенную кодовую базу для всех языков.
+---
+published: true
+layout: post
+---
+
+* *Почему сначала класс объекта, а потом необязательный идентификатор (имя)?*
+  * Потому что шаблон принципиально работает с объектом еще до его создания, то есть, на самом деле шаблон для разработчика и для шаблонизатора должен формировать новый объект из заданного класса. Зачастую, этого достаточно, а если недостаточно, то уже можно обращаться к конкретному объекту.
+* *Как будет обеспечиваться модульность шаблонов?*
+  * Скорее всего, модульность шаблонов будет обеспечиваться таким же образом, как и в `LOMO`, то есть, вложенных шаблонов не будет, один шаблон - одна импортируемая сущность. Что не исключает возможности группировки шаблонов в подсистемы чисто организационно, на уровне файловой системы и полного квалификатора имени. Так же возможно будут экспортированные константы и объекты внутри сущностей (например, стандартные аттрибуты html).
+* *Шаблоны декларативные или императивные?*
+  * Описание шаблона мультипарадигменное, тут и декларативная часть, и императивная часть и работа с контекстом, который каждый раз меняется под действием самого шаблона.
+* *Процедуры и модульность внутри `LEAF`, импорт юнитов в `LOMO`?*
+  * Так как менять языки не хочется, скорее всего импорт из любого модуля будет возможен на этапе выполнения шаблона. Допустим это будет выглядеть так:
+
+        CORE.TEMPLATE(my-little-tree):
+          CHESS:
+            DO! IMPORT Strings
+
+              PROCEDURE Invert
+                VAR i+, o- STRING
+              BEGIN
+                o := i[\LEN i .. 0] (* range-нотации пока нет в LEAF *)
+              END Invert
+
+            VAR s STRING
+            BEGIN
+              Invert(o: "K F G", i -> s)
+              THIS: move = s;
+            END;
+            CALC!
+              VAR x INTEGER
+            PROCESS
+              2 -> x
+              x ^ 2 -> THIS number;
+            END;
+          ;
+        ;
+
+* *Громоздко!*
+  * императивный код -> декларативный код -> шаблонный код, чем дальше тем хуже. Но попробовать стоит. Конечно, для поддержки инструкций шаблонов внутри встраиваемых языков их компиляторы придётся доработать, но формально это останутся те же языки с полным набором фич. Заодно можно попробовать наконец-то сделать обобщенную кодовую базу для всех языков.

_posts/2015-10-12-Первый-прототип.md

@@ -1,29 +1,29 @@
----
-published: true
-layout: post
----
-
-Первый прототип языка, парсера и объектной модели готов, подробности в [вики](https://github.com/kpmy/ot/wiki). 
-По результату тестов можно отметить, что неявная квалификация даже в контексте текстовых человекочитаемых шаблонов есть фича неоднозначная. 
-
-В остальном всё довольно просто прошло, парсер -> объектная модель -> контекст. Даже немного боязно, не упустил ли чего за кажущейся простотой. 
-Сомнения вызывает точка, как разделитель в квалификаторе, она не позволяет использовать точку, как часть идентификатора, хотя в роли квалификатора точка довольно органично смотрится. 
-Сегодняшний формат выглядит примерно так:
-
-    module.class(id): content;
-
-Куча вариантов было отброшено:
-
-    module>class(id)
-    [module]class(id)
-    module:class(id)
-    
-В последнем варианте двоеточие смотрится неплохо, как в xml namespace, но это сразу убивает возможность использования двоеточия, как негромоздкого символа, открывающего содержимое объекта.
-
-*UPD:* Всё же не смог пожертвовать точкой в идентификаторе и на свежую голову придумал разделитель вместо точки: `~`.
-
-    module~class(id): content;
-
-Конечно, пока никаких языков программирования встроить не требовалось, да и задача постепенно усложняется, так как встраивание требует модификации парсера, что может серьёзно повредить его, простой как сапог, сути. 
-Возможно, встраивание ЯП должно выглядеть иначе, чем задумывалось в посте с рассуждениями.
-
+---
+published: true
+layout: post
+---
+
+Первый прототип языка, парсера и объектной модели готов, подробности в [вики](https://github.com/kpmy/ot/wiki). 
+По результату тестов можно отметить, что неявная квалификация даже в контексте текстовых человекочитаемых шаблонов есть фича неоднозначная. 
+
+В остальном всё довольно просто прошло, парсер -> объектная модель -> контекст. Даже немного боязно, не упустил ли чего за кажущейся простотой. 
+Сомнения вызывает точка, как разделитель в квалификаторе, она не позволяет использовать точку, как часть идентификатора, хотя в роли квалификатора точка довольно органично смотрится. 
+Сегодняшний формат выглядит примерно так:
+
+    module.class(id): content;
+
+Куча вариантов было отброшено:
+
+    module>class(id)
+    [module]class(id)
+    module:class(id)
+    
+В последнем варианте двоеточие смотрится неплохо, как в xml namespace, но это сразу убивает возможность использования двоеточия, как негромоздкого символа, открывающего содержимое объекта.
+
+*UPD:* Всё же не смог пожертвовать точкой в идентификаторе и на свежую голову придумал разделитель вместо точки: `~`.
+
+    module~class(id): content;
+
+Конечно, пока никаких языков программирования встроить не требовалось, да и задача постепенно усложняется, так как встраивание требует модификации парсера, что может серьёзно повредить его, простой как сапог, сути. 
+Возможно, встраивание ЯП должно выглядеть иначе, чем задумывалось в посте с рассуждениями.
+

_posts/2015-10-21-Застрял.md

@@ -1,22 +1,22 @@
----
-published: true
-layout: post
----
-
-После первого прототипа дело o.t. застопорилось и неспроста.
-Я начал повторять шаги, по которым до меня прошло уже много людей и коллективов, а с коллективами тягаться смысла нет.
-Поэтому всякие плюшки типа аналога xpath или применения relaxng теперь кажутся неинтересными.
-
-Со встраиванием языков программирования тоже проблема. Получается, что нет возможности встроить языки в шаблонизатор на уровне библиотеки и необязательного компонента.
-Уже на уровне сканнера символов сталкиваемся с необходимостью двух различных обработчиков одного и того же символа, что само по себе лишает сканнер обероновской простоты.
-Возможно на этом этапе стоит оформить сканнер и парсер по-другому.
-
-Что тут можно предложить?
-
-* Первой на ум приходит мысль о модели производитель-потребитель. Сканнер становится нерасширяемым и монолитным и потребляет любой символ, даже тот, который ему незнаком. Минус очевиден, вся работа по осознанию семантики прочитанного становится задачей потребителя, что не очень хорошо с точки зрения разделения ответственности.
-
-* Второй способ довольно банален, монолитный парсер со сменными стратегиями разбора символов. Сканнер включает в себя сразу все возможные символы и предопределенные идентификаторы. Минус очевиден, возможные интерференции между синтаксисами языков внутри сканнера. Сложный компилятор с кучей дублирующегося по сути кода для разных режимов разбора, что почти не решается шаблонизацией или обобщением. Просто чуть разный, но однообразный код.
-
-* Третий способ полностью противоречит исходному желанию органично встроить исполняемый код в шаблон, мне придётся реализовать код в шаблонах как полностью отдельную сущность и разделять их с шаблоном уже на уровне текстового представления. Удобный, но антиконцептуальный способ.
-
-Одно понятно, задача нетривиальная и малой кровью переиспользования существующих компиляторов `leaf/lomo` как мне кажется нерешаема. Может быть, для начала стоит перевести на общие рельсы имеющиеся системы, что в целом равносильно их переписыванию.
+---
+published: true
+layout: post
+---
+
+После первого прототипа дело o.t. застопорилось и неспроста.
+Я начал повторять шаги, по которым до меня прошло уже много людей и коллективов, а с коллективами тягаться смысла нет.
+Поэтому всякие плюшки типа аналога xpath или применения relaxng теперь кажутся неинтересными.
+
+Со встраиванием языков программирования тоже проблема. Получается, что нет возможности встроить языки в шаблонизатор на уровне библиотеки и необязательного компонента.
+Уже на уровне сканнера символов сталкиваемся с необходимостью двух различных обработчиков одного и того же символа, что само по себе лишает сканнер обероновской простоты.
+Возможно на этом этапе стоит оформить сканнер и парсер по-другому.
+
+Что тут можно предложить?
+
+* Первой на ум приходит мысль о модели производитель-потребитель. Сканнер становится нерасширяемым и монолитным и потребляет любой символ, даже тот, который ему незнаком. Минус очевиден, вся работа по осознанию семантики прочитанного становится задачей потребителя, что не очень хорошо с точки зрения разделения ответственности.
+
+* Второй способ довольно банален, монолитный парсер со сменными стратегиями разбора символов. Сканнер включает в себя сразу все возможные символы и предопределенные идентификаторы. Минус очевиден, возможные интерференции между синтаксисами языков внутри сканнера. Сложный компилятор с кучей дублирующегося по сути кода для разных режимов разбора, что почти не решается шаблонизацией или обобщением. Просто чуть разный, но однообразный код.
+
+* Третий способ полностью противоречит исходному желанию органично встроить исполняемый код в шаблон, мне придётся реализовать код в шаблонах как полностью отдельную сущность и разделять их с шаблоном уже на уровне текстового представления. Удобный, но антиконцептуальный способ.
+
+Одно понятно, задача нетривиальная и малой кровью переиспользования существующих компиляторов `leaf/lomo` как мне кажется нерешаема. Может быть, для начала стоит перевести на общие рельсы имеющиеся системы, что в целом равносильно их переписыванию.

_posts/2015-10-28-Очередной-язычок.md

@@ -1,28 +1,28 @@
----
-published: true
-layout: post
----
-И снова от безделья появляются идеи написать очередной (да) язык. Оглядев `LEAF`, `LOMO` и `o.t.` для себя понял, что многие идеи хоть и звучат разумно, но выглядят при этом совершенно отвратительно.
-
-Чего стоит хотя бы вызов процедур, обязательно указывать именование входного параметра это конечно хорошо, но во-первых, их не всегда помнишь, а во-вторых, конструкция получается очень сложной.
-
-    Call(x: 1, y <- my.y, res -> x)
-
-Сложновато, как не крути. Получается, что порядок аргументов процедуры важен.
-Из этого вытекает необходимость в сигнатуре процедуры описывать всё именно так, как в Обероне `PROCEDURE Call(x: INTEGER; IN y: INTEGER; OUT x: INTEGER)`, что конечно неплохо (в очередной раз удивляюсь продуманности Оберона), но не оставляет пространства для маневра. И еще в этой форме записи всего полшага остаётся для признания процедуры функцией, со всеми вытекающими последствиями.
-
-И таких моментов много. Навигация внутри `MAP` требует постоянного разыменования значения. Так как цепочки селекторов я не реализовал, навигация требует ещё и кучи временных переменных.
-
-Сами селекторы, как показал `LOMO`, тоже могут быть довольно нетривиальной сущностью. Тут проходит трудноуловимая грань между строгой и нестрогой типизацией, когда цепочки селекторов должны неявно разыменовывать значение. А это значит, что на каждом этапе разыменования внутри может оказаться `UNDEF`-значение или вообще примитивный тип.
-
-Плюс к этому, сама идея разных языков с очень похожей (очень) системой типов намекает на то, что по факту это как будто один язык, мультипарадигменный, но при этом принципиально по-разному обращающийся с рантаймом и переменными. А ведь иногда действительно декларативный подход выглядел бы лучше и проще даже внутри полностью императивного кода. Но смешение парадигм это довольно опасная дорожка.
-
-А тут ещё и язык шаблонов сам собой нарисовался. Простой способ описывать всякие объекты, произвольной природы, но при этом человекотипизированные (то есть человек понимает семантику чисто из описания, из текстового представления шаблона объекта). Интересные возможности открываются.
-
-При этом недостатков в `o.t.` тоже хватает, например, необходимость закрывающего элемента, обозначающего конец содержимого. Никак я не придумал способ обнаруживать конец содержимого автоматически.
-Так же плохой идеей было переиспользование объектов. Точнее, идея хорошая, но по факту получилось слишком сложно, как в разборе, так и в понимании.
-А еще я не реализовал программирование внутри шаблонов, не осилил. Отсюда, в общем, и мысли о новом язычке, в котором, ну правда-правда, всё будет идеально продумано и реализовано.
-
-Главное не перечитывать пост про жизненный цикл программы, а то можно до конца года так и сидеть, продумывая каждый этап.
-
-В общем, пройдя по пути создания императивного языка, декларативного языка и языка разметки я снова оказался в начале пути.
+---
+published: true
+layout: post
+---
+И снова от безделья появляются идеи написать очередной (да) язык. Оглядев `LEAF`, `LOMO` и `o.t.` для себя понял, что многие идеи хоть и звучат разумно, но выглядят при этом совершенно отвратительно.
+
+Чего стоит хотя бы вызов процедур, обязательно указывать именование входного параметра это конечно хорошо, но во-первых, их не всегда помнишь, а во-вторых, конструкция получается очень сложной.
+
+    Call(x: 1, y <- my.y, res -> x)
+
+Сложновато, как не крути. Получается, что порядок аргументов процедуры важен.
+Из этого вытекает необходимость в сигнатуре процедуры описывать всё именно так, как в Обероне `PROCEDURE Call(x: INTEGER; IN y: INTEGER; OUT x: INTEGER)`, что конечно неплохо (в очередной раз удивляюсь продуманности Оберона), но не оставляет пространства для маневра. И еще в этой форме записи всего полшага остаётся для признания процедуры функцией, со всеми вытекающими последствиями.
+
+И таких моментов много. Навигация внутри `MAP` требует постоянного разыменования значения. Так как цепочки селекторов я не реализовал, навигация требует ещё и кучи временных переменных.
+
+Сами селекторы, как показал `LOMO`, тоже могут быть довольно нетривиальной сущностью. Тут проходит трудноуловимая грань между строгой и нестрогой типизацией, когда цепочки селекторов должны неявно разыменовывать значение. А это значит, что на каждом этапе разыменования внутри может оказаться `UNDEF`-значение или вообще примитивный тип.
+
+Плюс к этому, сама идея разных языков с очень похожей (очень) системой типов намекает на то, что по факту это как будто один язык, мультипарадигменный, но при этом принципиально по-разному обращающийся с рантаймом и переменными. А ведь иногда действительно декларативный подход выглядел бы лучше и проще даже внутри полностью императивного кода. Но смешение парадигм это довольно опасная дорожка.
+
+А тут ещё и язык шаблонов сам собой нарисовался. Простой способ описывать всякие объекты, произвольной природы, но при этом человекотипизированные (то есть человек понимает семантику чисто из описания, из текстового представления шаблона объекта). Интересные возможности открываются.
+
+При этом недостатков в `o.t.` тоже хватает, например, необходимость закрывающего элемента, обозначающего конец содержимого. Никак я не придумал способ обнаруживать конец содержимого автоматически.
+Так же плохой идеей было переиспользование объектов. Точнее, идея хорошая, но по факту получилось слишком сложно, как в разборе, так и в понимании.
+А еще я не реализовал программирование внутри шаблонов, не осилил. Отсюда, в общем, и мысли о новом язычке, в котором, ну правда-правда, всё будет идеально продумано и реализовано.
+
+Главное не перечитывать пост про жизненный цикл программы, а то можно до конца года так и сидеть, продумывая каждый этап.
+
+В общем, пройдя по пути создания императивного языка, декларативного языка и языка разметки я снова оказался в начале пути.

_posts/2015-11-01-Непонятно.md

@@ -1,7 +1,7 @@
----
-published: true
-layout: post
----
-Сильно интересный вопрос, какой выбрать язык и платформу для реализации очередного язычка, а заодно и опять думаю, надо ли вообще этим заниматься...
-
-Вопрос не праздный. 
+---
+published: true
+layout: post
+---
+Сильно интересный вопрос, какой выбрать язык и платформу для реализации очередного язычка, а заодно и опять думаю, надо ли вообще этим заниматься...
+
+Вопрос не праздный. 

_posts/2015-11-04-Такая-мысль.md

@@ -1,18 +1,18 @@
----
-published: true
-layout: post
----
-
-Так как прошлые язычки в основном про алгоритмы (декларативные/императивные), и только чуть-чуть про данные (в виде dom), то логично предположить, что надо расширить эксперименты на системы типов и прочее.
-
-Проблема в целом известная, любой пользовательский тип данных почти всегда лишён возможности описать для этого типа литерал в пользовательском формате, операции тоже зачастую неприменимы. Перегрузка операторов и прочее это конечно зло. Но что может быть концептуальным решением этой проблемы?
-
-В Оберонах выбран путь классического наследования. В КП добавлены абстрактные и полу-абстрактные типы, разделение доступа к методам при переопределении. В go вообще наследования нет, как такового. Множество вариантов.
-
-Отдельным пунктом можно отметить псевдонимы и/или расширение пользователем примитивных типов, базовых сложных типов.
-
-Так же встаёт вопрос о необходимости встроенных в язык сложных типов данных, типа `MAP` в `LEAF`.
-
-Если программы, это алгоритмы + структуры данных, и с алгоритмами мы уже разобрались, надо переходить к структурам данных.
-
-Решил начать издалека и как-то обобщить предыдущий опыт разработки компиляторов в виде [универсального сканнера/полупарсера](https://github.com/kpmy/tier) для будущего проекта.
+---
+published: true
+layout: post
+---
+
+Так как прошлые язычки в основном про алгоритмы (декларативные/императивные), и только чуть-чуть про данные (в виде dom), то логично предположить, что надо расширить эксперименты на системы типов и прочее.
+
+Проблема в целом известная, любой пользовательский тип данных почти всегда лишён возможности описать для этого типа литерал в пользовательском формате, операции тоже зачастую неприменимы. Перегрузка операторов и прочее это конечно зло. Но что может быть концептуальным решением этой проблемы?
+
+В Оберонах выбран путь классического наследования. В КП добавлены абстрактные и полу-абстрактные типы, разделение доступа к методам при переопределении. В go вообще наследования нет, как такового. Множество вариантов.
+
+Отдельным пунктом можно отметить псевдонимы и/или расширение пользователем примитивных типов, базовых сложных типов.
+
+Так же встаёт вопрос о необходимости встроенных в язык сложных типов данных, типа `MAP` в `LEAF`.
+
+Если программы, это алгоритмы + структуры данных, и с алгоритмами мы уже разобрались, надо переходить к структурам данных.
+
+Решил начать издалека и как-то обобщить предыдущий опыт разработки компиляторов в виде [универсального сканнера/полупарсера](https://github.com/kpmy/tier) для будущего проекта.

_posts/2015-11-05-Не-всё-так-просто.md

@@ -1,14 +1,14 @@
----
-published: true
-layout: post
----
-
-Довольно быстро выяснилось, что, так скажем, обобщить парсер невозможно. Есть возможность выделить в парсерах похожих языков некоторые одинаковые части, но на этом обобщение и закончится. Потому что даже разбор выражений зависит от определенной конкретной грамматики. Беглый поиск не дал информации о каком-то способе обобщения любых выражений (expressions) хотя бы арифметики. И это 2015-й год. Каждый лепит что-то своё, у кого `OR`, у кого `||`, у кого `or`, у кого `^`, у кого `**`, `=`, `->`, `:=`, и так далее, про целочисленное деление вообще молчу. Позорище вселенского масштаба. Никакой возможности обобщить и унифицировать.
-
-Не зря Н. Вирт не стеснялся дублировать код компилятора от проекта к проекту, раз за разом, жестоко нарушая принцип DRY, чем очень злил вчерашних школьников, угоревших по всяким красивым принципам, манифестам, высерам Макконелла и так далее.
-
-Ну ничего, даже в варианте с частичным обобщением уже нарисовался один важный паттерн потоковой обработки текста исходника. Его я и описал в соответствующем интерфейсе. Ещё из того, что я помню из разработки компиляторов, всегда было костыльно-проблематично описать результат работы компилятора.
-
-У Вирта это был непосредственно генератор маш.кодов, минимальный объект с кучей полей, сразу видно, автор выделил минимум и его держался. У меня это превратилось в набор билдеров и холдеров, билдер содержит непосредственный результат разбора исходника и производит внутренние трансформации, холдер принимает на хранение результат работы билдера, часто это AST и вспомогательные индексы переменных, полей, параметров и модулей. Довольно странная структура, возможно, она тоже никак не обобщается.
-
-В итоге получится инструментальный набор юного компиляторщика, не иначе. 
+---
+published: true
+layout: post
+---
+
+Довольно быстро выяснилось, что, так скажем, обобщить парсер невозможно. Есть возможность выделить в парсерах похожих языков некоторые одинаковые части, но на этом обобщение и закончится. Потому что даже разбор выражений зависит от определенной конкретной грамматики. Беглый поиск не дал информации о каком-то способе обобщения любых выражений (expressions) хотя бы арифметики. И это 2015-й год. Каждый лепит что-то своё, у кого `OR`, у кого `||`, у кого `or`, у кого `^`, у кого `**`, `=`, `->`, `:=`, и так далее, про целочисленное деление вообще молчу. Позорище вселенского масштаба. Никакой возможности обобщить и унифицировать.
+
+Не зря Н. Вирт не стеснялся дублировать код компилятора от проекта к проекту, раз за разом, жестоко нарушая принцип DRY, чем очень злил вчерашних школьников, угоревших по всяким красивым принципам, манифестам, высерам Макконелла и так далее.
+
+Ну ничего, даже в варианте с частичным обобщением уже нарисовался один важный паттерн потоковой обработки текста исходника. Его я и описал в соответствующем интерфейсе. Ещё из того, что я помню из разработки компиляторов, всегда было костыльно-проблематично описать результат работы компилятора.
+
+У Вирта это был непосредственно генератор маш.кодов, минимальный объект с кучей полей, сразу видно, автор выделил минимум и его держался. У меня это превратилось в набор билдеров и холдеров, билдер содержит непосредственный результат разбора исходника и производит внутренние трансформации, холдер принимает на хранение результат работы билдера, часто это AST и вспомогательные индексы переменных, полей, параметров и модулей. Довольно странная структура, возможно, она тоже никак не обобщается.
+
+В итоге получится инструментальный набор юного компиляторщика, не иначе. 

_posts/2015-11-15-ПЕАР.md

@@ -1,6 +1,6 @@
----
-published: true
-layout: post
----
-
-[![IMAGE ALT TEXT](http://img.youtube.com/vi/R-QBqT9RQAM/0.jpg)](http://www.youtube.com/watch?v=R-QBqT9RQAM "28 панфиловцев")
+---
+published: true
+layout: post
+---
+
+[![IMAGE ALT TEXT](http://img.youtube.com/vi/R-QBqT9RQAM/0.jpg)](http://www.youtube.com/watch?v=R-QBqT9RQAM "28 панфиловцев")

_posts/2015-12-08-Плюгавые-пйоки.md

@@ -1,7 +1,7 @@
----
-published: true
-layout: post
----
-Это будто записная книжка. Всё равно никто не видит. Скука одолевает, ничего невозможно придумать, удержать мысль трудно. Вычислители уже делают всё, что нужно, сомнительно, что придумается что-то новое. Даже этот пост уже давно потерял связь с собственной причиной. Что-то хотелось описать, разложить. Что?
-
-Блоки.
+---
+published: true
+layout: post
+---
+Это будто записная книжка. Всё равно никто не видит. Скука одолевает, ничего невозможно придумать, удержать мысль трудно. Вычислители уже делают всё, что нужно, сомнительно, что придумается что-то новое. Даже этот пост уже давно потерял связь с собственной причиной. Что-то хотелось описать, разложить. Что?
+
+Блоки.

_posts/2015-12-30-Люстрировали.md

@@ -1,51 +1,51 @@
----
-published: true
-layout: post
----
-*Написал тут статью на хабр. Она долго лежала в песочнице. Потом я её вроде хотел поредактировать. Сохранил заново, видимо, она попалась на глаза модератору. Он её сначала пропустил на сайт, там её, конечно, заминусовали. А потом удалили вообще, сказали, что ошибка модератора. Такой день.*
-
-*Текст статьи, раз уж на хабре её не ждут*
-
-Оригинал тут:
-[http://habrahabr.ru/post/274355/](http://habrahabr.ru/post/274355/)
-
-
-## Бессилие умнейших или habralang...
-
-Сколько стоит разработка инфраструктуры разработки? Чем собрать сборочный цех? Как запустить систему запуска? На все эти интересные вопросы приходится отвечать, когда приступаешь к очередному проекту. Когда ТЗ утверждено, наступает мучительный период выбора подходящих технологий. Кто-то выбирает фреймворк, кто-то прочёсывает каталоги расширений, кому-то нужны шаблоны. Всех этих людей объединяет одно — они не создают уже существующих фреймворков, не реализуют расширения, аналогичные зарегистрированным в каталоге, новых шаблонов тоже не пишут. Не плодят велосипеды. Не повторяют себя других. Решает задачи бизнеса оптимальным образом.
-
-Работа в таком стиле неизбежно влияет на общие профессиональные навыки. Схожие профессиональные навыки многих людей формируют критерии оценки. Критерии становятся основой запросов индустрии к внешнему миру, к системе образования, к соискателям и даже к заказчикам.
-
-Вполне нормальной считается ситуация, при которой знание определённых фреймворков (даже в отрыве от понимания их внутреннего устройства) выглядит преимуществом соискателя, а знание теории никак не влияет на успехи в поиске работы.
-
-Можно привести пример многих ситуаций, каждый из которых только будет подтверждать нашу гипотезу о том, что удивительный мир программирования в своей основе почти всегда содержит массовые инфраструктурные продукты, проверенные временем. Это касается языков программирования, фреймворков и так далее.
-
-И возвращаясь к началу рассуждения, постараемся дать ответ, кто же стоит за этими инфраструктурными продуктами? Две, три, десять компаний? Несколько консорциумов, в составе которых те же десять компаний? Да, стоит признать, что понятие монополий применимо не только к рыночным игрокам. Дальше больше. Так как технологии работают непосредственно, их нельзя юридически извратить, к ним нельзя применить процедуру банкротства или реорганизации, получается, что степень привязки ваших продуктов к инфраструктурным продуктам крайне высока. А где привязка, там и контроль. Влияние экосистемы на ваш продукт, ваш стиль работы, ваш разум, в конце концов.
-
-Влияние экосистем нельзя было не заметить, и в какой-то момент это стало настолько очевидным, что даже холивары сошли на нет, так как зачастую люди из разных экосистем одинаковые слова интерпретируют по-своему. Особым образом смотрят на мир. Возникает несовместимость не только бинарных протоколов и объектно-реляционных моделей. Возникает несовместимость мировоззрений, и устранять её никто не намерен. Разделяй и управляй. При этом производители инфраструктурных продуктов готовы их даже бесплатно раздавать. Потому что понимают. Асимметрия информации работает на благо десяти компаний.
-
-Ну и что плохого, спросите вы, это лишь разделение труда. Тут очевидный ответ один. Инфраструктурный проект не является целью работы компании. Целью работы компании является зарабатывание денег. А инфраструктурный проект это просто способ превратить много денег в средство привязки и контроля. К конкретной компании. Которая может пойти на дно. Которая может перестать вас любить. Google больше не против зла.
-
-Ответной мерой, как многим кажется, является опенсурс-движение. Однако его возможности ограничены уже на уровне определений. Сложные многолетние проекты просто не потянуть. Никак. Ядро Linux? А сколько коммитов, в процентах, исходит всё от тех же корпораций. По сути, весь опенсурс это соглашение о влиянии корпораций в нейтральных водах. Специальная матрица для врагов матрицы. Выхода нет.
-
-А ведь есть ещё и государства. Пока не устарели, не ушли в прошлое, как многим хочется. Государства имеют интересы, часто противоположные. А корпорации, возможно вопреки своему желанию, всё ещё существуют в рамках конкретных государств и волей-неволей, подчиняются законам этих государств. Следовательно, в какой-то момент международный бизнес и ИТ-шники всей планеты могут оказаться прежде всего лишь гражданами совершенно чужих государств. И поток уже существующих шаблонов, библиотек и фреймворков может прекратиться. Речь тут даже не о патриотизме и оппозиционности к власти государств, это банальный расчёт, если есть зависимость, разрешение которой зависит от факторов, которые вы не контролируете, то в один прекрасный момент зависимость просто не разрешится, проект не соберется и зарплату не выплатят.
-
-Решений много, прежде всего предложат — «валить». Власть или в Америку. Неважно. Мы тут про ИТ. Наукоёмкие проекты. Веб-магазины в конце концов. Инфраструктура не зародится от сквозняка, даже если вы умнейший человек в стране и решили остаться ради принципа.
-
-Исходя из всего этого лично мне с течением времени всё меньше понятны высказывания о ненужности существования в рамках отдельно взятой страны проживания, в великой и могучей Российской Федерации своей операционки, своих телефонов, своих языков программирования для разных сфер деятельности. Своё просто необходимо. А нету. А что есть? А есть смешки, шуточки и презрительный взгляд. «Опять болгенос, фуфу йоптафон, хахаха язык Дракон». И это понятно. Но непонятно, а на что же вы расчитываете?
-
-Уйдут инженеры, программисты, забросят свои болгеносы, будут писать на этой вашей джаве, пока её не отключат. Все же пишут, вы что, самые умные чтоли? Интеллектуальное производство, напряжение ума. Думающие люди со светлыми лицами и европейским мировоззрением в свободное от работы время занимаются тем, что отговаривают коллег по цеху пилить РеактОС? Способы отговаривания тоже заслуживают внимания. Бери чужое, свой велосипед — это удел неразумных людей. Всё равно не получится так же качественно.
-
-Конечно не получится, ребята. Ведь «там» люди делают своё. «Там» первородство. А «здесь» не делают своё. И не научатся. А кто умел, те разучатся. Или разучат. Это мы можем, с этим у нас всё просто. А ну, ребята, навались на выскочек и недоучек.
-
-Даже стране уже не нужно воспитывать фанатов чужого. Она сама об этом говорит. Через обмуд омбуд одбум через своих глашатаев. Скоро и программистов своих не станет.
-
-А заголовок ведь как раз про это? Кажется, целое поколение мировоззренчески не желает иметь ничего своего. И это объяснимо, это нормально. Но разумные люди должны уже наконец сделать выбор. Удручающая картина, тридцатилетние покорители ИТ-вершин бесплодно завершают своё творческое существование в Этой Стране, где место проклято и ничего не растёт, кроме коррупционеров. Но даже им нужно что-то своё, а вам?
-
-А, ну «Эльбрусы», да. С компилятором американских язычков программирования Си/Си++.
-
-На основании всех входных параметров алгоритм вычисления того, как нам дальше жить, должен дать ответ. Где habralang? Где продукт вашего ума сделанный так, как это нужно лично вам? В «Долине»? В Цюрихе? В Амстердаме? Может, в Чехии (где там jetBrains зарегистрированы вместе со своим Котлином)? Нужно нам своё или не нужно? Да или нет? 1 или 0? true или false? Или может, вспомним троичную логику?
-
-Где habra language? Хотя бы в виде обсуждения? На гитхабе, на их площадке, ну и что? Где проекты, предложения? Никого, ничего, пустота и функциональное программирование, на хаскелле. На каком языке говорил автор Хаскелля?
-
-*В комментариях сказали, что это ксенофобская хуйня. Ну вот и всё.*
+---
+published: true
+layout: post
+---
+*Написал тут статью на хабр. Она долго лежала в песочнице. Потом я её вроде хотел поредактировать. Сохранил заново, видимо, она попалась на глаза модератору. Он её сначала пропустил на сайт, там её, конечно, заминусовали. А потом удалили вообще, сказали, что ошибка модератора. Такой день.*
+
+*Текст статьи, раз уж на хабре её не ждут*
+
+Оригинал тут:
+[http://habrahabr.ru/post/274355/](http://habrahabr.ru/post/274355/)
+
+
+## Бессилие умнейших или habralang...
+
+Сколько стоит разработка инфраструктуры разработки? Чем собрать сборочный цех? Как запустить систему запуска? На все эти интересные вопросы приходится отвечать, когда приступаешь к очередному проекту. Когда ТЗ утверждено, наступает мучительный период выбора подходящих технологий. Кто-то выбирает фреймворк, кто-то прочёсывает каталоги расширений, кому-то нужны шаблоны. Всех этих людей объединяет одно — они не создают уже существующих фреймворков, не реализуют расширения, аналогичные зарегистрированным в каталоге, новых шаблонов тоже не пишут. Не плодят велосипеды. Не повторяют себя других. Решает задачи бизнеса оптимальным образом.
+
+Работа в таком стиле неизбежно влияет на общие профессиональные навыки. Схожие профессиональные навыки многих людей формируют критерии оценки. Критерии становятся основой запросов индустрии к внешнему миру, к системе образования, к соискателям и даже к заказчикам.
+
+Вполне нормальной считается ситуация, при которой знание определённых фреймворков (даже в отрыве от понимания их внутреннего устройства) выглядит преимуществом соискателя, а знание теории никак не влияет на успехи в поиске работы.
+
+Можно привести пример многих ситуаций, каждый из которых только будет подтверждать нашу гипотезу о том, что удивительный мир программирования в своей основе почти всегда содержит массовые инфраструктурные продукты, проверенные временем. Это касается языков программирования, фреймворков и так далее.
+
+И возвращаясь к началу рассуждения, постараемся дать ответ, кто же стоит за этими инфраструктурными продуктами? Две, три, десять компаний? Несколько консорциумов, в составе которых те же десять компаний? Да, стоит признать, что понятие монополий применимо не только к рыночным игрокам. Дальше больше. Так как технологии работают непосредственно, их нельзя юридически извратить, к ним нельзя применить процедуру банкротства или реорганизации, получается, что степень привязки ваших продуктов к инфраструктурным продуктам крайне высока. А где привязка, там и контроль. Влияние экосистемы на ваш продукт, ваш стиль работы, ваш разум, в конце концов.
+
+Влияние экосистем нельзя было не заметить, и в какой-то момент это стало настолько очевидным, что даже холивары сошли на нет, так как зачастую люди из разных экосистем одинаковые слова интерпретируют по-своему. Особым образом смотрят на мир. Возникает несовместимость не только бинарных протоколов и объектно-реляционных моделей. Возникает несовместимость мировоззрений, и устранять её никто не намерен. Разделяй и управляй. При этом производители инфраструктурных продуктов готовы их даже бесплатно раздавать. Потому что понимают. Асимметрия информации работает на благо десяти компаний.
+
+Ну и что плохого, спросите вы, это лишь разделение труда. Тут очевидный ответ один. Инфраструктурный проект не является целью работы компании. Целью работы компании является зарабатывание денег. А инфраструктурный проект это просто способ превратить много денег в средство привязки и контроля. К конкретной компании. Которая может пойти на дно. Которая может перестать вас любить. Google больше не против зла.
+
+Ответной мерой, как многим кажется, является опенсурс-движение. Однако его возможности ограничены уже на уровне определений. Сложные многолетние проекты просто не потянуть. Никак. Ядро Linux? А сколько коммитов, в процентах, исходит всё от тех же корпораций. По сути, весь опенсурс это соглашение о влиянии корпораций в нейтральных водах. Специальная матрица для врагов матрицы. Выхода нет.
+
+А ведь есть ещё и государства. Пока не устарели, не ушли в прошлое, как многим хочется. Государства имеют интересы, часто противоположные. А корпорации, возможно вопреки своему желанию, всё ещё существуют в рамках конкретных государств и волей-неволей, подчиняются законам этих государств. Следовательно, в какой-то момент международный бизнес и ИТ-шники всей планеты могут оказаться прежде всего лишь гражданами совершенно чужих государств. И поток уже существующих шаблонов, библиотек и фреймворков может прекратиться. Речь тут даже не о патриотизме и оппозиционности к власти государств, это банальный расчёт, если есть зависимость, разрешение которой зависит от факторов, которые вы не контролируете, то в один прекрасный момент зависимость просто не разрешится, проект не соберется и зарплату не выплатят.
+
+Решений много, прежде всего предложат — «валить». Власть или в Америку. Неважно. Мы тут про ИТ. Наукоёмкие проекты. Веб-магазины в конце концов. Инфраструктура не зародится от сквозняка, даже если вы умнейший человек в стране и решили остаться ради принципа.
+
+Исходя из всего этого лично мне с течением времени всё меньше понятны высказывания о ненужности существования в рамках отдельно взятой страны проживания, в великой и могучей Российской Федерации своей операционки, своих телефонов, своих языков программирования для разных сфер деятельности. Своё просто необходимо. А нету. А что есть? А есть смешки, шуточки и презрительный взгляд. «Опять болгенос, фуфу йоптафон, хахаха язык Дракон». И это понятно. Но непонятно, а на что же вы расчитываете?
+
+Уйдут инженеры, программисты, забросят свои болгеносы, будут писать на этой вашей джаве, пока её не отключат. Все же пишут, вы что, самые умные чтоли? Интеллектуальное производство, напряжение ума. Думающие люди со светлыми лицами и европейским мировоззрением в свободное от работы время занимаются тем, что отговаривают коллег по цеху пилить РеактОС? Способы отговаривания тоже заслуживают внимания. Бери чужое, свой велосипед — это удел неразумных людей. Всё равно не получится так же качественно.
+
+Конечно не получится, ребята. Ведь «там» люди делают своё. «Там» первородство. А «здесь» не делают своё. И не научатся. А кто умел, те разучатся. Или разучат. Это мы можем, с этим у нас всё просто. А ну, ребята, навались на выскочек и недоучек.
+
+Даже стране уже не нужно воспитывать фанатов чужого. Она сама об этом говорит. Через обмуд омбуд одбум через своих глашатаев. Скоро и программистов своих не станет.
+
+А заголовок ведь как раз про это? Кажется, целое поколение мировоззренчески не желает иметь ничего своего. И это объяснимо, это нормально. Но разумные люди должны уже наконец сделать выбор. Удручающая картина, тридцатилетние покорители ИТ-вершин бесплодно завершают своё творческое существование в Этой Стране, где место проклято и ничего не растёт, кроме коррупционеров. Но даже им нужно что-то своё, а вам?
+
+А, ну «Эльбрусы», да. С компилятором американских язычков программирования Си/Си++.
+
+На основании всех входных параметров алгоритм вычисления того, как нам дальше жить, должен дать ответ. Где habralang? Где продукт вашего ума сделанный так, как это нужно лично вам? В «Долине»? В Цюрихе? В Амстердаме? Может, в Чехии (где там jetBrains зарегистрированы вместе со своим Котлином)? Нужно нам своё или не нужно? Да или нет? 1 или 0? true или false? Или может, вспомним троичную логику?
+
+Где habra language? Хотя бы в виде обсуждения? На гитхабе, на их площадке, ну и что? Где проекты, предложения? Никого, ничего, пустота и функциональное программирование, на хаскелле. На каком языке говорил автор Хаскелля?
+
+*В комментариях сказали, что это ксенофобская хуйня. Ну вот и всё.*

_posts/2016-03-23-По-Чапаеву.md

@@ -1,9 +1,9 @@
----
-published: true
-layout: post
----
-*"Ты, Петька, прежде чем о сложных вещах говорить, разберись с простыми."*
-
-А ведь с простыми вещами ещё Дейкстра разобрался. А потом умники начали говорить, что надо прогресс и усложнили всё. Теперь только умный человек может понять подавляющее большинство концепций computer science.
-
-А я не могу. 
+---
+published: true
+layout: post
+---
+*"Ты, Петька, прежде чем о сложных вещах говорить, разберись с простыми."*
+
+А ведь с простыми вещами ещё Дейкстра разобрался. А потом умники начали говорить, что надо прогресс и усложнили всё. Теперь только умный человек может понять подавляющее большинство концепций computer science.
+
+А я не могу. 

_posts/2016-04-28-Про-WebAssebly.md

@@ -1,12 +1,12 @@
----
-published: true
-layout: post
----
-Wasm это значит такая технология, которая как бы slim-binaries, но в 2016-м.
-И оно конечно даже клёво выглядит, подумать только, кто-то додумался наконец-то объединить идею AST и доставки исполняемого кода клиенту.
-
-В сегодняшнем варианте у wasm нет даже устоявшегося текстового представления, но в целом, технология мне нравится, даже сделал для неё смешной демо-проект: [brainfuck2wasm](https://github.com/kpmy/tiss/tree/master/demo/bf)
-
-Конечно, в РФ сегодня не найти людей, серьёзно устремлённых на построение собственной экосистемы. Поэтому остаётся следить, чем же там заняты зарубежные прогрессивные личности. Вот, М. Франца копируют.
-
-Разработчик wasm обещает смену текстового представления в ближайшие месяцы, поэтому наверное подожду этого этапа, там и созрею до построения компилятора очередного обероноподобного языка для wasm. Хотя, кому это надо.
+---
+published: true
+layout: post
+---
+Wasm это значит такая технология, которая как бы slim-binaries, но в 2016-м.
+И оно конечно даже клёво выглядит, подумать только, кто-то додумался наконец-то объединить идею AST и доставки исполняемого кода клиенту.
+
+В сегодняшнем варианте у wasm нет даже устоявшегося текстового представления, но в целом, технология мне нравится, даже сделал для неё смешной демо-проект: [brainfuck2wasm](https://github.com/kpmy/tiss/tree/master/demo/bf)
+
+Конечно, в РФ сегодня не найти людей, серьёзно устремлённых на построение собственной экосистемы. Поэтому остаётся следить, чем же там заняты зарубежные прогрессивные личности. Вот, М. Франца копируют.
+
+Разработчик wasm обещает смену текстового представления в ближайшие месяцы, поэтому наверное подожду этого этапа, там и созрею до построения компилятора очередного обероноподобного языка для wasm. Хотя, кому это надо.

_posts/2016-04-30-Монополист-то-голый.md

@@ -1,9 +1,9 @@
----
-published: true
-layout: post
----
-
-Подумал тут, что Habrahabr как объединение умов русскоязычных программистов уже давно стал монополистом, то есть никто другой уже не сможет вырасти рядом до конкурентноспособных размеров.
-Вместе с этим, внутри таких сообществ, как показали исследования, формируется своеобразная олигархия, в полном соответствии с железным правилом. Стало быть, и внутри сообщества монополизирована социальная мощь, следовательно, никакой движухи внутри быть не может, выбившихся со своей социальной роли тут же порешат богатые кармовладельцы. Порешат показательно, не взирая на нарушение мыслимых и немыслимых норм приличия в интеллектуальной и околонаучной среде.
-
-Войлок, что и говорить. 
+---
+published: true
+layout: post
+---
+
+Подумал тут, что Habrahabr как объединение умов русскоязычных программистов уже давно стал монополистом, то есть никто другой уже не сможет вырасти рядом до конкурентноспособных размеров.
+Вместе с этим, внутри таких сообществ, как показали исследования, формируется своеобразная олигархия, в полном соответствии с железным правилом. Стало быть, и внутри сообщества монополизирована социальная мощь, следовательно, никакой движухи внутри быть не может, выбившихся со своей социальной роли тут же порешат богатые кармовладельцы. Порешат показательно, не взирая на нарушение мыслимых и немыслимых норм приличия в интеллектуальной и околонаучной среде.
+
+Войлок, что и говорить. 

_posts/2016-05-09-Изобретая-велосипед.md

@@ -1,18 +1,18 @@
----
-published: true
-layout: post
----
-
-Пришло время вспомнить про концепцию жизненного цикла программы. Вот его этапы:
-
-![](https://raw.githubusercontent.com/kpmy/kpmy.github.io/master/_posts/code-life-line.png)
-
-В ситуации недостаточных ресурсов для полноценной проработки этих этапов на уровне хорошей годной бинарной кроссплатформенности ничего не остаётся кроме как загнать всё это дело в эмулятор, виртуальную машину, которую можно реализовать для любой подходящей по возможностям экосистемы. А потом уже раскрутиться до полноценного продукта.
-
-В ожидании релиза webassebmbly можно выработать набор собственных примитивов, сводимых к wasm-примитивам, благо не нужно работать для бизнеса, на надёжность и окупаемость.
-
-Возможно ли минимальными выразительными средствами обеспечить приемлимую реализацию всего этого великолепия, пока не ясно.
-
-Плюс ко всему остался нерешённым вопрос совмещения декларативного и императивного подхода, многопоточного и однопоточного кода, возможности выполнения кода на разных вычислительных платформах (гетерогенные вычисления) и так далее.
-
-Короче, надо обозначить ближайшую цель: получить виртуализированную программную платформу, в которой возможна реализация и исполнение программных модулей, отвечающих концепции жизненного цикла программы.
+---
+published: true
+layout: post
+---
+
+Пришло время вспомнить про концепцию жизненного цикла программы. Вот его этапы:
+
+![](https://raw.githubusercontent.com/kpmy/kpmy.github.io/master/_posts/code-life-line.png)
+
+В ситуации недостаточных ресурсов для полноценной проработки этих этапов на уровне хорошей годной бинарной кроссплатформенности ничего не остаётся кроме как загнать всё это дело в эмулятор, виртуальную машину, которую можно реализовать для любой подходящей по возможностям экосистемы. А потом уже раскрутиться до полноценного продукта.
+
+В ожидании релиза webassebmbly можно выработать набор собственных примитивов, сводимых к wasm-примитивам, благо не нужно работать для бизнеса, на надёжность и окупаемость.
+
+Возможно ли минимальными выразительными средствами обеспечить приемлимую реализацию всего этого великолепия, пока не ясно.
+
+Плюс ко всему остался нерешённым вопрос совмещения декларативного и императивного подхода, многопоточного и однопоточного кода, возможности выполнения кода на разных вычислительных платформах (гетерогенные вычисления) и так далее.
+
+Короче, надо обозначить ближайшую цель: получить виртуализированную программную платформу, в которой возможна реализация и исполнение программных модулей, отвечающих концепции жизненного цикла программы.

_posts/2016-05-09-Про-Electron.md

@@ -1,6 +1,6 @@
----
-published: true
-layout: post
----
-
-Лет пять назад уже всем было понятно, что развитие отобразительных средств браузера идёт, а развитие отобразительных средств десктопного гуя остановилось. Не спасло даже Windows Modern UI. А теперь вот, совсем хорошо, гуй десктопного приложения строится в браузерном движке с помощью html/css/js. Такой мир. Этим мог стать BlackBox. Но не стал.
+---
+published: true
+layout: post
+---
+
+Лет пять назад уже всем было понятно, что развитие отобразительных средств браузера идёт, а развитие отобразительных средств десктопного гуя остановилось. Не спасло даже Windows Modern UI. А теперь вот, совсем хорошо, гуй десктопного приложения строится в браузерном движке с помощью html/css/js. Такой мир. Этим мог стать BlackBox. Но не стал.

_posts/2016-05-13-Первые-результаты.md

@@ -1,9 +1,9 @@
----
-published: true
-layout: post
----
-За пару дней, с большой осторожностью, накидал прототип own2js-компилятора по мотивам lomo/leaf [тут](https://github.com/kpmy/own).
-Конечно, он пока больше завязан на nodejs, нежели на electron в целом, но получается, что electron, как устройство вывода должен появиться чуть позже.
-Язык `own` пока ничего из себя не представляет, концепцию я пока не придумал, но модуль описать/транспилировать/загрузить динамически уже можно. Ура!
-
-Если позиционировать этот продукт, как собственный вариант BlackBox, то нужно глубже погружаться в систему типов КП, так как управляющих инструкций в КП не так много, и они не самые важные (ну, кроме эффективного WITH). С другой стороны, кому нужен будет Оберон, всегда смогут взять `oberonjs`, тут почти ничего делать не потребуется, `own` же в целом должен быть в чём-то концептуальным, так что надо изучить системы типов народов мира :D
+---
+published: true
+layout: post
+---
+За пару дней, с большой осторожностью, накидал прототип own2js-компилятора по мотивам lomo/leaf [тут](https://github.com/kpmy/own).
+Конечно, он пока больше завязан на nodejs, нежели на electron в целом, но получается, что electron, как устройство вывода должен появиться чуть позже.
+Язык `own` пока ничего из себя не представляет, концепцию я пока не придумал, но модуль описать/транспилировать/загрузить динамически уже можно. Ура!
+
+Если позиционировать этот продукт, как собственный вариант BlackBox, то нужно глубже погружаться в систему типов КП, так как управляющих инструкций в КП не так много, и они не самые важные (ну, кроме эффективного WITH). С другой стороны, кому нужен будет Оберон, всегда смогут взять `oberonjs`, тут почти ничего делать не потребуется, `own` же в целом должен быть в чём-то концептуальным, так что надо изучить системы типов народов мира :D

_posts/2016-05-25-Язык-твой-враг-твой.md

@@ -1,22 +1,22 @@
----
-published: true
-layout: post
----
-Конечно же, новый язычок не мог обойтись без гибкой концепции процедурных блоков. 
-
-````
-  BLOCK Add 
-  	VAR x, y, res INTEGER
-  	PAR x, y, res* FUNC res(x, y) 
-  BEGIN
-  	a + b -> res
-  END Add
-  
-  Add[1, 2, fx]
-  Add[x: 1, y: 2, res::fx]
-  Add(1, 2) -> fx
-  Add(x: 1, y: 2) -> fx
-  1 \Add 2 -> fx
-````
-
-Тут тебе и процедура, и процедура с переменным числом параметров, и функция, и наличие именованных параметров, и даже, не может быть, инфиксный вызов (надо ограничить его только для одного и двух операндов)!
+---
+published: true
+layout: post
+---
+Конечно же, новый язычок не мог обойтись без гибкой концепции процедурных блоков. 
+
+````
+  BLOCK Add 
+  	VAR x, y, res INTEGER
+  	PAR x, y, res* FUNC res(x, y) 
+  BEGIN
+  	a + b -> res
+  END Add
+  
+  Add[1, 2, fx]
+  Add[x: 1, y: 2, res::fx]
+  Add(1, 2) -> fx
+  Add(x: 1, y: 2) -> fx
+  1 \Add 2 -> fx
+````
+
+Тут тебе и процедура, и процедура с переменным числом параметров, и функция, и наличие именованных параметров, и даже, не может быть, инфиксный вызов (надо ограничить его только для одного и двух операндов)!

_posts/2016-05-29-О-системе-типов.md

@@ -1,27 +1,27 @@
----
-published: true
-layout: post
----
-
-Развитие `Own/L` встало на стабильные рельсы. Каждый элемент цепочки (компилятор, кодогенератор, рантайм) сейчас позволяют в рабочем режиме добавить новую фичу языка без проблем.
-
-Появилось время подумать, куда двигаться дальше. Наибольшие опасения вызывает этап выбора системы типов. Про системы типов написано много умных слов, чем дальше, тем сильнее все эти слова сводятся к описанию имплементации системы типов в языке haskell, как будто ничего лучше человечество не придумало.
-
-Если не брать от безысходности готовую систему типов Оберона, а немного подумать, то ситуация ещё больше ухудшается. Во-первых, есть определённый провал между простым определением типа и его математическим развитием, все эти декартовы произведения, мощности и прочее.
-Отдельная проблема это обратный переход, так как математику развили хорошо, уже непонятно, как спуститься на землю, к числам, спискам и объектам.
-Взять, например, дескрипционную логику, которая является формальной основой для систем онтологий.
-Да, концепции, роли, индивиды, это похоже на типы, свойства и объекты. Но как именно перейти к тому, что будет понятно говнокодеру - не сказано.
-
-Опять же, Вирт в AD предлагает простые понятия, но он это всё предлагает с послезнанием, он уже знает всё это и говорит сразу правду, что не оставляет шанса дойти до всего самому.
-
-Надо думать.
-
-Пока что принимаем за отправную точку определение: *тип данных — допустимое множество значений объекта*.
-
-Данное определение сразу предъявляет ряд требований ко всей системе - наличие объектов и значений, возможность определить множество этих значений.
-
-Допустим, объекты это переменные и параметры процедур. Значения - это литералы и результат вычисления выражений, а так же константы (пока отсутствуют в языке).
-
-Первый вывод - могут быть объекты, которые принимают любое значение, точнее, значение любого типа. То есть, формально это будет объект с нулевым типом, без типа, но в языке со строгой типизацией это будет объект с типом `ANY`. При этом, предполагается, что значение так же может быть не установлено, чему соответствует значение `NONE`.
-
-Пока всё :(
+---
+published: true
+layout: post
+---
+
+Развитие `Own/L` встало на стабильные рельсы. Каждый элемент цепочки (компилятор, кодогенератор, рантайм) сейчас позволяют в рабочем режиме добавить новую фичу языка без проблем.
+
+Появилось время подумать, куда двигаться дальше. Наибольшие опасения вызывает этап выбора системы типов. Про системы типов написано много умных слов, чем дальше, тем сильнее все эти слова сводятся к описанию имплементации системы типов в языке haskell, как будто ничего лучше человечество не придумало.
+
+Если не брать от безысходности готовую систему типов Оберона, а немного подумать, то ситуация ещё больше ухудшается. Во-первых, есть определённый провал между простым определением типа и его математическим развитием, все эти декартовы произведения, мощности и прочее.
+Отдельная проблема это обратный переход, так как математику развили хорошо, уже непонятно, как спуститься на землю, к числам, спискам и объектам.
+Взять, например, дескрипционную логику, которая является формальной основой для систем онтологий.
+Да, концепции, роли, индивиды, это похоже на типы, свойства и объекты. Но как именно перейти к тому, что будет понятно говнокодеру - не сказано.
+
+Опять же, Вирт в AD предлагает простые понятия, но он это всё предлагает с послезнанием, он уже знает всё это и говорит сразу правду, что не оставляет шанса дойти до всего самому.
+
+Надо думать.
+
+Пока что принимаем за отправную точку определение: *тип данных — допустимое множество значений объекта*.
+
+Данное определение сразу предъявляет ряд требований ко всей системе - наличие объектов и значений, возможность определить множество этих значений.
+
+Допустим, объекты это переменные и параметры процедур. Значения - это литералы и результат вычисления выражений, а так же константы (пока отсутствуют в языке).
+
+Первый вывод - могут быть объекты, которые принимают любое значение, точнее, значение любого типа. То есть, формально это будет объект с нулевым типом, без типа, но в языке со строгой типизацией это будет объект с типом `ANY`. При этом, предполагается, что значение так же может быть не установлено, чему соответствует значение `NONE`.
+
+Пока всё :(

_posts/2016-07-01-Статейка-про-OT.md

@@ -1,167 +1,167 @@
-Неделя самописных языков разметки на Habrahabr. Статья про AXON напомнила мне про мой проектик `o.t` - object template language. В нём я соединил интересные идеи из XML, yaml и прочих.
-
-### Что, ещё один?
-
-Велосипеды бывают разные. Мне например, было интересно попробовать создать именно язык описания данных и в какой-то степени язык разметки.
-
-<cut text="что из этого получилось" />
-
-### TL;DR
-````xml
-<note status="saved">
-  <to>Tove</to>
-  <from>Jani</from>
-  <heading>Reminder</heading>
-  <body>Don't forget me this weekend!</body>
-</note>
-````
-
-````
-note:
-  status :: saved;
-  to: "Tove";
-  from: "Jani";
-  heading: 'Reminder';
-  body: `Don't forget me this weekend!`;
-;
-````
-
-### Концепция
-Изначально, хотелось что-то типа языка программирования внутри DOM, чтобы код всегда выполнялся в контексте того или иного узла, чтобы можно было осуществлять навигацию по DOM управляющими инструкциями языка, переменные и объекты рантайм маппит в DOM-узел контекста и т.д. и т.п. В итоге, первый вариант концепции успешно вылетел из памяти.
-
-Второй вариант намного проще, и вообще не про программирование, как таковое. Он скорее про шаблоны, в том виде, в котором они представлены в технологии JSP, когда xhtml перемешивается с управляющими элементами. При этом замечено, что jsp неплохо подходит для чистой шаблонизации, без программирования. Но там же XML, великий и ужасный.
-
-А что есть кроме, JSON, YAML и TOML (.ini на стероидах). Первый описывает примитивные типы, объекты и массивы javascript, второй делает то же самое, но без курли-скобочек, а третий вообще не о том. От XML их всех отличает только одно, они описывают объект через его свойства, предполагается при этом, что при необходимости, пользователь добавит объекту поле `type` и опишет класс объекта.
-В xml объект описывается непосредственно как экземпляр класса, и потом при необходимости могут быть указаны дополнительные поля, типа идентификатора.
-
-Что же будет, если объединить простоту YAML и концепцию объектов из xml? Правильно - object template language, экспериментальный человекочитаемый язык описания данных, структур и шаблонов..
-
-### O.T.
-Схематически, весь OT можно описать одной строчкой `module~class(id): content;` то есть это модульный язык рекурсивных объектных шаблонов. Кроме этого, присутствуют дополнительные типы данных помимо строк, и отсуствуют ассоциативные массивы, которые типа объекты из json, как неконцептуальная сущность.
-
-Помимо текстовых идентификаторов, строковых, булевых, целочисленных и вещественных констант присутствуют некоторые символы, позволяющие описывать древовидные структуры объектов (object model). Так же присутствует ссылочный тип для построения других видов структур-графов.
-
-Любое пустое пространство между идентификаторами, группами идентификаторов, символами разметки и константами игнорируется и используется для разделения значимых символов, но не включается в содержимое объекта. Внутри символов-кавычек любое пустое пространство учитывается.
-
-### Объектная модель
-
-Любой шаблон представляет собой один объект, который является корневым. Любой объект, в т.ч. корневой представляется как минимум идентификатором класса объекта, и опционально идентификаторами модуля и уникальным идентификатором объекта:
-
-    module~class(id)
-
-Например, для html-страницы существует объект класса `body`, который может быть предварен идентификатором модуля, из которого взят этот класс (`html~body`). Этот объект наделяется идентификатором `index-page`, по которому можно установить связь с объектом через ссылку `@index-page`.
-
-    body
-    html~body
-    html~body(index-page)
-    @index-page
-
-Объекты могут быть вложены друг в друга, таким образом первый объект будет содержать в себе второй объект, устанавливается связь родитель-потомок.
-
-    html:
-      body
-    ;
-
-Внутреннее содержимое объекта начинается после символа `:`. Всё содержимое вплоть до соответствующего символа `;` будет считаться принадлежащим объекту-родителю. Если объект не предполагает содержимого, символы `:;` не указываются.
-
-При этом важно помнить, что обязательным для любого объекта является идентификатор класса объекта, то есть, два и более одинаковых идентификатора класса в шаблоне будут соответствовать двум и более экземплярам класса.
-
-    html:
-      body: br br br;
-    ;
-
-#### Повторное использование
-
-Для объектов, содержимое которых может быть описано в нескольких местах шаблона, возможно указать такой режим описания содержимого, при котором создание нового экземпляра класса не будет производиться, и всё содержимое будет принадлежать одному экземпляру данного класса в рамках родительского объекта. Это достигается использованием символа `::` открывающего содержимое.
-
-    xml:
-      attr ::
-        id: "my-xml";
-      ;
-      attr ::
-        xmlns: "urn:oberon:ot";
-      ;
-    ;
-
-В режиме повторного использования учитываются не только класс но и другие параметры объекта, его модуль и идентификатор.
-
-### Другое содержимое
-
-Помимо объектов-потомков, в родительский объект могут быть включены различные константы и ссылки на объекты. При этом для разделения отдельных элементов содержимого используется пустое пространство.
-
-    html:
-      head:
-        title: "Привет, Мир!";
-      ;
-      body:
-        p: 2 "+" 2 "=" 4.0;
-        concat: "Hello":':':"World":"!";
-      ;
-    ;
-
-Текстовое содержимое указывается в кавычках разных типов: `'`, `"`, и \`, при этом возможно указание отдельного символа текста в одинарных кавычках `'` и с помощью шестнадцатеричного кода (например `0DU`) с модификатором `U` на конце. Текст может содержать переносы строки и любые другие символы unicode. Есть возможность конкатенации строки и символов с помощью символа `:` расположенного между двумя и более частями строк. Результирующая строка будет представлена в объектной модели как одна строка.
-
-### Модульность
-
-Модульность в самом простом виде позволяет визуально разделять одноименные классы объектов различной природы. Например, `html~body` и `human~body`. Модульность в объектной модели предполагает так же наличие поддержки контекстом некоторых модулей, расширенная функциональность которых позволяет расширить возможности работы с шаблоном в рантайме.
-
-#### Стандартные модули и классы
-
-Стандартные модули предоставляют дополнительные возможности рантайма для объектной модели.
-
-##### core
-
-Модуль `core` является встроенным модулем, а так же базовым модулем. Для начала использования модуля `core` необходимо создать экземпляр класса `core~template` как корневой объект шаблона. Тем самым всё содержимое корневого элемента сможет обращаться к классам модуля `core`. В других случаях функциональность модуля `core` отключена.
-
-    core~template:
-      (* ваше содержимое *)
-    ;
-
-Модуль `core` предоставляет класс `import`, который позволяет описывать зависимости шаблона от сторонних шаблонов (стандартных, пользовательских, виртуальных и  т.д.).
-
-    core~template:
-      import: context;
-    ;
-
-Внутри объекта типа `core~template` действует неявное указание модуля для известных классов, таких как `import` и для импортированных классов действует такое же правило, поэтому нет необходимости (но возможность остаётся) указывать модуль `core` и другие импортированные модули каждый раз.
-
-Например:
-
-    core~template:
-      import: html;
-      html: body: p: "Привет, Мир!";;;
-    ;
-
-Классы `html`, `body` и `p` принадлежат модулю `html` и их принадлежность контролируется рантаймом, но при этом указывать их модуль явно не требуется.
-
-
-### Шаблонизация и пользовательские данные
-
-#### context
-Модуль `core` предоставляет класс `context` который является идентификатором модуля `context`.
-Модуль `context` предоставляет доступ к данным контекста существования объектной модели. Обращение к объектам модели через специальные классы модуля `context` позволит размещать в содержимом шаблона данные из рантайма.
-
-Например, класс `context~$` позволяет обратиться к данным контекста по идентификатору или иерархическому набору идентификаторов.
-
-    core~template:
-      import: context;
-      $(hello-world-text)`, `$(user-names/hello-world-user)`!`
-    ;
-
-Таким образом, в зависимости от данных, размещенных в контексте каким-либо образом и доступных по заданным идентификаторам, после обработки текста шаблона и построения объектной модели мы получим итоговый объект с заданными значениями.
-
-    core~template:
-      import: context;
-      `Здравствуй` `, ` `Дружок` `!`
-    ;
-
-### Реализация
-
-Первый прототип парсера был написан на golang, рядом были реализованы некоторые шаблонные модули, `core` конечно, и ещё модуль хранения бинарной информации в виде zbase32-строки, отличный формат, заслуживает отдельного упоминания дизайн-документ этого формата, как тщательно люди анализировали ситуацию с форматами baseXXX.
-В дальнейшем, был реализован неполный прототип парсера OT для javascript, который стал основой для языка описания структурных атомов в языке... а впрочем это уже другая история.
-
-### Ссылки
-
-* Репозиторий https://github.com/kpmy/ot
-* Дополнительные примеры в виде недотестов https://github.com/kpmy/ot/blob/master/ot_test.go
-* Обсуждение zbase32 http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt
+Неделя самописных языков разметки на Habrahabr. Статья про AXON напомнила мне про мой проектик `o.t` - object template language. В нём я соединил интересные идеи из XML, yaml и прочих.
+
+### Что, ещё один?
+
+Велосипеды бывают разные. Мне например, было интересно попробовать создать именно язык описания данных и в какой-то степени язык разметки.
+
+<cut text="что из этого получилось" />
+
+### TL;DR
+````xml
+<note status="saved">
+  <to>Tove</to>
+  <from>Jani</from>
+  <heading>Reminder</heading>
+  <body>Don't forget me this weekend!</body>
+</note>
+````
+
+````
+note:
+  status :: saved;
+  to: "Tove";
+  from: "Jani";
+  heading: 'Reminder';
+  body: `Don't forget me this weekend!`;
+;
+````
+
+### Концепция
+Изначально, хотелось что-то типа языка программирования внутри DOM, чтобы код всегда выполнялся в контексте того или иного узла, чтобы можно было осуществлять навигацию по DOM управляющими инструкциями языка, переменные и объекты рантайм маппит в DOM-узел контекста и т.д. и т.п. В итоге, первый вариант концепции успешно вылетел из памяти.
+
+Второй вариант намного проще, и вообще не про программирование, как таковое. Он скорее про шаблоны, в том виде, в котором они представлены в технологии JSP, когда xhtml перемешивается с управляющими элементами. При этом замечено, что jsp неплохо подходит для чистой шаблонизации, без программирования. Но там же XML, великий и ужасный.
+
+А что есть кроме, JSON, YAML и TOML (.ini на стероидах). Первый описывает примитивные типы, объекты и массивы javascript, второй делает то же самое, но без курли-скобочек, а третий вообще не о том. От XML их всех отличает только одно, они описывают объект через его свойства, предполагается при этом, что при необходимости, пользователь добавит объекту поле `type` и опишет класс объекта.
+В xml объект описывается непосредственно как экземпляр класса, и потом при необходимости могут быть указаны дополнительные поля, типа идентификатора.
+
+Что же будет, если объединить простоту YAML и концепцию объектов из xml? Правильно - object template language, экспериментальный человекочитаемый язык описания данных, структур и шаблонов..
+
+### O.T.
+Схематически, весь OT можно описать одной строчкой `module~class(id): content;` то есть это модульный язык рекурсивных объектных шаблонов. Кроме этого, присутствуют дополнительные типы данных помимо строк, и отсуствуют ассоциативные массивы, которые типа объекты из json, как неконцептуальная сущность.
+
+Помимо текстовых идентификаторов, строковых, булевых, целочисленных и вещественных констант присутствуют некоторые символы, позволяющие описывать древовидные структуры объектов (object model). Так же присутствует ссылочный тип для построения других видов структур-графов.
+
+Любое пустое пространство между идентификаторами, группами идентификаторов, символами разметки и константами игнорируется и используется для разделения значимых символов, но не включается в содержимое объекта. Внутри символов-кавычек любое пустое пространство учитывается.
+
+### Объектная модель
+
+Любой шаблон представляет собой один объект, который является корневым. Любой объект, в т.ч. корневой представляется как минимум идентификатором класса объекта, и опционально идентификаторами модуля и уникальным идентификатором объекта:
+
+    module~class(id)
+
+Например, для html-страницы существует объект класса `body`, который может быть предварен идентификатором модуля, из которого взят этот класс (`html~body`). Этот объект наделяется идентификатором `index-page`, по которому можно установить связь с объектом через ссылку `@index-page`.
+
+    body
+    html~body
+    html~body(index-page)
+    @index-page
+
+Объекты могут быть вложены друг в друга, таким образом первый объект будет содержать в себе второй объект, устанавливается связь родитель-потомок.
+
+    html:
+      body
+    ;
+
+Внутреннее содержимое объекта начинается после символа `:`. Всё содержимое вплоть до соответствующего символа `;` будет считаться принадлежащим объекту-родителю. Если объект не предполагает содержимого, символы `:;` не указываются.
+
+При этом важно помнить, что обязательным для любого объекта является идентификатор класса объекта, то есть, два и более одинаковых идентификатора класса в шаблоне будут соответствовать двум и более экземплярам класса.
+
+    html:
+      body: br br br;
+    ;
+
+#### Повторное использование
+
+Для объектов, содержимое которых может быть описано в нескольких местах шаблона, возможно указать такой режим описания содержимого, при котором создание нового экземпляра класса не будет производиться, и всё содержимое будет принадлежать одному экземпляру данного класса в рамках родительского объекта. Это достигается использованием символа `::` открывающего содержимое.
+
+    xml:
+      attr ::
+        id: "my-xml";
+      ;
+      attr ::
+        xmlns: "urn:oberon:ot";
+      ;
+    ;
+
+В режиме повторного использования учитываются не только класс но и другие параметры объекта, его модуль и идентификатор.
+
+### Другое содержимое
+
+Помимо объектов-потомков, в родительский объект могут быть включены различные константы и ссылки на объекты. При этом для разделения отдельных элементов содержимого используется пустое пространство.
+
+    html:
+      head:
+        title: "Привет, Мир!";
+      ;
+      body:
+        p: 2 "+" 2 "=" 4.0;
+        concat: "Hello":':':"World":"!";
+      ;
+    ;
+
+Текстовое содержимое указывается в кавычках разных типов: `'`, `"`, и \`, при этом возможно указание отдельного символа текста в одинарных кавычках `'` и с помощью шестнадцатеричного кода (например `0DU`) с модификатором `U` на конце. Текст может содержать переносы строки и любые другие символы unicode. Есть возможность конкатенации строки и символов с помощью символа `:` расположенного между двумя и более частями строк. Результирующая строка будет представлена в объектной модели как одна строка.
+
+### Модульность
+
+Модульность в самом простом виде позволяет визуально разделять одноименные классы объектов различной природы. Например, `html~body` и `human~body`. Модульность в объектной модели предполагает так же наличие поддержки контекстом некоторых модулей, расширенная функциональность которых позволяет расширить возможности работы с шаблоном в рантайме.
+
+#### Стандартные модули и классы
+
+Стандартные модули предоставляют дополнительные возможности рантайма для объектной модели.
+
+##### core
+
+Модуль `core` является встроенным модулем, а так же базовым модулем. Для начала использования модуля `core` необходимо создать экземпляр класса `core~template` как корневой объект шаблона. Тем самым всё содержимое корневого элемента сможет обращаться к классам модуля `core`. В других случаях функциональность модуля `core` отключена.
+
+    core~template:
+      (* ваше содержимое *)
+    ;
+
+Модуль `core` предоставляет класс `import`, который позволяет описывать зависимости шаблона от сторонних шаблонов (стандартных, пользовательских, виртуальных и  т.д.).
+
+    core~template:
+      import: context;
+    ;
+
+Внутри объекта типа `core~template` действует неявное указание модуля для известных классов, таких как `import` и для импортированных классов действует такое же правило, поэтому нет необходимости (но возможность остаётся) указывать модуль `core` и другие импортированные модули каждый раз.
+
+Например:
+
+    core~template:
+      import: html;
+      html: body: p: "Привет, Мир!";;;
+    ;
+
+Классы `html`, `body` и `p` принадлежат модулю `html` и их принадлежность контролируется рантаймом, но при этом указывать их модуль явно не требуется.
+
+
+### Шаблонизация и пользовательские данные
+
+#### context
+Модуль `core` предоставляет класс `context` который является идентификатором модуля `context`.
+Модуль `context` предоставляет доступ к данным контекста существования объектной модели. Обращение к объектам модели через специальные классы модуля `context` позволит размещать в содержимом шаблона данные из рантайма.
+
+Например, класс `context~$` позволяет обратиться к данным контекста по идентификатору или иерархическому набору идентификаторов.
+
+    core~template:
+      import: context;
+      $(hello-world-text)`, `$(user-names/hello-world-user)`!`
+    ;
+
+Таким образом, в зависимости от данных, размещенных в контексте каким-либо образом и доступных по заданным идентификаторам, после обработки текста шаблона и построения объектной модели мы получим итоговый объект с заданными значениями.
+
+    core~template:
+      import: context;
+      `Здравствуй` `, ` `Дружок` `!`
+    ;
+
+### Реализация
+
+Первый прототип парсера был написан на golang, рядом были реализованы некоторые шаблонные модули, `core` конечно, и ещё модуль хранения бинарной информации в виде zbase32-строки, отличный формат, заслуживает отдельного упоминания дизайн-документ этого формата, как тщательно люди анализировали ситуацию с форматами baseXXX.
+В дальнейшем, был реализован неполный прототип парсера OT для javascript, который стал основой для языка описания структурных атомов в языке... а впрочем это уже другая история.
+
+### Ссылки
+
+* Репозиторий https://github.com/kpmy/ot
+* Дополнительные примеры в виде недотестов https://github.com/kpmy/ot/blob/master/ot_test.go
+* Обсуждение zbase32 http://philzimmermann.com/docs/human-oriented-base-32-encoding.txt

_posts/2017-07-08-Ещё-попытка.md

@@ -1,8 +1,8 @@
-
-Ещё попытка изложить диалектику в красивом формате микроблога [https://zen.yandex.ru/media/id/595a81ee8e557d6f208611ed](https://zen.yandex.ru/media/id/595a81ee8e557d6f208611ed)
-
-Занести денег автору на углеводы, белки, протеины, жиры и витаминки [https://money.yandex.ru/to/410011315537930](https://money.yandex.ru/to/410011315537930)
-
-Надо было в своё время прикрутить счётчики на страницы справочников. Теперь и не узнать, сколько таких фанатов диалектики зашло в гости.
-
-P.S. В новом формате диалектика довольно образно передаётся картинками, обратите внимание.
+
+Ещё попытка изложить диалектику в красивом формате микроблога [https://zen.yandex.ru/media/id/595a81ee8e557d6f208611ed](https://zen.yandex.ru/media/id/595a81ee8e557d6f208611ed)
+
+Занести денег автору на углеводы, белки, протеины, жиры и витаминки [https://money.yandex.ru/to/410011315537930](https://money.yandex.ru/to/410011315537930)
+
+Надо было в своё время прикрутить счётчики на страницы справочников. Теперь и не узнать, сколько таких фанатов диалектики зашло в гости.
+
+P.S. В новом формате диалектика довольно образно передаётся картинками, обратите внимание.

_posts/code-life-line.svg

@@ -1,49 +1,49 @@
-<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill-opacity="1" color-rendering="auto" color-interpolation="auto" text-rendering="auto" stroke="black" stroke-linecap="square" width="206" stroke-miterlimit="10" shape-rendering="auto" stroke-opacity="1" fill="black" stroke-dasharray="none" font-weight="normal" stroke-width="1" height="797" font-family="'Dialog'" font-style="normal" stroke-linejoin="miter" font-size="12" stroke-dashoffset="0" image-rendering="auto">
-  <!--Generated by ySVG 2.5-->
-  <defs id="genericDefs"/>
-  <g>
-    <defs id="defs1">
-      <clipPath clipPathUnits="userSpaceOnUse" id="clipPath1">
-        <path d="M0 0 L206 0 L206 797 L0 797 L0 0 Z"/>
-      </clipPath>
-      <clipPath clipPathUnits="userSpaceOnUse" id="clipPath2">
-        <path d="M417 -151 L623 -151 L623 646 L417 646 L417 -151 Z"/>
-      </clipPath>
-    </defs>
-    <g fill="white" text-rendering="geometricPrecision" shape-rendering="geometricPrecision" transform="translate(-417,151)" stroke="white">
-      <rect x="417" width="206" height="797" y="-151" clip-path="url(#clipPath2)" stroke="none"/>
-    </g>
-    <g text-rendering="geometricPrecision" stroke-miterlimit="1.45" shape-rendering="geometricPrecision" font-family="sans-serif" transform="matrix(1,0,0,1,-417,151)" stroke-linecap="butt">
-      <text x="489.2363" xml:space="preserve" y="-93.2861" clip-path="url(#clipPath2)" stroke="none">design-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="-135.5" clip-path="url(#clipPath2)"/>
-      <text x="486.2422" xml:space="preserve" y="5.4639" clip-path="url(#clipPath2)" stroke="none">compile-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="-36.75" clip-path="url(#clipPath2)"/>
-      <text x="495.5732" xml:space="preserve" y="104.2139" clip-path="url(#clipPath2)" stroke="none">load-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="62" clip-path="url(#clipPath2)"/>
-      <text x="497.9141" xml:space="preserve" y="202.9639" clip-path="url(#clipPath2)" stroke="none">link-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="160.75" clip-path="url(#clipPath2)"/>
-      <text x="499.2471" xml:space="preserve" y="301.7139" clip-path="url(#clipPath2)" stroke="none">init-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="259.5" clip-path="url(#clipPath2)"/>
-      <text x="498.2451" xml:space="preserve" y="400.4639" clip-path="url(#clipPath2)" stroke="none">run-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="358.25" clip-path="url(#clipPath2)"/>
-      <text x="492.9102" xml:space="preserve" y="499.2139" clip-path="url(#clipPath2)" stroke="none">close-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="457" clip-path="url(#clipPath2)"/>
-      <text x="491.9023" xml:space="preserve" y="597.9639" clip-path="url(#clipPath2)" stroke="none">death-time</text>
-      <rect fill="none" x="432.75" width="175" height="75" y="555.75" clip-path="url(#clipPath2)"/>
-      <path fill="none" d="M520.25 -60.5 L520.25 -44.75" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 -36.75 L525.25 -48.75 L520.25 -45.75 L515.25 -48.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
-      <path fill="none" d="M520.25 38.25 L520.25 54" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 62 L525.25 50 L520.25 53 L515.25 50 Z" clip-path="url(#clipPath2)" stroke="none"/>
-      <path fill="none" d="M520.25 137 L520.25 152.75" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 160.75 L525.25 148.75 L520.25 151.75 L515.25 148.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
-      <path fill="none" d="M520.25 235.75 L520.25 251.5" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 259.5 L525.25 247.5 L520.25 250.5 L515.25 247.5 Z" clip-path="url(#clipPath2)" stroke="none"/>
-      <path fill="none" d="M520.25 334.5 L520.25 350.25" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 358.25 L525.25 346.25 L520.25 349.25 L515.25 346.25 Z" clip-path="url(#clipPath2)" stroke="none"/>
-      <path fill="none" d="M520.25 433.25 L520.25 449" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 457 L525.25 445 L520.25 448 L515.25 445 Z" clip-path="url(#clipPath2)" stroke="none"/>
-      <path fill="none" d="M520.25 532 L520.25 547.75" clip-path="url(#clipPath2)"/>
-      <path d="M520.25 555.75 L525.25 543.75 L520.25 546.75 L515.25 543.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
-    </g>
-  </g>
-</svg>
+<?xml version="1.0" encoding="UTF-8"?><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" fill-opacity="1" color-rendering="auto" color-interpolation="auto" text-rendering="auto" stroke="black" stroke-linecap="square" width="206" stroke-miterlimit="10" shape-rendering="auto" stroke-opacity="1" fill="black" stroke-dasharray="none" font-weight="normal" stroke-width="1" height="797" font-family="'Dialog'" font-style="normal" stroke-linejoin="miter" font-size="12" stroke-dashoffset="0" image-rendering="auto">
+  <!--Generated by ySVG 2.5-->
+  <defs id="genericDefs"/>
+  <g>
+    <defs id="defs1">
+      <clipPath clipPathUnits="userSpaceOnUse" id="clipPath1">
+        <path d="M0 0 L206 0 L206 797 L0 797 L0 0 Z"/>
+      </clipPath>
+      <clipPath clipPathUnits="userSpaceOnUse" id="clipPath2">
+        <path d="M417 -151 L623 -151 L623 646 L417 646 L417 -151 Z"/>
+      </clipPath>
+    </defs>
+    <g fill="white" text-rendering="geometricPrecision" shape-rendering="geometricPrecision" transform="translate(-417,151)" stroke="white">
+      <rect x="417" width="206" height="797" y="-151" clip-path="url(#clipPath2)" stroke="none"/>
+    </g>
+    <g text-rendering="geometricPrecision" stroke-miterlimit="1.45" shape-rendering="geometricPrecision" font-family="sans-serif" transform="matrix(1,0,0,1,-417,151)" stroke-linecap="butt">
+      <text x="489.2363" xml:space="preserve" y="-93.2861" clip-path="url(#clipPath2)" stroke="none">design-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="-135.5" clip-path="url(#clipPath2)"/>
+      <text x="486.2422" xml:space="preserve" y="5.4639" clip-path="url(#clipPath2)" stroke="none">compile-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="-36.75" clip-path="url(#clipPath2)"/>
+      <text x="495.5732" xml:space="preserve" y="104.2139" clip-path="url(#clipPath2)" stroke="none">load-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="62" clip-path="url(#clipPath2)"/>
+      <text x="497.9141" xml:space="preserve" y="202.9639" clip-path="url(#clipPath2)" stroke="none">link-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="160.75" clip-path="url(#clipPath2)"/>
+      <text x="499.2471" xml:space="preserve" y="301.7139" clip-path="url(#clipPath2)" stroke="none">init-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="259.5" clip-path="url(#clipPath2)"/>
+      <text x="498.2451" xml:space="preserve" y="400.4639" clip-path="url(#clipPath2)" stroke="none">run-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="358.25" clip-path="url(#clipPath2)"/>
+      <text x="492.9102" xml:space="preserve" y="499.2139" clip-path="url(#clipPath2)" stroke="none">close-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="457" clip-path="url(#clipPath2)"/>
+      <text x="491.9023" xml:space="preserve" y="597.9639" clip-path="url(#clipPath2)" stroke="none">death-time</text>
+      <rect fill="none" x="432.75" width="175" height="75" y="555.75" clip-path="url(#clipPath2)"/>
+      <path fill="none" d="M520.25 -60.5 L520.25 -44.75" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 -36.75 L525.25 -48.75 L520.25 -45.75 L515.25 -48.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 38.25 L520.25 54" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 62 L525.25 50 L520.25 53 L515.25 50 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 137 L520.25 152.75" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 160.75 L525.25 148.75 L520.25 151.75 L515.25 148.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 235.75 L520.25 251.5" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 259.5 L525.25 247.5 L520.25 250.5 L515.25 247.5 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 334.5 L520.25 350.25" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 358.25 L525.25 346.25 L520.25 349.25 L515.25 346.25 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 433.25 L520.25 449" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 457 L525.25 445 L520.25 448 L515.25 445 Z" clip-path="url(#clipPath2)" stroke="none"/>
+      <path fill="none" d="M520.25 532 L520.25 547.75" clip-path="url(#clipPath2)"/>
+      <path d="M520.25 555.75 L525.25 543.75 L520.25 546.75 L515.25 543.75 Z" clip-path="url(#clipPath2)" stroke="none"/>
+    </g>
+  </g>
+</svg>