Илья Ермаков писал(а):
Можно говорить о том, что Оберон является ядром такого лексикона программирования. Как мы всегда говорили - экстрактом самых существенных понятий. Однако выраженных в форме языка программирования, на котором можно непосредственно писать эффективно выполняемые программы.
Если понимать принципы диалектического развития, то нет ничего удивительного, что противоречие, описанное Ершовым (много языков... следовательно, на язык нельзя опираться вообще... поэтому лексикон не должен быть языком программирования...), оказалось возможным снять, выполнить синтез ролей.
Так же, как синтез "и псевдокод, и язык программирования".
Прежде всего поставим вопрос шире - речь идёт об инженерии знаний. Эти знания инвариантно выражаются, полагаю, через целостные постановки задач. Когнитивное качество требует визуальной основы этих постановок. Далее собственно как вижу практическое движение к инженерии знаний (в т.ч. программных). В основном будет о языке - за реализацию по-прежнему принимается гипотетическая РДП-система, а технологию в общем определил в Драконографике, конкретная же сформируется от итоговых характеристик языка и реализации.
Прежде всего - у нас получится метаязык РДП-документа, несводимый только к ДРАКОНу как по алфавиту, так и по типологии схем.
Далее - нужно исходить из принципа единого источника данных модели. Это предложил и Дмитрий_ВБ как ТФАП (свою т. зр. изложил
во вложении в это сообщение), это же определено
в 9-м техтребовании от меня. А по сути, в основе этого требования и лежит моя идея реализации единого источника, только не сформулированная явно - Оберон (в перспективе - Активный) и должен быть языком ТФАП (лежащим в основе метаязыка РДП-документа)! Для этого и нужно соответствие исхчертежи-исхтекст - тогда Оберон-текст (с уточнениями, о которых ниже - т.к. не всё сводится к алгоритмам и программам) и является содержанием РДП-документа, а в РДП-редакторе просто визуализируется как граф-схемы.
На мой взгляд, для отражения семантики Оберона эти схемы образуют такую иерархию (снизу вверх):
* дракон-схемы отдельных алгоритмов, отражающие структуру маршрутов для одной рабочей точки (потока исполнения) и деклар-схемы типов величин;
* схема модулярной структуры программы - отражает её реализацию как изделия (я так понимаю, то что в UML представлено диаграммами реализации);
* межпрограммная конструктивная схема, которую можно трактовать как метамодулярную, описывающую взаимодействие ряда потоков в общей задаче.
На первом уровне снова приходим к необходимости визуального (графового) деклар-языка. Для него и иконы нужно определять, и схемы.
С визуализацией модулярности вопрос вижу такой - определять ли её через вставки (полагая, что оператор MODULE - это такой особый случай/расширение PROCEDURE, естественно визуализируемого иконой
Вставка) или ввести отдельную икону
Модуль? Склоняюсь ко второму - всё-таки реализация нагружает деталями, нехарактерными для процедур. И схема модулей - это уже не обязательно дракон-схема.
Язык межпрограммных схем - это по сути то, что обсуждалось
в этой теме - для визуализации независимых процессов. С чем-то в Обероне надо отождествить и икону
Параллельный процесс.
Нужно квалифицированное рассмотрение - возможно, в чём-то эти рассуждения следует уточнить.
Тем самым и не связываем сочинителей определённым представлением - кто-то работает с графикой, кто-то с текстом. Ведь мнение Info21 о достоинствах текстового представления справедливо - если а) не обобщать на всех людей и б) не абсолютизировать по области применения. Как люди бывают по способу восприятия аудиалы/визуалы/кинестетики - так и по способу внутреннего представления есть "писатели" и "живописцы".
Вот и получаем естественную технологию формализации - правка схем отражается (автоматически) на тексте и наоборот.
Единству служит и трактовка модели процессов как дракон-руководства, из которого выделяются программные части - именно так мы совмещаем разработку и документирование программ (а шире - косавтов) и не делаем лишней работы - пишем сразу и программу, и инструкцию на неё (если идём логически "сверху вниз" по уровню формальности - как у Вирта в книге от DEFINITION-конструкций к строго Обероновским).
Что ещё надо? Модель реализации есть, инструкции есть. Как уже говорил, можно строить по дракон-схемам их протокольные диаграммы (автоматически). Нужен язык схематизации всего содержания - тоже предложил, инфор-синт-язык, точнее сказать, лист-диалект его - пока
в этом сообщении - а реализуется это расширением Оберона для текстового описания силуэта (ну и иконы гибкого и жёсткого полей вводятся в РДП-метаалфавит).
Схемы на других языках привязаны к синт-иконам - а их связи идут "поверх". Практически текстовый синтаксис включающей иконы (жёсткого поля и др.) содержит поле текстоэлемента - в нём-то и содержится текстом всё, что входит в эту икону с указанием базовых точек привязки для каждого физически отдельного вхождения (граф-схемы, изображения, таблицы и т.п.). Вхождению предпослан префикс языка его представления (ДО-2, АТ, СД и пр.) для выбора РДП-редактором обрабатывающего языкового модуля.
Но не забудем, что для работы "сверху вниз" у нас и язык изначально непрограммной строгости (в немаршрутной части). И надо, чтобы импер-схемы с неформальным языком в ТФАП описывались как квази-Оберон-текст (с подстановкой неформального текста в немаршрутную часть Оберон-оператора). На компиляцию эти тексты, ясное дело, не передаются - оформляются отдельно - а результаты трансляции дракон-программ идут файлом в формате компилятора (ББ или другого). Вот тогда будет целостный синтез ролей.
Нужно ввести и подъязык разметки неформального текста икон (как в инфордок-процессорах) и шаблонов формального текста. Ещё добавятся иконы Область, туннели, другие вершины, о которых писал в Драконографике.
И для отражения межпрограммных схем возможностей Оберона (в т.ч. Активного) может оказаться недостаточно - придётся дополнить стандарт языка. Т.о. действительно может получиться не чистый Оберон, а Оберон-ТФАП (точнее говорить о текстовом формате разработки и документирования и соответственно ТФРД-метаязыке, частью которого будет язык Оберон).
Оберон-часть ТФРД будет понятна тому, кто знает базовый прогязык - не надо специально изучать какой-то ещё ТФАП-язык. Визуализация же служит и его изучению непрограммистами по складу ума - вместо изучения текстовой спецификации языка, где написано, скажем, "оператор MODULE - это тр-тр-тр...", человек видит икону с текстом и схему употребления, откомментированные посредством КогниСтиль - и понимает, что к чему, особенно если он ещё и "живописец". Тут, правда, надо правильно меня понимать - текстовая спецификация (конкретно для Оберона, скажем - Вирта в пер. Свердлова) не исключается никоим образом - просто она будет для тех, кому такое представление подходит больше.
Вот такие соображения пока. Прошу критиковать.