Так.. Для осуждения..

Предисловие. 

Вопрос «Зачем все это?» я неоднократно слышал и задавал сам себе. Не могу похвастаться, что легко отвечу не него и сейчас, потому что слова «так будет лучше» не являются ответом. Хотя лично я к этим словам отношусь очень серьезно. И не потому, что лучше и легче это, в конечном счете, дешевле. Освободить голову разработчика от неестественных «заморочек» и условностей, которыми буквально нашпиговано программирование и вообще работа с компьютером, это значит сконцентрировать усилия на решение поставленной задачи.

Любопытно, кому первому пришла идея создать различные форматы и придумать расширение файлов. Но, это была замечательная идея для своего времени. Таких идей было много. Сейчас вряд ли кого удивишь процедурой, и трудно передать ощущение программиста тех лет пишущего несколько лет, на ассемблере впервые узнавшего о таких методах решения как  подпрограммы, списки, реентерабельные программы (предвестники классов) и много-много было придумано интересного. Что-то осталось и стало классикой, что-то ушло. Может быть, и мои мысли окажутся интересными, а может быть, и нет.

Но, вернемся к форматам. Основная причина их создания в том, что каждый формат предполагал какую-то систему кодирования. Как-то надо было отличить текстовый файл от программы или данных, которые каждый кодировал, как хотел, а кое-что и стало стандартом. Для каждой системы кодировок требовался свой редактор, который работал только с этим форматом. Или как-то реализовывал этот формат. Например, воспроизводил файл или запускал как программу. Так вот основной моей задачей поставленной при создании системы Lada изобрести универсальный формат и универсальный редактор.

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

Единственно такой подход способен реализовать глобализацию данных, и решить многие глубинные проблемы и баз данных и работы в сети. С глобализацией понятно. Каждый файл держит описание своих собственных классов в себе и потому может быть открыт и обработан всегда и везде независимо от того где, кем, когда и чем он был создан. Останется только вопрос применения в каждой предметной области, так для этого и придуман механизм сценариев, о котором чуть позже. Хотя предлагаемые режимы  редактирования покрывают классические нужды пользователя. Это, конечно, текстовый редактор-транслятор, редактор изображений, редактор таблиц, редактор классов и объектов (аналог UML), редактор событий (Проверка полноты событий, отсутствие зацикленности и редактор-отладчик связей и условий для UML) и редактор TLL (можно назвать теговым дизассемблером или ассемблером).

Проблема баз данных совсем не проблема, если обратить внимание что таблица это значение свойств нескольких объектов одного класса, количество строк которой совпадает с количеством объектов, а количество столбцов с количеством свойств. Таким образом, строка это свойства объекта, а столбец это значение одного свойства нескольких объектов. Просмотр и редактирование таблицы объектов решается просто просмотром свойств нескольких объектов одного класса. Единственная разница, что обычно мы просматриваем свойство в таблице, где один столбец это имена свойств, а второй их значение. Осталось повернуть эту таблицу на 90 градусов, и получим знаменитый Exel. Любопытно, что приведение базы данных к нормальной форме в таком контексте формулируется по отношению к классам, что не лишний раз заставляет задуматься при их создании, потому как доменами в такой формулировке являются свойства класса. И условия нормализации (независимость и т.п.) должны применяться к свойствам класса.

Еще одним положительным моментом при создании баз данных можно считать то, что все данные необходимые для баз данных содержаться в самом документе и нет необходимости создавать сопровождающие документ записки дублирующие данные, находящиеся в документе и отражающие содержание документа и этапы его прохождения. Этот же момент весьма полезен для поиска и анализа данных, потому как все что может представлять интерес для поиска, содержится внутри документа как объект, и нет необходимости в тегах для выделения ключевых слов и т.п.

В процессе работы пришлось пересмотреть подход ко многим вроде бы привычным вещам. За что приношу извинения. И жду критики. А теперь о форматах.

 
 1.     Проблема формата. 

В общем случае если считать формат как систему кодировок, то кодировка обычно заключается в решении двух задач. Первая это определение отношений код-объект и код – свойства. И, вторая проблема кодирования это определение последовательности всех этих кодов. Понятно, что, не зная порядок следования кодов, мы вряд ли раскодируем.

Конечно, можно рядом с каждым кодом передавать его тип (т.е. что именно он кодирует) однако это нельзя назвать хорошим решением. Если мы анализируем объект, то достаточно знать какого класса это объект, а дальше принять последовательность кодов (свойств) в том порядке, как они определены в классе. Тогда с типами кодов тоже вопросов не возникнет потому, как описание типов в описании класса (предполагается, что описание класса уже загружено) следует в том же порядке.Собственно, для линейных данных (такие в которых расположение объектов не предполагает вложенности), таких как текст такого кодирования вполне достаточно. Но, дело в том, что даже линейные данные могут порождать не линейный смысл (что мы назовем семантикой). Например, прямая речь или примечания. Или в тексте программы мы программируем операторы, вложенные в цикл или элементы управления, содержащиеся внутри других элементов. Или вообще данные могут представлять собой графы или сети Петри.На первый взгляд, а какая разница какой смысл имеется в виду в линейных данных? Наша задача раскодировать решается и так. Но, нам мало раскодировать и отображать. Нам необходимо редактировать. А механизм редактирования должен нам и со смыслом помогать. Причем вопрос смысла должен решаться универсальным образом и появляться в подсказках и комментариях. Откуда появляется смысл? А он появляется и разный. Конечно, сначала это сам объект со своими свойствами. Если это буква, то можно считать что все понятно по изображению. Однако если визуально это выглядит как прямоугольник то, что это микросхема, помещение или элемент блок-схемы? И, кроме того может смысловую нагрузку нести некие множества этих объектов. Тогда появляется еще уровни смысла.Во-первых, при лексическом разборе. Некоторые последовательности объектов в результате лексического анализа превращаются в лексему (и возможно неоднозначно). Эта лексема имеет свои свойства, возможно, не безразличные для редактирования.Во-вторых, при синтаксическом разборе. Ведь последовательность лексем образует некие синтаксические конструкции, в результате которых может быть решена неоднозначность лексем, но может и остаться, добавляя неоднозначность и самих синтаксических конструкций. Устранить эту неоднозначность можно, только анализируя свойства и класс выделенной синтаксической конструкции.В-третьих, вопрос семантики мы решаем созданием объектов на основе синтаксических конструкций. Так вот редактируя документ, нам отнюдь не безразличен для редактирования этот созданный объект и его свойства. Фактически это то, что именно представляет собой эта синтаксическая конструкция (фраза, оператор и т.д.). В качестве примера можно привести следующую конструкцию в языке Lada. New New: New= New New Это, конечно, искусственная, но вполне допустимая конструкция могущая превратиться в результате трансляции в следующую:[М1]  New New: New= New New Где смысл лексем выделен цветом

Предлагаемые цвета.

New –  Ключевое слово определяющее класс объекта.

New –  Тип

New –  Класс

New –  Текст

New –  Идентификатор наследует цвет класса или типа. В данном случае типа.

New–  Зеленым цветом выделяется комментарий.

 А смысл семантический это объект класса New со свойствами Name=New, Type=New, Value=New. Комментарий это отдельный объект.А теперь допустим, что мы научились разбираться со смыслом, но тогда у нас возникает новая проблема. Вернее это старая проблема, проблема производительности и эффективности. В тексте, или вообще при редактировании мы размещаем объекты так, как нам удобнее для редактирования, а вот размещение в неком формате подразумевает еще эффективность алгоритма, который будет работать с этим форматом. По этой причине размещение данных в форматах как правило отличается от того как они размещены визуально при редактировании. Например, двоичные форматы программ содержат отдельно список внешних переменных для связывания. Отдельно размещены процедуры. Даже если в тексте мы размещаем процедуры внутри друг друга, тем самым ограничивая их область доступа, в двоичном формате они вполне могут размещаться последовательно, решив вопрос ограничения доступа на этапе трансляции. Тело программы (имеются в виду инструкции для выполнения) также размещается в отдельной области, предполагая последовательное выполнение инструкций. Кроме того, формируются инструкции и интегрированные данные необходимые им для выделения памяти и прочих необходимых специфических действий для подготовки работы с этим форматом на основе анализа всего документа. Как правило, эта суммирующая информация собирается в начале документа и называется заголовок (для программ там же находится вычисленная точка запуска). Так как предметных областей так много что предусмотреть их все не представляется возможным, невозможно создать универсальный заголовок в смысле эффективности. Что не мешает, впрочем, к этому стремиться. И одним из способов решения проблемы универсального заголовка это создание универсальной среды выполнения. Заголовок должен содержать суммирующую информацию типа размеры, количество и т.д., и не объекты, а ссылки на необходимые объекты так, как сами объекты нельзя перемещать. Если какой-то из элементов универсального заголовка требует сортировок или еще каких-то обработок, то сортировать необходимо ссылки, а объекты должны сохранять своё расположение. Ссылки могут быть двух видов, ссылки на объекты внутри документа (дата создания или этапы согласования), и ссылки на объекты которые будут созданы в процессе реализации документа как объекта (данные создаваемые оператором Dim или New), если документ представляет собой класс или содержит инструкции, создающие динамические данные. В смысле реализации адресации машиной это должны быть разные методы адресации.Но самая большая проблема это не наличие заголовка, а тот факт что форматы изменяют расположение объектов из того как мы их наблюдаем при редактировании, в то что превращается, допустим, в результате трансляции. Проблема, состоит собственно, не в том, что порядок другой, а в том, что он разный для разных приложений (и, следовательно, форматов). Отсюда следует, что универсальный редактор должен сохранять расположение объектов не только в смысле сохранения расположения самих данных для хранения, но и сохранять это расположение в результирующем файле после трансляции. Решение этой задачи в том, что все объекты, созданные при редактировании должны поступать на вход виртуальной машины и в каком-то смысле выполняться. Что, собственно, и делает теговая машина в системе Lada.Инструкции в такой теговой машине не просто большие, они еще и не фиксированной длины, потому требуют указания собственного размера (вообще это требуется для двоичного формата объекта, а инструкции тоже объекты). Указание размера можно считать относительной адресацией, тем более что по причине того, что в теле документа-программы инструкции могут находиться не только подряд (мы не можем изменять порядок объектов при редактировании), указание адреса следующей выполняемой инструкции становится необходимым. В такой формулировке теговая машина Lada представляет собой машину Тьюринга с дополнительной адресной лентой (в которой находится адрес следующей выполняемой инструкции). Принципиально это ничего не меняет, так как обычная машина Тьюринга и машина Тьюринга с дополнительной адресной лентой эквивалентны и моделируются одна на другой. Хотя и появляется возможность создавать программы программой с динамическим размещением инструкций, равно как и любых объектов (что мы и делаем операторами Dim или New), ничего не могу сказать о практической полезности этой возможности. Еще одним аргументом в пользу такой архитектуры компьютера является ситуация с преобразованием выражений из инфиксной в постфиксную или префиксную форму, и удаление скобок. Порядок объектов участвующих в выражении и участвующих в вычислениях изменяется. Так «a+b» превращается в «+ab». Понятно, что без преобразования не обойтись, но преобразовывать необходимо не порядок объектов, а адреса, и запускать на выполнение последовательность адресов, а не команд-параметров-объектов, которые должны выполняться не только не в той последовательности, как написаны, а еще и не все. Так, например, скобки в вычислениях не принимают участие. Хотя порядок, конечно, изменяют. 1.     Ввод. Вывод. Отличие универсального формата в том, что имея его, у нас пропадает необходимость управлять загрузкой и как следствие нет необходимости в командах Input, Output. Слово загрузка можно вообще убрать из лексикона этим занимается система. Остается только активация объекта (для объектов класса Document нечто вроде открытия файла), после чего становятся доступны все свойства объекта (кроме свойства Child), которые доступны для анализа и редактирования, но вложенные объекты недоступны. Заметим здесь, что в свойстве Child и находятся вложенные объекты. Вложенные объекты становятся доступны при активации свойства Child.Активация объектов и свойств возможна двумя методами. При редактировании и программно. При редактировании активация объекта происходит при указании на него мышкой (один клик). Двумя кликами открываются и вложенные объекты (документ тоже объект). Вложенные объекты можно открыть кликом на свойство Child. Активация программно происходит командами Activate Объект или Activate Имя_объекта или непосредственным обращением к объекту в программе. Активировать можно несколько документов. Но в самом документе может быть только один активный объект в данный момент.Манипуляции ввода-вывода с данными возможны только на уровне объектов. Это позволяет загрузить целостный объект и иметь гарантию полного описания объекта в случае необходимости обрабатывать событие Activate или другие события, описанные в классе, в объекте и имеющие процедуры обработки.Для сохранения объекта программно используется команда Save. При редактировании активный документ может быть сохранен как командой Save, так и при закрытии окна с документом будет предложено сохранить изменения, если они имели место. Заметим, что закрытие документа не имеет смысла принятого обычно закрытия файла, потому как нет понятия открытия файла.Команда Save работает только для объектов в среде объекта класса Document и для объектов класса Document. Этим гарантируется наличие среды для хранения объекта (среда необходима для однозначного определения формата хранения). По этой причине для создания и сохранения нового документа необходимо не только создать необходимые для хранения объекты, но и создать объект класса Document, в него вложить вновь созданные объекты и применить команду Save к документу.