DRAKON.SU

Текущее время: Вторник, 19 Март, 2024 14:44

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




Начать новую тему Ответить на тему  [ Сообщений: 107 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 21 Октябрь, 2019 18:40 

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 439
Откуда: Астрахань-Сочи
Можно явно указать направление ответа, добавив в Иконе жирную точку.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Октябрь, 2019 21:53 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
PSV100 писал(а):
"цикл-силуэт", который по сути является циклом вида "while..."
Не вдаваясь в анализ дополнительного функционала, замечу, что это всё-таки не развилка, а case, реализованный с помощью развилок.

Цитата:
Конструкция громоздкая, но зато именно замкнутый блок (согласно канонам "структурщины"
Кстати, это плюс.
Но разговор был не о цикле (а тема так и вообще о таблицах решений).

Цитата:
В самом деле, второй вариант воспринимается лучше
Я бы сказал, не просто "воспринимается лучше", а методически вернее.

Цитата:
Видимо, желателен явный или косвенный признак направления развилок.
Дмитрий Бардынин писал(а):
Можно явно указать направление ответа, добавив в Иконе жирную точку.
Обсуждали варианты:
- форму графического элемента (не "универсальный" ромб и не странно усечённый ромб, зачем-то сохранивший симметричность, а стрела, указывающая в направлении "да" - вправо либо вниз);
- визуальный маркер направления "да" (закрашенный угол наподобие угла в адресе силуэта).
Все варианты были отвергнуты Паронджановым с единственным "аргументом": "Нельзя увеличивать количество новых визуальных элементов, это сложно для новичков!"
Ну да, как углы в адресе закрашивать, так пожалуйста (а что, книги-то уже изданы!), а как что-то действительно полезное - так "сложно для новичков". И это при том, что необходимость рвать скольжение взгляда и подключение медленного мышления для распознавания ТЕКСТА "да/нет" антиэргономична и потому плоха как для новичков, так и для профессионалов...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:30 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Начало группы сообщений PSV100
от 25 октября 2019


Alexey_Donskoy писал(а):
Цитата:
Видимо, желателен явный или косвенный признак направления развилок.

Цитата:
Можно явно указать направление ответа, добавив в Иконе жирную точку.

Обсуждали варианты:
- форму графического элемента (не "универсальный" ромб и не странно усечённый ромб, зачем-то сохранивший симметричность, а стрела, указывающая в направлении "да" - вправо либо вниз);
- визуальный маркер направления "да" (закрашенный угол наподобие угла в адресе силуэта).
Все варианты были отвергнуты Паронджановым с единственным "аргументом": "Нельзя увеличивать количество новых визуальных элементов, это сложно для новичков!"

Да, были раньше "баталии" по поводу:
Метка на выходе "Нет"
нужен ли текст ДА-НЕТ в иконе ВОПРОС?
"Да"-"нет" в развилках

Любопытно завершение одной из тем выше:
https://forum.drakon.su/viewtopic.php?f=162&t=6061&start=20#p100230
Цитата:
Да, что-то было... Ну значит пора тему закрывать, поностальгировали и хватит. Систему не пробьёшь. Интересно, В.Д. пробивает систему ГОСТ, Вы пробиваете систему В.Д. :) Засим возвращаюсь в гараж мастерить свой драндулет. Но последующее поколения драконоводов всё равно на это тему выходить будут.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:34 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
стрела, указывающая в направлении "да" - вправо либо вниз

Подобные стрелки пересекаются с "адресами" и "выводом":
https://forum.drakon.su/viewtopic.php?f=162&t=6061&start=20#p100228
Изображение

В целом, со "стрелами" у ДРАКОН-а есть некий перебор. На схемках ниже тот же ромбик "теряется" среди них:
https://forum.drakon.su/viewtopic.php?f=62&t=6485&p=103325#p103271
Изображение
https://forum.drakon.su/viewtopic.php?f=62&t=6485&p=103325#p103318
Изображение

Интересна вот эта схема:
https://forum.drakon.su/viewtopic.php?f=162&t=1281&start=180#p33345
Изображение

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

Однако, видимо, фантазировать есть смысл лишь в рамках некоего альтернативного "драндулета", а-ля "ДАЛВЯЗ-3" в варианте "да - вправо".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:35 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
PSV100 писал(а):
Конструкция громоздкая, но зато именно замкнутый блок (согласно канонам "структурщины"

Кстати, это плюс.

В принципе то, "цикл со стрелкой" также имеет полезные топологические ограничения. Есть возможность оценить его применимость или возникающие особенности в случае методики "да всегда справа".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:39 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Предлагаю, всё же, пофантазировать в качестве бреда по поводу некоего условного ДАЛВЯЗ, соблюдая исходную задумку -- сопоставление (и совместное применение) графической и текстовой форм алгоритма (о чём данный раздел форума), и адекватность в их соответствии. В качестве текстового языка пусть также будет Оберон или псевдокод по его мотивам (язык с известными особенностями насчёт придерживаться азам структурного программирования).

Выше в теме была выдержка с задачей по поводу поиска:
https://forum.drakon.su/viewtopic.php?f=228&t=6666&start=40#p103887
Изображение

Пусть текстовая форма будет в таком виде:
Код:
WHILE ( (не конец последовательности поиска)
        OR ELSE (состояние не найдено) )
    AND ((текущее состояние не удовлетворяет условию поиска)
        OR ELSE (состояние найдено) )
DO
    перейти к следующему состоянию;
END

Графическая схема будет идентична оригиналу, но "да справа" в условиях.

Особая форма "или"-операции как "OR ELSE" (встречается в ряде языков, как и "and then") предназначается в данном случае для действий. Конструкцию легче "переварить", если бы в языке семантика операторов "and"/"or" была бы как в Lua (также паскаль-подобный язык. Напр., "or" возвращает не true/false, а первый аргумент, если он валиден, и второй в ином случае. Так результатом "x or 0" будет "0", если "x" есть nil/null или false). Если срабатывает "OR ELSE" -- результат void или unit (в зависимости от особенностей типизации в языке) и интерпретируется как невалидный.

В общем, в некотором смысле "OR ELSE" -- способ "узаконить" частые грехи использовать "побочные эффекты" в предикатах (однако, без которых "не выжить" в реальной рутине), в Си-подобных языках "грехи" часто в том числе и с явной операцией присваивания значений переменным (при которых несложно спутать присваивание и сравнение, сейчас в языках хотя бы появилась мода вставлять ключевое слово а-ля var или "продвинутое" let для определения переменных по месту).
В качестве действий может быть что угодно, включая изменение переменных и пр. Может быть последовательность действий (через ";"), но не допустимы какие-либо условные конструкции и циклы.
Таким образом снижается потребность в дублировании операций после цикла для проверок результата его отработки (причём, как бы, весь необходимый разбор состояния остаётся рядом при теле цикла (но не внутри) как часть циклического процесса). Либо же снижается необходимость применять досрочные выходы вида break/exit (и устраивать соответствующий "разбор полётов" внутри тела цикла, а не в контексте предиката), которых нет в циклах вида "while", как и continue.

Условный ДРАКОН-конструктор может гипотетически автоматом "переварить" такие предикаты в тексте, отделить "OR ELSE" и показать их ниже тела цикла как его последствие, точнее защитных выражений.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:42 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Архитектура многоветочного "while" ("цикл Дейкстры") выглядела бы так:
Код:
BEGIN
    x, y := X, Y;
    WHILE x > y DO
        x := x - y;
    ELIF y > x DO
        y := y - x;
    END;
    print(x);
END

Вложение:
dr7.png
dr7.png [ 7.89 КБ | Просмотров: 9124 ]

В данном случае "OR ELSE" неприменимы. Защитные выражения могут быть и комплексными из нескольких икон-условий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Насчёт циклов с постусловиями. Паскалевский цикл вида "repeat...until" подходит под методику "да вниз", для "да вправо" лучше сишный "do...while". Но можно обойтись одной формой "управленческого" цикла "loop...end" (который, всё же, нужен), применяемого, когда затруднительно обойтись одним условным выражением (или "ветками" условий) для цикла (необходимы некие дополнительные действия над состоянием, прежде чем появится возможность для защитных выражений).
На форуме когда-то были темы по поводу, например:
https://forum.oberoncore.ru/viewtopic.php?f=86&t=3159
https://forum.oberoncore.ru/viewtopic.php?f=86&t=3159&sid=3bb8f404431bc26e960deb774e6107cf&start=20#p60161
http://oberspace.org/index.php/topic,425.0.html
http://oberspace.org/index.php/topic,425.msg13272.html#msg13272

В Оберон-07 убран loop-end и предлагается применять "цикл Дейкстры". Однако, цикл может приобретать форму в стиле "силуэта" -- через защитные выражения, специализировано адаптированные, необходимо прыгать по этапам процесса как по "веткам" (а-ля автоматные состояния).
Предлагается форма с "внутренними" защитами -- с использованием "CHECK":
https://forum.oberoncore.ru/viewtopic.php?f=86&t=3159#p59240
Код:
LOOP
  ... ; ... ;
CHECK Conjunct1 DO
  ...; ... ;
CHECK Conjunct2 DO
  ...; ... ;
END

Цитата:
В случае истинности конъюнкта выполнение проходит в следующую секцию цикла, уже под охраной условия конъюнкта.
В случае ложности, разумеется, цикл завершается.
Условие цикла и его отрицание легко собирается в уме.

В Аде есть такой цикл с exit when, но нужно, чтобы было именно условие продолжения, для грамотного построения цикла думать через него удобнее. И строить цикл почти как обычный WHILE, но с промежуточными вычислениями. В случае exit when программист вынужден думать наоборот, "через одно место": "а когда же мне спрыгнуть с цикла".

В отличие от break/exit конструкция CHECK есть защитное выражение -- на верхнем уровне цикла, а не находятся где-то внутри. Защиту можем подкрепить через "OR ELSE":
Код:
BEGIN
    prepare;
    LOOP
        a1;
    CHECK c1 OR ELSE r1 DO
        a2;
    CHECK c2 OR ELSE r2 DO
        a3;
    END
    a4;
END

Вложение:
dr5.png
dr5.png [ 9.01 КБ | Просмотров: 9124 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:51 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Возможен и переход на начало цикла (новая итерация, а-ля операция continue). Формальные (и не формальные) рассуждения для такой возможности -- поближе к автоматным методикам (с соответствующим "недетерминизмом" возникающих событий). У последних позаимствуем оператор every (в частности, от Esterel/Lustre/SCADE), читается как "loop...every..." (операторов EVERY может быть несколько в цикле как и CHECK):
Код:
BEGIN
    prepare;

    LOOP
        a1;
    CHECK c1 DO
        a2;
    EVERY c2;
    a3;
    CHECK c3 OR c4 DO
        a4;
    END;

    IF c5 THEN
        a5
    ELSE
        a6
    END
END

Вложение:
dr6.png
dr6.png [ 13.91 КБ | Просмотров: 9124 ]

Цикл вида с единственным постусловием -- как частный случай "LOOP...CHECK...END" или "LOOP...EVERY...END" (и "LOOP...END" -- вечный цикл).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Цикл вида "for" -- как частный вариант цикла "while".

Таким образом, методика-фантазия "да всегда вправо", как минимум, даёт возможность адекватно согласовать текстовую и графические форму в рамках циклов. Отсюда могут быть соответствующие возможности, вплоть до "ракетного ввода" алгоритма (по ссылке ранее).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 19:58 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
PSV100 писал(а):
Конструкция громоздкая, но зато именно замкнутый блок (согласно канонам "структурщины"

Кстати, это плюс.
Но разговор был не о цикле (а тема так и вообще о таблицах решений).

Точнее -- о деревьях решений. ДРАКОН-методология в качестве преимущества предлагает, скорее, некие плексы решений, что ли. Для чего в рамках двумерной структурной алгоритмизации позволяется произвольный "goto" вперёд, с единственным ограничением в виде запрета пересечений. В результате возможны схемы такого вида:
https://forum.drakon.su/viewtopic.php?f=229&t=6595#p103361
Изображение

Области под "защитой" (маршруты после "вопросов" или "if"-блоки) могут иметь произвольные дополнительные входы, что традиционная структурная алгоритмизация не допускает. Необходимо эти входы выявлять (всё же, они не так заметны как образ конкретно специализированной иконы "вопрос"), следовать обратно и восстанавливать "сторонние" условия, их "соединять" с текущей "защитой", с учётом возможности содержания на пути действий, которые могут влиять на "актуальность" предикатов.
Таким образом, ДРАКОН-методология предполагает гибкое явное представление отношения следования между элементами и условиями прежде всего. Снижается необходимость дублирования выражений (как условий, так и исполнимых инструкций). Однако не в полной мере, поскольку существует ограничение (планарности). Дублирование элементов возможно (или иногда неизбежно), к примеру, и в бинарных линейных графах (по ссылке ранее).

Степану не удалось избежать дублирования (прежде всего, предикатов) в примерах ранее, напр., в этой схеме (в условиях: "machine.state === "expanding"):
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696
Изображение

Из-за переплетения условий (и действий), в самом деле, как отметил Степан: "нельзя "понять" одним махом, как можно понять анекдот" (к тому же, в отличие от тех же примеров насчёт линейных бинарных графов, где "раскладывают" логические формулы из одиночных символов в качестве операндов, в ДРАКОН-рутине осуществляется оперирование "весомыми" предметно содержательными выражениями, "обращение" к элементу может подразумевать исполнение опроса состояния, а то и с "побочным эффектом" (сложно в реальности быть "идеальным" и соответствовать известному "command query separation")).
В результате схемы могут приобрести вид, напоминающий этот пример ("детская задача" в рамках попытки отобразить XOR-отношение):
https://forum.drakon.su/viewtopic.php?f=217&t=5182#p91518

И может быть возможны такие последствия (хотя, всё таки, данный случай есть особенный):
https://forum.drakon.su/viewtopic.php?f=217&t=5182&start=60#p101534


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 20:03 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Попытаемся вместо "деревьев решений" в качестве альтернативы применить "наколенные таблицы решений" или "схематические таблицы" (по ссылке ранее), но по-драконовски, а точнее в контексте всё того же условного ДАЛВЯЗ.

Воспользуемся отмеченным выше примером функции "Tree_itemClick":
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696

Пусть текстовый (и графический) язык не позволяет goto (особая гибкость -- пусть для особых случаев, о чём далее). Построим код с применением "сопоставления с образцом" ("pattern matching") в виде оператора "CASE":
Код:
PROC Tree_itemClick(machine, item, event)
VAR now;
BEGIN
  IF event.button === 0 THEN
    now = getUnixTime();
    CASE
        item.lastClick,
              (now - item.lastClick > DoubleClickThreshold),
                    (machine.state === "expanding")
    OF
    |   TRUE, TRUE, TRUE
    |   FALSE,   _, TRUE: SKIP

    |   TRUE, TRUE, FALSE
    |   FALSE,   _, FALSE:
          item.lastClick = now;
          IF event.ctrlKey THEN
            Tree_ctrlClick(machine, item)
          ELSE
            IF item.leaf THEN
              Tree_singleClick(machine, item, event)
            ELSE
              Tree_clearSelection(machine);
              Tree_selectItem(machine, item);
              Tree_toggleExpand(machine, item, event);
            END   
          END

    |   TRUE, FALSE, TRUE:
          machine.postponedDClick = item.id

    |   TRUE, FALSE, FALSE:
          Tree_doubleClick(machine, item, event)
    END
  END
END;

Сопоставлять можно как угодно:
Код:
CASE cond OF TRUE...
CASE TRUE OF cond...
CASE FALSE OF cond...

В общем, традиционный pattern matching -- любые предусмотренные семантикой образцы, с константами, переменными, символами игнорирования, с деструктивным разбором структуры-образца на элементы и т.д.
Как, напр., и в функциональных языках предполагаем, что оператор "IF" есть всего лишь частный случай оператора "CASE":
Код:
CASE cond OF
| TRUE: ...
| FALSE: ...
END

Графическая попытка:
Вложение:
20191025132014.png
20191025132014.png [ 36.61 КБ | Просмотров: 9124 ]

Для любого "сопоставления" используется один оператор ("вопрос"). В полной форме осуществляется сопоставление образца с "операндами" -- якобы закруглённые прямоугольники -- по мотивам граф/штрих-схем (ранее в теме) и "схематических таблиц":
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103717

В простой форме сопоставления -- как оператор "if" -- подразумевается неявный операнд "TRUE", всегда справа. Снизу -- всегда FALSE, где линия имеет разрыв или ее нет (при соединении с последующими иконами).
На схеме на маршруте под "CASE"-условиями мог бы быть вариант "иначе" (если бы был определен), с соответствующим операндом снизу условий (см. пример далее).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 20:05 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
В данном случае всего лишь фантазия, и в случае чего, конечно же, форма элементов должна быть адаптирована (включая и "разрывы" линий, связи между операндами. Может быть есть смысл "склеивать" условия и операнды по вертикали в одну фигуру, разделенную "полками").
Симпатичный вариант "ромбика" имеется здесь (органично сочетаемый с закруглениями линий и возможными "закруглёнными операндами"):
https://forum.drakon.su/viewtopic.php?f=162&t=1281&start=180#p33345
Вложение:
romb.png
romb.png [ 20.51 КБ | Просмотров: 9124 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 20:07 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Есть возможность для "case" чуть ослабить строгую "структурность", которую несложно "переварить", в т.ч. и в формальных рассуждениях:
Код:
CASE n OF
| >100:
  print("выше нормы")
| 10..100:
  print("норма")
AND THEN
  print("все ок")
| 0..9:
  print("проблемно")
ELSE
  print("опасно")
END

Оператор "AND THEN" вводит общую (безусловную) секцию для предшествующих "или"-вариантов. На схеме:
Вложение:
20191025154753.png
20191025154753.png [ 8.93 КБ | Просмотров: 9124 ]

В данном случае образец сопоставления один, и одна линия операндов, с вариантом на текущем маршруте.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 20:09 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Конкретный произвольный goto в условном гипотетическом ДАЛВЯЗ пусть возможен только по определенным требованиям. На схеме можно оформить как "соединитель" по мотивам:
https://forum.drakon.su/viewtopic.php?f=152&t=5482&start=20#p94190
Изображение


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 20:11 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Конец группы сообщений PSV100
от 25 октября 2019


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 25 Октябрь, 2019 23:22 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5844
Откуда: Москва
PSV100 писал(а):
со "стрелами" у ДРАКОН-а есть некий перебор. На схемках ниже тот же ромбик "теряется" среди них:

Изображение
В этой схеме нарушено Правило семейного сходства.
Чтобы исправить схему, следует нижние 4 полые стрелки выровнять по горизонтали (поскольку они функционально однородны)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 29 Октябрь, 2019 20:28 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Владимир Паронджанов писал(а):
В данной схеме (а не в языке ДРАКОН) со стрелками действительно перебор.
Если убрать стрелки, будет проще и понятнее.

Всё же, скорее всего, подразумевается убрать стрелки из "репертуара исполнителя" (из тезауруса языка извлечь образы "стрелок" и использовать для операций с семантикой ввода/вывода иные формы символов), т.е. извлечь "проблемные стрелки" из технологического языка (иначе, если убрать "стрелки" из схемы -- совсем иной алгоритм).
Владимир Паронджанов писал(а):
В этой схеме нарушено Правило семейного сходства.
Чтобы исправить схему, следует нижние 4 полые стрелки выровнять по горизонтали (поскольку они функционально однородны)
...
Правило семейного сходства следует соблюдать.

Формализация правила мне незнакома, но интуитивно, по-видимому, соблюдать это правило можно лишь ограниченно согласно семантике языка.
Выше был отмечен пример, где это правило, фактически, соблюсти невозможно в полной мере из-за переплетения неструктурных отношений межу условиями и прочими элементами (действиями):
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696
Изображение
В этом "структурном" варианте:
https://forum.drakon.su/viewtopic.php?f=228&t=6666&start=60#p103944
Изображение
хотя бы более-менее явно прослеживается упорядоченность всего процесса: после действия "now = getUnixTime()" следуют несколько альтернативных маршрутов (начало этих маршрутов, видимо, функционально однородны) в зависимости от событий (выровнять элементы можно в привязке к нижней или верхней границе маршрутов).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 29 Октябрь, 2019 20:33 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
https://forum.drakon.su/viewtopic.php?f=228&t=6666&sid=a7bbca1fef4b56ec3cb7a1fbdac2ac94#p103707
Цитата:
В ДРАКОН-схеме можно задать вопрос, совершить действие, снова задать вопрос, снова совершить действие и т.п.
При этом мы:
- избегаем лишних повторов.
- можем совершать действия между вопросами. На примере advanceStep: после вопроса canMoveDown()? - ответ нет - выполняем freezeProjectile().
- можем избегать проверки некоторых условий, что важно, если проверки дорого стоят. На примере advanceStep: clearRow() - затратная процедура. Хорошо, что можно её иногда не вызывать.

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

Скорее всего, в подобных случаях лучше работает методика "управление от данных" (а-ля "dataflow"), нежели "поток управления". Элемент "dataflow" в ДРАКОН-е имеется или, как минимум, можно ввести/утвердить -- конструкция "выбор" (в предположении, что семантика отлична от якобы последовательной серии опросов). Как именно "на низком уровне" осуществляется процесс выбора/перехода -- абстрактно и подразумевается эффективно (как, напр., и процесс перехода с адресов на заголовки веток).

Выше в теме была попытка применить "сопоставление с образцом" (а-ля "таблицы решений"):
https://forum.drakon.su/viewtopic.php?f=228&t=6666&start=60#p103944

Сама методика "сопоставления с образцом" (наследство от Пролога и функциональных языков) может быть эффективной (с контролем охвата вариантов и пр.). Однако, форма конструкции выше явно "наколенная", в данном случае может быть перегружена для анализа человеком, непонятно как формализовать и т.д. (собственно то, другой фантазии и нет).

Имеет смысл рассмотреть ещё один вариант методики "pattern matching"-а в редуцированной форме (удобной в ряде случаев) на манер "join-calculus" -- конъюнкции событий (с формальной основой для верификации и оптимизации).
На примере Lucid Synchrone -- вариация языка ML для "dataflow":
Код:
let node sum x y = o where
present
| x(v) & y(w) -> do emit o = v + w done
| x(v1) -> do emit o = v1 done
| y(v2) -> do emit o = v2 done
| _ -> do done
end

Здесь "node" -- процесс как автомат, с идентификатором "sum", имеющий вход "x", "y" и выход "o". Тело процесса определено как система уравнений (после "where"), в данном случае имеется лишь одна конструкция "present...end" (особая форма "pattern matching"-а), осуществляющая тестирование событий в указанном порядке (сверху вниз). Так при наличии на входе всех двух сигналов (выражение в образце вида "x(v)" -- протестировать и извлечь содержимое в переменную "v") для выхода задаётся сумма входа ("emit o" -- эмиссия сигнала), и т.д. Конструкция "present" требует полного охвата всех вариантов или наличия опции "иначе" (последний вариант в примере, не имеющий действий).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 29 Октябрь, 2019 20:40 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
По мотивам выше перепишем императивную процедуру Tree_itemClick, неоднократно представленную ранее:
https://forum.drakon.su/viewtopic.php?f=228&t=6666&start=60#p103944
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696

в варианте конъюнкции событий:
Код:
PROC Tree_itemClick(machine, item, event)
VAR now;
BEGIN
  IF event.button === 0 THEN
    now = getUnixTime();
    WITH
      lastClick := item.lastClick;
      threshold := now - item.lastClick > DoubleClickThreshold;
      expanding := machine.state === "expanding";
    PRESENT
    | lastClick & threshold:
        item.lastClick = now;
        IF event.ctrlKey THEN
          Tree_ctrlClick(machine, item)
        ELSE
          IF item.leaf THEN
            Tree_singleClick(machine, item, event)
          ELSE
            Tree_clearSelection(machine);
            Tree_selectItem(machine, item);
            Tree_toggleExpand(machine, item, event);
          END   
        END 
    | lastClick & expanding:
        machine.postponedDClick = item.id
    | lastClick:
        Tree_doubleClick(machine, item, event)
    ELSE
      SKIP   
    END
  END
END   

Здесь а-ля паскалевский оператор WITH, но семантика отлична -- задаётся не "вычисленная переменная", а уравнения. Т.е. введенные имена интерпретируются как "алиасы" (вычисляются/редуцируются при потребности и один раз). Если для оператора "CASE" подобные алиасы (неявные) указываются в качестве исходного образца (перед "of" в "CASE...OF"), то для PRESENT таковы задаются через WITH, определяющий область событий. В эту область можно ввести и уже существующие переменные/выражения, например: "WITH item.lastClick; expanding := ..." -- в данном случае мол "item.lastClick" уже содержит (эффективно) результат опроса ( пусть в примере все события являются затратными). Оператор WITH необязателен -- в таком случае тестируются существующие доступные переменные/выражения и должна быть опция "иначе" или рассмотрены все варианты (напр., весь вход и уже определенные/доступные локальные переменные).
Оператор PRESENT работает по схеме выше.


Рассмотрим процедуру в графической нотации. Откровенно говоря, для ДРАКОН-а или условного ДАЛВЯЗ -- нет фантазии (тем более с прицелом иметь удобный идентичный вариант конструкции некоего "выбора" как и для "CASE", так и для PRESENT).

В качестве примера -- в виде Р-схемы. В древние времена, ещё до ГОСТ-а, в тех краях для "pattern matching" предлагалась особая форма двойной ("поглощающей") дуги "с разрывом" (мол блок как не циклическое поглощение дуг, обычная двойная дуга подразумевает цикл или "петлю"):
Вложение:
key_edge.png
key_edge.png [ 22.11 КБ | Просмотров: 9083 ]

Пусть если нет предиката у дуги с разрывом -- операция PRESENT, где в нагрузке под дугой могут быть определены уравнения при необходимости:
Вложение:
R_Tree_itemClick.png
R_Tree_itemClick.png [ 23.41 КБ | Просмотров: 9083 ]


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 107 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

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


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

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


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

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