OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 15:56

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 26, 27, 28, 29, 30, 31, 32 ... 34  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 03 Декабрь, 2012 08:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Тут по связям в лист-сети надо уточнить кое-что существенное для реализации. Во-первых, связи между терминами (из "подвала" каждой статьи) должны учитываться при формировании указателя. Пока документ юзается в среде - просто тем, что и на статьи, не вставленные составителем в документ, "подвальные" ссылки остаются доступными, и можно по ним переходить. При выгрузке же во внешнее представление такие статьи нужно подставлять - либо автоматом, либо с подтверждением от юзера. Не подтвержает он включение термина - значит, и все ссылки на него автоматом убираются из вьюшки (висячих же не д.б. ;)).
Во-вторых, на структуру ссылок могут влиять права доступа. Т.к. некоторые термины-цели ссылок могут иметь ограничение употребления. По-простому - возьмём термин "секретное делопроизводство". Сам-то по себе он несекретен... ;) но м.б. связан с определениями каких-то "грифованных" понятий, документов, предметов. Ну или вот - иногда при размещении источники совершенно разрешённые нужно сокращать (иной раз только до упоминания :)), потому что мало ли чего там автору написать захотелось (как тут у нас бывает с постами... и удалёнными, и не только ;)).
Так что и записи БД, и документы нужно категорировать. И "вертикально" - хотя бы по уровням "6/12/16/18+"... ну, все всё поняли... (а то конкурент приведёт дядю, который скажет: "и это вы хотите предлагать в техникумах/школах/кружках?!.." ;)) - ну а для коммерции и как обычно, по "уровням таинственности" (а именной указатель - это, между прочим, в применениях редактора/софта, в нём разрабатываемого, м.б. и удобное средство для работы с "персональными данными"... тут уже другие дяди, умеющие показывать Магадан ;)). И "горизонтально" - по предметкам. А редактор доолжен исключать ссылки на цели, нарушающие ограничения. Так, чтобы юзер их и не видел... :)

И это на самом деле штуки-то не "только для указателей", как нетрудно видеть...
Но. На самом деле многие из этих "угроз" могут и не осуществиться в обозримом для коммерческого редактора будущем... ;) Так что надо думать, что из сказанного принимать во внимание... а чем в реализации пренебречь... возможно, до поры... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: И о пользе :)
СообщениеДобавлено: Пятница, 07 Декабрь, 2012 04:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ну и зачем всё это (прежде всего описанное здесь: viewtopic.php?p=76210#p76210) нужно?.. Дело в том, что если исходить из коммерческого распространения - то такая среда как нечто новое на рынке оформления документов должна прежде всего что-то делать лучше, чем уже имеющиеся. :)
А работа с корпусом указателей - место у существующих редакторов как раз весьма слабое... а дело весьма нужное... Это так и с научной точки зрения - если не забывать, что "структуризация предшествует формализации" (и программной тоже) - а "знания отчуждаются как данные" прежде всего в форме тезауруса (который и представлен указателями). И с практической - вот скажем, людям надо использовать иной раз кучу источников... и представьте, что будет, если добавить хотя бы один внутрь текущего порядка в "просто редакторе"... м-да... А тут - раз, и готово... и номера по списку везде переиндексировались... и забивать описание, если уже есть в БД, не надо (и даже просто копипастить в документ - что тоже труд)...

Так что такая среда м.б. востребована на рынке более широком, чем разработка ПО. И что немаловажно - быстрее (вспомним обсуждение на Спейсе... а ведь такая реакция м.б. типична и для "мейнстрёмных" ИТ-шников) Да чё там далеко за примерами ходить - может статься, мне бы - как предметнику/аналитику безо всякого программирования - редактор с такими возможностями стал бы интересен... при разумной цене... :)
В связи с этим - о том, как цену можно сделать разумной. Думаю, документные возможности (как и поддержка описания техпроцессов) в небесплатном продукте прежде всего - потому д.б. некая базовая линейка конфигураций, где "всё для постановщика задач" и почти ничего для программиста - отсюда и стоимость лицензий низкая. Т.е. информатически формальные языки поддерживаются только как "родные" (спецификаций) - м.б. и без структурирования в понятиях "семантического ядра" - только с подразделением операторов, а пишут пусть в свободной форме. И нетекстовые вьюшки ограничены по формам/синтаксисам, и возможности экспорта/импорта. Пример такого документа теперь можно видеть здесь: viewtopic.php?p=76208#p76208. Ну а дополнительно идёт линейка "профессиональная" - там уже и "ядро", и синтаксисы конкретных ЯВУ/асмов... ну и либы всякие... и типовые техпроцессы... и конфигурации документов... и широкий спектр сторонних продуктов, содержание которых можно включить в документ и выгрузить обратно... :)

А реализация работы с указателями - по сути, то самое "звено, ухватившись за которое, можно вытянуть всю цепь" приближения структурного редактора как рыночного продукта к тому уровню, который Дмитрий некогда определил как "сказку"... однако без которого, может оказаться, коммерциализация сделается былью гораздо позже всех расчётных сроков окупаемости... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И о пользе :)
СообщениеДобавлено: Пятница, 07 Декабрь, 2012 11:20 

Зарегистрирован: Суббота, 17 Сентябрь, 2011 16:39
Сообщения: 72
Владислав Жаринов писал(а):
А реализация работы с указателями - по сути, то самое "звено, ухватившись за которое, можно вытянуть всю цепь" приближения структурного редактора как рыночного продукта к тому уровню, который Дмитрий некогда определил как "сказку"... однако без которого, может оказаться, коммерциализация сделается былью гораздо позже всех расчётных сроков окупаемости... :)


Тут проблема не столько в связях(указателях) между понятиями и самих понятиях, сколько в механизме добавления новых понятий.
Редактор может быть и получится классный, но если набор понятий и связей между ними будет жестко задан и пользователь не сможет его отредактировать, то такое вряд ли кому-то приглянется.
Представьте себе: менеджер проекта хочет оперативно следить за разработкой. Для этого он хочет, чтобы в каждом модуле появилось понятие, показывающее трудозатраты на этот модуль, и понятие, показывающее процент выполнения. Разработчики заполняют эти понятия по ходу дела (как обычно описывают заголовки в начале файла), а внутренний механизм агрегирует информацию со всех модулей и выводит менеджеру в виде диаграммы.

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

Подчеркнутое у нас с Валерием Викторовичем скоро будет, а как решать вопрос с выделенным жирным, я пока ума не приложу.
Впрочем нам для обучения этого не надо.

Кстати, Владислав, что Вы думаете о MPS? Тут механизм описания действий нового понятия сводится к выражению через действия уже существующих понятий.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И о пользе :)
СообщениеДобавлено: Пятница, 07 Декабрь, 2012 12:15 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Дмитрий Грачёв писал(а):
Значит у любого пользователя системы должна быть возможность добавить семантическое понятие в общий набор, описать его форму (синтаксис и лексику), добавить его связи с другими понятиями, и, наконец, описать что же это понятие должно делать.

Подчеркнутое у нас с Валерием Викторовичем скоро будет, а как решать вопрос с выделенным жирным, я пока ума не приложу.
Впрочем нам для обучения этого не надо.

Кстати, Владислав, что Вы думаете о MPS? Тут механизм описания действий нового понятия сводится к выражению через действия уже существующих понятий.

1. Механизм описания действий нового понятия через существующие - это во всех языках программирования. Процедура - это как раз то самое описание нового понятия через существующие в языке.
2. Описать, что же это понятие должно делать - это сначала ввести новый DSL (привет Мартину Фаулеру) для данной предметной области. А потом на этом DSL уже написать, что должно делать новое понятие - в рамках ЭТОЙ ПРЕДМЕТНОЙ ОБЛАСТИ. То есть, сначала нужен механизм определения DSL


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 07 Декабрь, 2012 13:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Это да. Потому не замахиваюсь дальше описанного здесь: http://forum.easyelectronics.ru/viewtop ... 41#p204947 - т.е. пользователь пусть сам решает, что элемент компоновки значит и что он должен делать, на каждом "языке системы", для него допустимом. Ну, насчёт определения допустимости Вам мысли (не свои) тоже представил. :)

Конечно, проблема не в связях (вон на примере словаря-схемы видно, как пользователь может их устанавливать/отслеживать). Собсно, коль скоро это "ЕСКД-сеть с видом маршрутной goto-схемы" - то и "приматические" операции исчисления таких схем для добавления/удаления/реструктуризации подходят... :)

В общем, редактор не должен угадывать желания пользователя. :) Хотя на Ру-Борде обсуждают и аналитические операции: http://forum.ru-board.com/topic.cgi?for ... art=740#11. Но это реализатор должен решить, насколько реализуемо... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: И о пользе :)
СообщениеДобавлено: Пятница, 07 Декабрь, 2012 14:49 

Зарегистрирован: Суббота, 17 Сентябрь, 2011 16:39
Сообщения: 72
Валерий Лаптев писал(а):
Дмитрий Грачёв писал(а):
Значит у любого пользователя системы должна быть возможность добавить семантическое понятие в общий набор, описать его форму (синтаксис и лексику), добавить его связи с другими понятиями, и, наконец, описать что же это понятие должно делать.

Подчеркнутое у нас с Валерием Викторовичем скоро будет, а как решать вопрос с выделенным жирным, я пока ума не приложу.
Впрочем нам для обучения этого не надо.

Кстати, Владислав, что Вы думаете о MPS? Тут механизм описания действий нового понятия сводится к выражению через действия уже существующих понятий.
2. Описать, что же это понятие должно делать - это сначала ввести новый DSL (привет Мартину Фаулеру) для данной предметной области. А потом на этом DSL уже написать, что должно делать новое понятие - в рамках ЭТОЙ ПРЕДМЕТНОЙ ОБЛАСТИ. То есть, сначала нужен механизм определения DSL


А сами DSL тогда должны быть написаны на основе DSL-языка высокого уровня общего назначения, у которого под капотом компилятор?
Ну, мы тогда точь-в-точь копируем MPS.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 07 Декабрь, 2012 20:03 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Ну, если делать супер-пупер-универсальный инструмент, то - да.
Но мы ж для всего - не хотим. Не нужно для всего.
У нас в первую очередь - обучение дисциплинам, связанным с разработкой ПО.
Вот на эту тему и надо делать нижний DSL.
Поэтому можно посмотреть в сторону Форта - там на 3 (трех!) сущностях строится все здание Форта.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 08 Декабрь, 2012 07:04 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот об чём и речь... что как я понимаю системный подход, можно для всего, если не связываться с ДСЛ и Фаулерами... :) Т.е. ничего лишнего из языковых средств в редакторе не реализуем. Основа - операторские роли, техпроцессы и единицы компоновки систем (в т.ч. и самой среды как предмета разработки в ней же :)).
Операторы имеют права на исполнение техпроцессов по обращению с предметами. Это как всё связывается в основе.
Детальнее так. Базовые техпроцессы определены разработчиком (команды редактора как элементарные техоперации и ваши "операции рефакторинга", из них построенные). Далее уже любой оператор может определять техоперации и набирать из них техпроцессы. В пределах своих прав. Система в среде (как предмет труда) представлена архитектурной моделью типа "иерархии абстракций". Она и строится из единиц. Права их компоновки "для среды" определяются никакими не ДСЛами её, а просто "охраной типа" (у меня в механизме областей это SUBSTIF - или Вх:). Раздельно по типам единиц в целом и типам их стыковочных точек (фактически - интерфейсов). Все типы назначает "предметник" (ну и/или аналитик). Далее можно задавать параметризуемые поля в содержании единиц - и одновременно правила параметризации (у меня - SUBSTEXT).
Т.е. нужен "язык SUBSTов" - фактически "условной сборки". Сначала по "охране типов единиц/точек", а для случая выполнения охран - по правилам параметризации содержания, если таковые определены.

И что тогда получается? Предметный смысл любых систем изначально в редакторе представляется только системой правил подстаноовки. И никак не какими-то специальными "языками предметок". Всё это операторы могут определить (для человека) как описания областей на "родных" языках... Имея в виду, что содержание единицы ведь реализует её назначение как элемента архитектуры...
Из осмысления (человеком) таких описаний в связи с опытом применения единиц могут, разумеется, определяться и новые/уточнённые правила... а также типы единиц и их стыков (представленных содержанием областей и их "контактов").
Вот для описания содержания единиц и стыков и нужны языки... только вряд ли специализированные "по Фаулеру"... скорее по способу выражения смысла различных предметок... Тут бы скорее Рыжикова с Овчинниковым смотреть... да и на "КУБ" со "Сферой" взглянуть... но это и мне надо ещё думать... Пока идея интуитивная такова. У Вас определилось "ядро" для императива, а хорошо бы взглянуть ещё на "релятив" и "продукционность"... И посмотреть, в частности, а как с этим связан системный подход к наследованию?..

Может, будет так - есть архитектурные компоновки для систем, производящих огнетушители (как здесь) или услуги (как здесь), а есть - для систем, производящих документы (в частности, "со встроенными программами", как структурный редактор)?.. И в связи с этим вспомнить, что в ЕСКД есть виды схем по аспекту раскрытия (структурные, функциональные, принципиальные) и по уровню декомпозиции (элементные/сборочные на комплекс, машину, агрегат, блок, деталь), а есть типы - по наполнению связей (механика, гидравлика, электрика, данные)... но не "по отраслям" (от чего зависят только конкретные УГО - т.е. по сути опять "типы областей"... одноэлементных)?.. Т.е. всё от назначения - и не исключая для разных назначений повторного использования единиц компоновки с уместными стыками и назначением?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 08 Декабрь, 2012 07:17 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Тогда получается, что предметка - подготовка документов. И в основе - DSL... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 08 Декабрь, 2012 08:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Скорее предметка (базовая для редактора) - разработка техпроцессов. И в основе - язык их описания... как работы над декомпозицией архитектуры, заданной (в редакторе) единообразно. ДСЛ будет выражен только в типах элементов и связей (стыков), доступных в данной предметке. Но не в способе организации языка...

В то же время формы представления одного описания в ряде случаев д.б. реализованы различные (не обязательно сразу). В подтверждение этому можно привести некоторые примеры из данного пространства общения... :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 08 Декабрь, 2012 09:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Итак, что обнаружилось в старых (и нечитанных - с позиции Усова, очевидно, правильно :)) постах по этому топику - может, будет интересно.

Насчёт нелинейных маршрутов - для циклов обозначено, что нужно бы представлять явно: viewtopic.php?p=14738#p14738. :) Итак, идею представить цикл как "виток спирали", кою заложил в свой вариант языка структурных скобок (показано на этом примере), Донской уже предлагал.
Читаю тему дальше - и вижу, что там реализована и мысль Прохоренко отсюда: viewtopic.php?p=14784#p14784. Ну вот, очередной велосипед изобретён... ;)
И вот давайте попробуем сделать так же в графовой записи... хорошо ли получится?.. :)

Теперь от циклов перейдём к ветвлениям (множественным):
Alexey_Donskoy в viewtopic.php?p=14610#p14610 писал(а):
... Могу только сказать, чего не хватает:
- описания структур данных;
- описания неалгоритмичексих знаний;
- по мелочам... например, очень бы хотелось видеть автоматизацию анализа всех возможных ситуаций выбора. Это косвенно (через эргономику) влияет на сложность модели. Вот, например, табличное представление алгоритма (те же таблицы решений, таблицы состояний и т.п.) реализуют если не анализ, то хотя бы визуальное представление всех возможностей выбора, которые описать наскоком через if then else (а хоть бы и через case!) не получается и не рекомендуется во избежание ошибок. Некоторые компиляторы (особенно функциональных языков), напротив, обеспечивают автоматическую проверку полноты определения вариантов, но текстовое представление для человека здесь не оптимально (текстовый язык из вполне понятной экономии не содержит требования обязательного указания всего массива вариантов, т.е. пропущенных мест просто не видно, в отличие от таблицы). В Драконе имеем то же, что и в тексте - пропущенных вариантов не видно.
...
- опять есть вопрос к графовой записи, как видим.
Замечу, что решения есть. Как первоначальное - всегда подставлять в кейс вариант "любое другое" (сочетание значений величин из списка фигурирующих во всех условиях ветвления). Указано ещё в Драконографике для схемно-техноязыковой формы записи здесь. Редактор может делать автоматом (с пустым телом варианта), подставляя и список величин/значений. Дабы сочинитель не забывал, чего наваял... :) Как детализирующее в графовой форме - "кейс по кейсам" с полным перебором вариантов, о чём писал здесь: viewtopic.php?p=64668#p64668. Тоже можно реализовать составление в редакторе - автоматом и/или по команде (тоже недоопределённые варианты с пустыми телами).
Разумеется, оба решения не зависят от формы записи. Но надо смотреть - а как лучше с таким "полно-переборным" описанием работать - в тексте? таблице? на графе?..

Alexey_Donskoy в viewtopic.php?p=14555#p14555 писал(а):
...

Имеем проблему: текст программы не похож на алгоритм. Между тем, алгоритм с блок-схемы типа ДРАКОН один в один списывается в ассемблер. Ассемблер более точно записывает алгоритм.
С этим не могу согласиться никак. Возьмем тот же пример - конструкцию if then else. По своей алгоритмической сути она имеет две равновесные ветки. Заметим, что переходов здесь никаких нет, есть только выбор пути. Сравним:
- что бы кто не говорил по этому поводу, табличное представление наиболее точно и беспристрастно отображает суть данной конструкции;
- графическое представление (ромбик со стрелками) также отображает точно, но имеет особенности (облегченное восприятие человеком и, вместе с тем, неоднозначность синтаксиса - да/нет и влево/вправо);
- Дракон чуть пытается улучшить графическое представление путём невнятной и противоречивой рекомендации располагать да/нет "в порядке предпочтения";
- текстовые ЯВУ типа Паскаля, оставаясь точными по сути, вносят искажение по форме, чем затрудняют восприятие человеком (как любая плоская картографическая проекция искажает глобус). Ну, и синтаксис усложняется соответственно;
- ассемблер делает две гадкие вещи, обе в порядке внесения дополнительной, лишней, не нужной для алгоритмической сути, сложности: а)добавляет понятие перехода (условного и безусловного), б)вносит жёсткую, аппаратно обусловленную асимметрию (во всех известных мне процессорах инструкция условного перехода сами знаете как выглядит и нсколько она похожа на алгоритмический ромбик со стрелочками).
...
- да, проблему имеем... И решение было - уж года два с лишним тому. В частности, как результат обдумывания, как в графах лучше записать вывод "теоремы о переписываемости"... :) И тогда же было очевидно, что переход - следствие ассемблера внешне, а глубинно - модели памяти... и вот здесь та самая "мерность" играет... если видеть её отдельно и от формы записи, и от структурности... :)
И тут тоже можно сущность перехода использовать... если подумать... ну, об этом Вы теперь в курсе...

Да и сама мысль Прохоренко от формы записи не зависит. А за ней стоит то, что переходы безусловные, на метку (как средства реализации нелинейных конструкций в линейной записи) бывают таких типов:
    * структурные - с общей точки ветвления на общую точку слияния маршрутов в направлении по следованию для выбора и против для цикла;
    * полуструктурные - сохраняют структурное направление, но их начало (для циклов) или конец (для досрочных выходов из процедуры - тоже начинаемых по сути через ветвления, явные или скрытые) не совпадают с общей точкой;
    * неструктурные - произвольно направлены, не связаны с ветвлением.
Первые представлены ключевыми словами структурных конструкций. Отсюда и необходимость читать даже структурный линейный текст алгоритма "скачками". Заметим, что exit в loop также можно считать структурным БП.
Вторые - break/continue, return.
Ну, третьи - goto. Сюда же относятся и допвходы в процедуру, когда они не понимаются как вызовы (т.е. без переключения контекста и пролога). Ну и такие же выходы.
А с учётом наличия восстановления контекста (и эпилога) при выходе из процедуры мысль Сергея о разнице с выходом из нелинейных конструкций, возможно, следует уточнить...

Ну и в целом те сжатые рекомендации, которые были здесь: viewtopic.php?p=14729#p14729 - видимо, по-прежнему актуальны.

В итоге, наверное, эти тезисы:
Alexey_Donskoy в viewtopic.php?p=14555#p14555 писал(а):
...Вот правильные тезисы:
- любая модель должна быть формализована, и формальный язык всегда вносит определенные ограничения (соответственно, добавляет сложность);
- во главу угла я ставлю эргономические вопросы (частным случаем которых являются вопросы экономические). С этой точки зрения всегда возможен оптимальный выбор инструмента;
- в подавляющем большинстве случаев ассемблер менее эргономичен, чем все другие инструменты (хотя бывает и по-другому, но редко и в специфических задачах);
- к сожалению, эргономичность всех нынешних инструментов оставляет желать лучшего. И я желаю улучшить их на порядок! (с этой точки зрения разница между ЯВУ и ассемблером далеко не так велика).
...
можно применять при определении, какие языки нужны в редакторе... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Четверг, 13 Декабрь, 2012 12:36 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
И ещё по поводу асимметрии. Да, в расчёте на линейно-адресную модель "информационного пространства" ((С) Б.А. Бабаян) исполнителя алгопроцесса она "привнесена нашей машиной". Но. В техноязыке-то предложено её использовать "по-человечески" - для представления неравнозначности выбираемых путей для цели процесса... Другое дело, что не всегда неравнозначность имеет место. И тогда надо бы действительно от асимметрии отказаться. Что обсуждалось ранее (в частности, Ильченко предлагал представление).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 16 Декабрь, 2012 09:02 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
И еще по поводу "все определяется правилами подстановки".
В языках программирования мы уже такое имеем - Рефал.

Опять же, чтобы подстановки ВЫПОЛНЯТЬ - нужен исполнитель.
То есть мы все равно попадаем в сферу операционного определения семантики, где семантика понятий определяется программой базового исполнителя - виртуальной машины.

А "нижняя" виртуальная машина - это машина Тьюринга... :)

Или мы имеем не исполнителя, а преобразователя - в другой формат-вид-представление. Но если динамика - внизу все равно машина.


Последний раз редактировалось Валерий Лаптев Воскресенье, 16 Декабрь, 2012 14:10, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Воскресенье, 16 Декабрь, 2012 10:31 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Ну да... "преобразователь" - это, надо думать, просто возможное определение, что делает "языковая машина" - реальная и виртуальная... :)
В общем, теоретических препятствий нет?..


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Труд над идеальным и его оценка :)
СообщениеДобавлено: Среда, 26 Декабрь, 2012 09:56 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот тут кое-что о системе оценки программного продукта: http://www.alex.krsk.ru/ppss/ppss_techpr.htm. Существенно, что ставится вопрос о том, чтобы начинать с ДЛЯ ЧЕГО и далее переходить к ЧТО... :) Похоже, автор согласен и с этим: viewtopic.php?p=76711#p76711.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 11 Январь, 2013 16:25 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 2046
Вот ещё интересная вещь про проектирование системы деятельности с учётом этого.
Возьмём снова пример с Калашникоовым. :) В РВ по поводу "аномальных вариантов" сказано:
https://sites.google.com/site/purebuilder/#TOC--27 писал(а):
...
в отличие от оператора Exit (отсутствующего в PureBuilder), оператор escape(имя_сигнала_отказа):
    объявляет сигнал отказа – переменную логического типа – и присваивает ей значение «истина»,
    объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре, кроме объектов, переданных по ссылке. Не происходит возврата параметров или возвращаемого значения в вызывающую функцию/процедуру. Поэтому сигналы отказа невозможно использовать для моделирования нормальной логики (нарушая при этом принципы структурного программирования), а можно использовать только для случаев аварийного завершения вызываемой процедур.
...
- т.е. при переходе к обработке исключения величины (данные), вызвавшие его, объявляются недостоверными.
А теперь посмотрите, что за величины участвуют в исключении Освободить патронник. Правильно - структура (запись), представляющая реальный автомат. Ну и что здесь будем "объявлять скомпрометированным"? заводской номер? :wink: поузловой состав? :wink: может, состояние? тоже нет - оно просто "другое, чем надо для цели процесса" (потому и исключение выбрасывается)... Как-то надо подумать... о смысле...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Пятница, 11 Январь, 2013 18:57 

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
По поводу отказов программ.
Чем дальше, тем все более отчетливо у меня проявляется осознание того, что возможные отказы и реакцию на них надо ПРОЕКТИРОВАТЬ.
Важно, что реакцию на отказы необходимо проектировать.
Проектирование покажет возможные варианты реакции на отказы.
А отсюда - разработка возможных языковых средств для реализации "отказной" части проекта.
И не факт, что традиционные исключения подойдут.
Тут меня поворачивает в сторону аспектного программирования.
Я эту парадигму практически не знаю, но похоже, что идея там как раз под отказы подходит.

Кстати, вышла отличная книга Орлова "Теория и практика языков программирования". Там об аспектном программировании написано. И еще много чего. Например, описывается ML, который вдохновил Вирта в свое время.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 12 Январь, 2013 13:28 
Аватара пользователя

Зарегистрирован: Воскресенье, 08 Июль, 2007 00:38
Сообщения: 778
Откуда: Москва
Владислав Жаринов писал(а):
Вот ещё интересная вещь про проектирование системы деятельности с учётом этого.
Возьмём снова пример с Калашникоовым. :) В РВ по поводу "аномальных вариантов" сказано:
https://sites.google.com/site/purebuilder/#TOC--27 писал(а):
...
в отличие от оператора Exit (отсутствующего в PureBuilder), оператор escape(имя_сигнала_отказа):
    объявляет сигнал отказа – переменную логического типа – и присваивает ей значение «истина»,
    объявляет все данные из вызываемой процедуры скомпрометированными и делает их недоступными в вызывающей процедуре, кроме объектов, переданных по ссылке. Не происходит возврата параметров или возвращаемого значения в вызывающую функцию/процедуру. Поэтому сигналы отказа невозможно использовать для моделирования нормальной логики (нарушая при этом принципы структурного программирования), а можно использовать только для случаев аварийного завершения вызываемой процедур.
...
- т.е. при переходе к обработке исключения величины (данные), вызвавшие его, объявляются недостоверными.
А теперь посмотрите, что за величины участвуют в исключении Освободить патронник. Правильно - структура (запись), представляющая реальный автомат. Ну и что здесь будем "объявлять скомпрометированным"? заводской номер? :wink: поузловой состав? :wink: может, состояние? тоже нет - оно просто "другое, чем надо для цели процесса" (потому и исключение выбрасывается)... Как-то надо подумать... о смысле...


О смысле уже подумали. Просто программист должен умеючи строить архитектуру разрабатываемой системы - чтобы правильно применять инструменты разработки. В частности, оператор escape будет полезен только в умелых руках. При введении этого оператора преследовались две цели: (1) предотвратить использование чрезвычайных механизмов для реализации обычных алгоритмов и (2) обеспечить плавную деградацию разработанной системы по мере отказов ее элементов вместо отказа всей системы сразу. Первая цель достигается во всех случаях. Вторая цель в Вашем примере не достигается, поскольку система разбита программистом на элементы таким образом, что плавная деградация невозможна. Хорошие инструменты разработки не могут возместить низкую надежность алгоритма, положенного в основу программы. У Вас может быть замечательно надежный автомат Калашникова, но если Вы его сунете идиоту, то тот своих перестреляет.
Существует множество методов проектирования отказоустойчивых систем:
  • Часто можно предложить надстроить алгоритм дополнительным модулем, который будет иным, более простым и надежным образом рассчитывать грубую оценку результата. Если точный результат будет значительно отличаться от этой грубой оценки результата, то система должна при дальнейших вычислениях использовать грубую оценку результата, а не точный результат.
  • При отказе каких-то элементов управления в распоряжении пользователя должны оставаться другие элементы управления тем же объектом.
  • Для каждого из дублируемых физических объектов должна быть обеспечена автономная система управления.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 12 Январь, 2013 15:57 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Владислав Жаринов писал(а):
Похоже, автор согласен и с этим: viewtopic.php?p=76711#p76711.
Елы-палы, Вы бы написали в двух словах, с чем именно, и дали ссылку.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Семантический редактор
СообщениеДобавлено: Суббота, 12 Январь, 2013 15:59 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Валерий Лаптев писал(а):
Чем дальше, тем все более отчетливо у меня проявляется осознание того, что возможные отказы и реакцию на них надо ПРОЕКТИРОВАТЬ.
Неужели это надо ... осазнывать?

В смысле, это не прописано в базовых учебниках?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 679 ]  На страницу Пред.  1 ... 26, 27, 28, 29, 30, 31, 32 ... 34  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 2


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB