DRAKON.SU

Язык ДРАКОН подразумевает последовательность действий во времени.
Пример:
Отрежь кусок хлеба, намажь масло, съешь.

А вот в логике времени нет. Там всё существует одновременно. (Не берём в расчёт темпоральную логику).
В логике нет начала и конца.
Пример:
Крабы одновременно и большие, и дорогие.

Тем не менее, человек не может объять необъятное за один присест.
Он вынужден читать логические высказывания одно за другим.
Пример:
"В матрице М 10 строк"
10 == count(rows(M))
Это высказывание, а не процесс во времени.
Тем не менее, его можно прочитать так: вытащили из матрицы строки, посчитали их, получается 10.

Стало быть, можно применять ДРАКОН для логических выражений.

Рассмотрим примеры из известной лекции Владимира Шелехова

Функция сортировать
Логическое И

Вот его аналог на ДРАКОНе:


Предикат отсортированный
Квантор всеобщности и следование (импликация)

На ДРАКОНЕ:


Общий пример с логическим следованием

На ДРАКОНЕ:

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

Спорное решение для представления конъюнкции в Драконе.
А как представите дизъюнкцию A or B и импликацию A => B ?

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

Рифат, не совсем так.

1. Я ввел понятие "канонической дракон-схемы". См. мою книгу "Учись..." стр. 171-177

2. Я ввел понятия "позитивный вопрос" и "негативный вопрос". См. мою книгу "Почему врачи убивают и калечат пациентов или зачем врачу блок-схемы алгоритмов..." стр.131 и далее

3. Я ввел понятие "картографический принцип" языка ДРАКОН. См. мою книгу "Почему врачи убивают и калечат пациентов или зачем врачу блок-схемы алгоритмов..." стр.190-197.

Указанные понятия сводят логические выражения в языке ДРАКОН к ОДНОЗНАЧНОМУ виду.

См. также в книге "Почему..."

Вот так:



Конъюнкция может быть двух типов:
1. Слева от знака импликации. A and B => C
2. Справа от знака импликации. A => C and D
Представления при помощи ДРАКОНа у них тоже разные.
Вот пример:




Дизъюнкция тоже может быть двух типов:
1. Слева от знака импликации. A or B => C (это хорошая дизъюнкция)
2. Справа от знака импликации. A => C or D (это плохая дизъюнкция. В логическом программировании редко применяется.)
Хорошая:

Плохая:

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

Степан, поддерживаю.
Но. Я проработал более подробно для позитивных и негативных вопросов.

Я ввел понятия "позитивный вопрос" и "негативный вопрос". См. мою книгу "Почему врачи убивают и калечат пациентов или зачем врачу блок-схемы алгоритмов..." стр.131 и далее

Дракон-схемы для позитивных и негативных вопросов РАЗНЫЕ.

А почему, собственно?

Вообще, ГРАФИТ изначально создавался для программирования систем управления реального времени для космической техники.

Я сначала согласился с этой мыслью. Всё-таки логическое программирование отличается от процедурного. Значит, по идее, надо и иконы другие ставить.

Однако меня одолевали смутные сомнения. А потом я понял.

Когда мы читаем ДРАКОН-схему, мы становимся на место исполнителя. Сначала сделать это. Сделали. Потом то. Сделали.
В процедурном программировании исполнитель — это процессор. Он-то во время работы программы и исполняет предписания.

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

Пример:

Вот как действует читатель правил, следуя данной диаграмме:
- В рабочей памяти есть утверждение A?
- Есть!
- Тогда добавляем в рабочую память утверждение B.

Вывод
Прочтение правил — процедурный процесс. А значит, ДРАКОН подходит для описания правил в логическом программировании.

ДРАКОН выводит интерпретатор логических программ на чистую воду!

Степан, поддерживаю.
Согласен с вашим примером импликации.

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

А — Тетя Маша приезжает?
Да.

В — Встречай тетю Машу

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

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

Не могу не заметить, что опять у Паронджанова маркетинговые соображения (ориентация на новичков) убивают исходную идею когнитивной эргономики, заложенную в ДРАКОН.

Согласен на все сто.

Я вовсе не предлагаю заменить логику процедурами.
Речь идёт о другом.
Логические утверждения можно рассматривать как команды по работе с логической базой данных.
Примеры:

Утверждение: расстояние(Земля, Солнце, 150000000)
Что это означает: запомни, любезный, что расстояние от Земли до Солнца — 150 млн. км.

Утверждение: отец(Витольд, Дорота)
Что это означает: запомни хорошенько, что Витольд — отец Дороты.

Правило: родитель(А, Б) и пол(А) == мужской -> отец(А, Б)
Что это означает?

Я пойду отдохну, а ты покамест сделай вот что:

Код:

Посмотри-ка в базе знаний, не является ли А родителем Б?
Если является, проверь в той же базе, А — это мужчина или женщина?
Если мужчина, то положи в базу новый факт, что А является отцом Б.

Всё это происходит на этапе компиляции программы. Не во время выполнения!

Повторяю: логические утверждения и правила — это команды по работе с базой знаний.
В чём разница?

Вот процедурные команды:
- посчитай косинус Икс
- открой файл Игрек

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

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

Степан!
Вы дали пример импликации.
Но импликации бывают разные. Желательно уточнить, какую именно импликацию вы имеете в виду.

Материальную?
Строгую?
Релевантную?

Это неизвестно, если смотреть только на диаграмму.

Данная ДРАКОН-схема импликации есть предписание ввести в базу знаний некое правило (продукцию).
Различные виды логик определяют различные действия с базой знаний.

Какая импликация имеет место, классическая или релевантная, зависит от реализации.

Степан, похоже, что Вы предлагаете что-то новое про интерпретацию импликации. Желательно пояснить подробнее.

Вот моя точка зрения:

Импликация

Думаю, это вполне наглядное объяснение.