DRAKON.SU

Как-то уж совсем тяжело вообразить какой-то такой возможный конструкт...

Предлагаю вновь взглянуть на примерчик ранее, с небольшими доработками -- исключив ранний return (который и в Р-схемах "режет глаз", хоть и нет "свисания", но есть "структурный вылет" изнутри):


Выше применяется цикл while, ака "цикл Дейкстры" (который фактически трансформирован до "цикла-паука", поскольку косвенно содержит и явное условие выхода). На схемах цикл с предусловиями задаётся как "петля", где двойная дуга не содержит предиката -- тогда предикаты начальных дуг в структуре определяют условия входа в цикл. Предполагается, что оптимизациями вычислений охран занимается транслятор (в стиле "join calculus").
В целом параллельные действия как "замыкания" получают ссылки на окружающие переменные/параметры, взаимодействие возможно через специализированные конкурентные объекты либо через переменные, находящиеся под "защитой" операторов exit, continue. Оператор continue создаёт новую копию данных для запускаемого процесса. Оператор exit прекращает исполнение всего блока параллельных действий (не только "выход из цикла" в экземпляре параллельного процесса), устанавливает значение переменной для "основного" процесса.
На схеме exit обозначен как "структурный переход на конец данной структуры" ("#"), который "упирается" в границу цикла, continue явно не отмечен в виде структурного перехода (после начала пар. действий "(||)" дуги не заканчиваются как "(&)", следуют сразу же "естественные переходы" в начало цикла).


В Дракон-е, в отличие от блок-схем, "гиперграф" как параллельные действия (двойная линия) обозначен только началом, его конец по сути есть общая шина слияния. Может быть для "стрелочных" циклов как-то можно было бы воспользоваться такой "лазейкой", начинать "гиперграф" в теле цикла и заканчивать вместе с обратной линией. Однако "стрелочный" цикл не имеет строгих границ блока, всего лишь маршрутный контур с множеством входов и выходов и чего угодно...
Нужен замкнутый блок. Однако, я не могу представить себе потенциальное сочетание предлагаемых "указателей" для начала и конца, continue и exit с параллельным стартом итераций. Причём чтобы и "свисало" однообразно. Если вписывать нагрузку в иконы "конец" цикла, чтобы они же были и continue (причём их должно быть тогда множество), то необходимо как-то отличать иконы от конца циклов с постусловиями.
Необходимо как-то определиться с формой "параллельности", чтобы однообразно строить и параллельные действия, и параллельные циклы. В т.ч. и с общим параллельным стартом (на схеме вершину "(&)" можно убрать -- двойная дуга определяет зону действий):


Неочевидно решение, как универсально можно применять двойную линию... Скорее понадобятся отдельные иконы для начала и конца блока параллельных действий, их же присоединять ака "синхронизатор" к "циклическим указателям", что ли...

Здесь на форуме немало критики громоздкого конструкта "выбор"... А подобные модели, как выше, скорее, будут представлены как "огромный квадратик" с кодом/псевдокодом, с полной реализацией, или как комментарий с объяснением "на пальцах", или со вписанной Р-схемой.

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

В общем то, ситуацию, когда и при использовании силуэта всё равно возникает желание "выпрямлять" в виде "свисаний" как здесь:
https://forum.drakon.su/viewtopic.php?f=62&t=6650

понять можно, поскольку в случае массы досрочных return её "канализация" в силуэт напрочь "засоряет" шину адресов переходами на "завершение" (причём ради единственной пустой ветки с "концом").

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

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

Выправляется то, что в таких IF не нужен ELSE. Если условий много (ELSEIF), то все иконы со свисающим выходом переделываются автоматически в разные IF, то есть, на схеме такую неточность не получится совершить. Если же загрузить такой неправильный код в схему, и потом сохранить его, то он будет переделан на правильный и более простой для понимания.

Да и не надо ключевые слова убирать, по крайней мере в иконах Действие. Цель - в представлении запроса в виде схемы, чтобы можно было работать с отдельными частями запроса, видеть их как отдельные иконы, чтобы не было мешанины текста. ДраконКод будет мало что знать о том, что именно он собирает, какой именно диалект SQL используется, лишь в общих чертах, что это SQL. По сути, это просто универсальный редактор, ему будет достаточно знать об обрабатываемом тексте не больше, чем знают текстовые редакторы с подсветкой синтаксиса.

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

Висящие иконы оказались вовсе не страшными, и благодаря им ещё и функциональное программирование удастся на схемы перенести. Силуэт с висящими иконами даже изящнее, на мой взгляд, только они могут быть информативнее, вместо слова Конец, в них можно просто писать, что именно возвращаем.

Форум не удобно смотреть со смартфона, возможно ли перевести оформление форума на адаптивный дизайн, или хотя бы прописать в заголовке <html><head> следующий тег?
П.С.: не нашёл где можно обсудить внешний вид этого форума.

Нужно обращаться к администратору форума Борису Рюмшину — на форум oberoncore:
https://forum.oberoncore.ru/viewforum.php?f=25

На том форуме закрыта регистрация.

Вы уже зарегистрированы и на этом, и на том форуме.
Просто войдите на тот форум, откройте новую тему и пишите.

Создал тему по адаптивной вёрстке форумов:
https://forum.oberoncore.ru/viewtopic.php?f=25&t=6743

Для работы с файлами слева будет отображаться схема со списком директорий и файлов в текущей директории и список родительских директорий, позволяющая быстро перемещаться по дереву директорий, занимая при этом один шампур на всей схеме.

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

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

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

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

В панели свойств можно будет массово поменять права на файлы, задать маску для массового переименования файлов.

ДраконКод-редактор заменит заодно и различные утилиты работы с файлами.

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

Решил, что не буду делать вставляемую на любом сайте схему в виде исходного кода схемы, для этого лучше подходит вставка картинки, SVG или PNG, которые будет легко получить из любой части схемы. Но свой формат разметки для схем нужно будет сделать, чтобы хранить обычные схемы, расширение у файлов будет .dc, он будет текстовым и наглядным, для работы со схемой и в обычном текстовом редакторе.

ibnteo, вы пишите все сообщения в одной теме.
Может быть (согласно логике вашего изложения) целесообразно открыть одну или две новых темы?
Как вы считаете? Как вам удобнее?

Лучше в одной теме, это всё (кроме адаптивной вёрстки форума, не нашёл подходящего раздела) относится к ДраконКод-редактору схем.

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

Мне кажется, что моделирующие параллельные циклы предпочтут InteloGraf -- там хоть есть возможность "разорвать" тело цикла по "веткам" и разнести ключевые слова-фигуры, как в текстовом формализме по разным строкам.

Повторил на Р-схеме примерчик ранее, в меру своей сообразительности и фантазии:
https://forum.drakon.su/viewtopic.php?f=62&t=6996&start=40#p105566


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

Немало в целом возникнет конструктов, требующих не сворачивание/разворачивание, а постоянный обзор. Может быть для таких примеров как здесь на странице:
https://kotlinlang.org/docs/type-safe-builders.html

"деревья" ака DOM к месту. А в примере ранее:
https://forum.drakon.su/viewtopic.php?f=62&t=6996&start=60#p105599

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

Ну да, здесь возникает вопрос из разряда "либо шашечки, либо ехать".

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

У Р-схем суть "общей картинки" как модели деятельности иная, чем у формы графа с вершинами-работами в виде геометрических фигур с замкнутым контуром -- это упорядоченный граф переходов (с вершинами-"состояними" и работами как дуги) с контурами самих переходов:

Подобные схемы, как ниже, могут "убить на повал" неподготовленного:

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

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


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

Можно попробовать по мотивам примерчика выше составить некий аналог в виде диаграммы состояний, Дракон-схемы. Рассмотреть Дракон-схемы в разных вариантах, включая применение силуэта не только в качестве вынужденной меры по снятию возникающих пересечений линий, но и целенаправленно для разделения задачи на части (с сопутствующими эргономичными техниками в виде "закрашиваний" и т.п. в адресах/заголовках для возможных циклов, вспомогательных пунктирных или иных линий для связей между ветками), с выделением каждого "состояния" в отдельную ветку в качестве варианта автоматной методики (к слову, в исходном алгоритме не было явных "состояний" в виде дополнительного именования вершин), заменить надписи на развилках на подкрашивающие пометки ромбов, изъять возможные "стрелочные" циклы и заменить на разметку через "указательные" иконы границ, применять "висящие" иконы, если необходимо, рассмотреть вариант с отказом от силуэта и пр.
При такой же "маленькой" нагрузке в виде коротких формул уменьшаются и размеры икон в Дракон-схемах, что только способствует обозримости:
https://forum.drakon.su/viewtopic.php?p=43805#p43805


Увы, я не возьмусь за такую задачку.

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

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

Обычно критикуется факт, что У Р-схем с наглядным аналогом "туговато", мол визуальные средства ограничены (однако, целенаправленно) так как нет "слияний" шин:

Или улучшалка возможна как обрыв/return (на схеме лучше разрыв и изображать как структурный переход -- не очень то приятное возникнет сочетание вершин (с "дырочкой"), но зато явное "в лоб", раз так постановили. Но, вероятно, примененный редактор их не рисует):

Возможен и такой вариант:

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

На схемах есть возможность частично компоновать поступательные структуры вниз (кроме "нарезки" схем на отдельные части ака ветки силуэта), как "ветки" в InteloGraf -- используя "квадратные" вершины:

т.е., ниже -- схема слева "раскрывается" в схему справа:

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

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

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

Предлагаю взглянуть на следующий пример -- самый сложный среди там представленных именно как "дерево решений", с промежуточными действиями. Но для объективности сначала не читая текст, содержащий постановку задачи:
https://forum.drakon.su/viewtopic.php?f=228&t=6666#p103696



Желательно поэкспериментировать:
-- восстановить постановку задачи, наблюдая алгоритм на данном технологическом языке (он ведь должен обеспечивать наглядность и понимание) не зная исходной модели на естественном языке;
-- насколько облегчается эта задача восстановления, если предварительно знать постановку.

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

Предлагаю оценить следующие факты. В примере дублируется условие 'machine.state = "expanding"' (к слову, "визуальная гибкость" Дракон-а за рамками академических примерчиков не снимает проблемы дублирования в общем случае). Достаточно ли выразителен язык, чтобы уточнить наблюдателю: это именно одна и та же проверка или новая оценка состояния, которое могло измениться (в императивной среде с совместно исполняемыми процессами)? Пусть суть этой проверки понятна из контекста согласно типу используемых элементов (к слову, вероятно, пример с применением некой автоматной методики, явный опрос "в каком состоянии?" имеет настороженную методологическую окраску, вроде бы, "состояние" не для этого предназначено). В случае чего, (тем более, если операция опроса "тяжёлая") эту проверку можно оформить отдельно с сохранением результатов, как в примере целенаправленно исполняется один раз функция "getUnixTime()" для установки значения переменной "now", используемой в нескольких местах. Однако переменная может оказаться невостребованной и её вычисление напрасным в зависимости от результатов "вопросов", если допустить необязательность или даже не допустимость данного действия ("getUnixTime()") без потребности -- очевиден ли на схеме факт необязательности инициализации переменной "now"? Очевидно ли: дублированное выражение 'machine.state = "expanding"' вычисляется всегда в алгоритме или есть путь без такой проверки?

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

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