DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 08:35

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




Начать новую тему Ответить на тему  [ Сообщений: 184 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7 ... 10  След.
Автор Сообщение
СообщениеДобавлено: Вторник, 02 Март, 2021 20:51 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
PSV100 писал(а):
Как-то сомнительно, раз уж речь о массовом программировании, что мейнстрим сможет обойтись без "висящих" икон. Наоборот, наблюдается "гиперусиление" противоположной тенденции.

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

PSV100 писал(а):
Есть ещё и конъюнкция функций, обозначаемое через умножение (преимущественно в "функциональщине") или, в основном, через точку. Также есть и операторы вида "|>", "<|", и "каскадные" операторы (например "..": "a = [1,2,3] ..push(4) ..push(5);").

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

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

PSV100 писал(а):
Кроме тернарных операторов есть и "множественный выбор" в виде "case..of/match...with", возвращающие значения. Такие операторы могут соединяться в цепочки (результат выбора подается на вход следующему блоку).

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

PSV100 писал(а):
А в целом, необходимо предполагать, что сейчас любой чих есть ака expression с результатом. Те же циклы уже возвращают значения (например, см. Rust как фактически уже мейнстрим). К тому же, видимо, модель циклов с else-частью (исполняемой, если тело цикла не завершилось через break) скоро уже будет всеобщим стандартом.
Формат условных выражений (для if, циклов и пр.) будет расширяться: от уже распространенного на сегодня как "init; condition", где init -- необязательная часть обычно с введением новых локальных переменных, до произвольного блока вычислений с конечным результатом, трансформируемым к логической валентности. Например, как для циклов в новой Scala:
https://dotty.epfl.ch/docs/reference/dropped-features/do-while.html

Такой произвольный "условный" блок может возникать где угодно, например, внутри "иконы выбор" как в этих примерчиках на Rust (где результаты -- это "варианты" для "выбора", подобный функционал уж очень вероятно будет не только прототипным):
https://github.com/rust-lang/rfcs/issues/1380

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

Значит будем внедрять и в схемах. Выглядеть всё это будет очень наглядно, гораздо лучше, чем в коде.

PSV100 писал(а):
Есть ещё такие операторы как "guard" в Swift -- специальная форма "if" без then с else-частью, как правило, с return, при этом вводимые переменные (если есть) ассоциируются с дальнейшей внешней областью.
Также есть и такие "защитные" операторы как "?" в Rust, осуществляющий досрочный return из любого выражения (собственно-то, даже "не имеющий своих вопросов").

Это тоже запланировано, if с break, continue, return, отображается как ответвление от шампура, Да выход справа (или внизу при инверсии вопроса).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 02 Март, 2021 21:10 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
PSV100 писал(а):
Пожалуй, вот для "горизонтального Дракон-а" неплохой потенциал у "FBD" (если, всё же, нужно уж "раскрывать"):
https://forum.drakon.su/viewtopic.php?p=61303

Изображение

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


Вложения:
IMG_20210302_210752_332.jpg
IMG_20210302_210752_332.jpg [ 20.49 КБ | Просмотров: 4700 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 02 Март, 2021 21:31 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
PSV100 писал(а):
В предложенных выше вариантах форм отнюдь не "как на ладони" (скорее наоборот, без формул "ладони" не понять).

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

PSV100 писал(а):
Пока кое-какие практические эксперименты не очень впечатляют, если говорить о "схема <=> текст" как "один в один" в мейнстриме:
https://forum.drakon.su/viewtopic.php?f=208&t=6971#p105354

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Март, 2021 15:45 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Начал делать компонент отрисовки икон (Icon.svelte), в SVG нет сейчас переноса длинной строки, есть вставка произвольного HTM, но с этим будут проблемы экспорта, поэтому лучше свой компонент сделать.

Так как в ДраконКод нельзя вручную изменять размер и положение икон (в пространстве), то требуется автоматическое отображение любой информации на иконах.

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

Это позволит и отобразить текст любого объёма, и заставит писать немногословные комментарии к коду, которые будет легко читать на схеме.

Как только получится нарисовать хотя бы простую полноценную схему, выложу код, можно будет посмотреть, как это работает, прямо в браузере.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Март, 2021 20:08 

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

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

В контексте "лямбда-деревьев" в "формулах" для подстановки вы применяете конструктор "unit" (скобки). Всё же, часто это именно конструктор со своей семантикой. Можно заменить на иной символ, но проблематика в другом.
В такой форме сети функций вообще нет связей операндов (ака "кастрированные FBD"), тем самым "отжирается мыслетопливо" у наблюдателя, принуждённого к "редукции" не визуально. В простых случаях он стерпит (или явные связи не нужны и они лишь визуальный шум), но при деревьях или сети...
Взгляните на фрагмент примерчика (вполне себе мейснтримный Kotlin):
Код:
fun main() = runBlocking<Unit> {
//sampleStart
    val list = asyncStringsList()
    val result = select<String> {
        list.withIndex().forEach { (index, deferred) ->
            deferred.onAwait { answer ->
                "Deferred $index produced answer '$answer'"
            }
        }
    }
    println(result)
    val countActive = list.count { it.isActive }
    println("$countActive coroutines are still active")
//sampleEnd
}

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

Вероятно, операторные связи, всё же, необходимо как-то выделять (иначе для чего тогда схема ?), например, как в "схематических таблицах" (заодно может быть в их же стиле и значения операндов для фичастого "pattern matching"-а, если уж "функциональщина" по полной):
https://habr.com/ru/post/80893/
ibnteo писал(а):
PSV100 писал(а):
Нет сомнений, что такая фичастая "императивная функциональщина" пролезет во все дыры мейнстрима.

Значит будем внедрять и в схемах. Выглядеть всё это будет очень наглядно, гораздо лучше, чем в коде.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Март, 2021 20:18 

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

Отличаются тем, что их видно на схеме, в отличие от Цикла ДЛЯ, разные циклы различаются по внешнему виду, надписями внутри икон, а вложенные циклы будут выделяться оттенками цвета, пару найти легко, не изменяя ширину икон.

Что же до досрочного выхода из цикла, есть висящие иконы break, для повторения цикла continue, и есть множественные выходы из схемы return, ровно так, как и в реальном коде, только в отличие от кода, они на схеме прекрасно видны.

Предлагаю оценить и иной вкус, построив схемку для вот такого примерчика, на языке ParaSail -- тренировочная площадка для Ada/SPARK:
Вложение:
Search_parasail.png
Search_parasail.png [ 21.05 КБ | Просмотров: 4674 ]

Есть специфика в синтаксисе языка, напр., через "T => ..." объявляется ссылка, в языке нет указателей, есть опциональные типы-значения, принимающие null. Алгоритм можно представить в иной форме, пусть с указателями. Псевдокод (для continue аргумент цикла задаётся императивно в виде "T := ...", что возможно и в ParaSail):
Код:
PROCEDURE Search(Root: Tree_Node; Desire_Value: Value_Type): REF Key_Type;
BEGIN
  FOR T := Root WHILE T <> NIL DO
    IF T.Value = Desire_Value THEN
      RETURN T.Key;
    ELSE
      CONTINUE T := T.Left;
    PAR
      CONTINUE T := T.Right;
    END
  END;
  RETURN NIL;
END;

В Ada крайне консервативный подход, минимум "лямбд" и рекурсий, стремление к структурности, императивности. Но в данном случае есть и return с continue как наименьшее зло из-за потребности в параллельных действий в цикле. Последние ввели в язык (в новый готовящийся стандарт, уже на подходе) из-за необходимости снизить градус в применении универсальных многопоточных средств (конкурентные объекты, так называемые task-и пр.), явные управляющие конструкты лучше выражают модель вычислений для локализованных задач, позволяют решить ряд проблем в формальной верификации.
Так, внутри цикла в случае, если элемент не найден, то следующие итерации запускаются параллельно (для левого и правого поддерева). Условие while интерпретируется как защитное выражение итерации. Если в потоке цикл прерывается (через break или return), то автоматически прерываются остальные возможные потоки. Цикл завершается только после завершения работы всех потоков.

Попытка построить схемку:
Вложение:
Search_par_cont.png
Search_par_cont.png [ 9.41 КБ | Просмотров: 4674 ]

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Март, 2021 20:22 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Насчёт гипотетической трансформации алфавита. Выше применялась "двойная" граница для continue. Такой приём может "конфликтовать" с иными принципами, использующими элементы "двойного" контура. Напр., "вставка". Или распространенное в схемах "объявления" (переменных и пр.), как здесь ранее было в картинках от Flowgorithm:
Вложение:
decl.png
decl.png [ 7.03 КБ | Просмотров: 4674 ]

Возможно возникнет желание по аналогии делать и "вопросы" с "декларациями" (ромбик с пометками двойной границы), когда там "возникают" переменные (к слову, на развилках ещё нужно анализировать, в какую сторону "живут" переменные, но совместно с выяснением да-направления). Аналогично и для циклов. В то же время и для "параллельности" популярна двойная линия. А те же циклы могут быть полностью параллельными (может быть и с "декларациями"), например (Ada):
Код:
parallel for I in Grid'Range(1) loop
   Grid(I, 1) := (for all J in Grid'Range(2) => Grid(I,J) = True);
end loop;


-- Для параллельного цикла можно задать количество параллельно исполняемых
-- отрезков указав его как выражение либо как спецификацию индекса:

parallel (Num_CPUs) for I in Arr'Range loop
   A(I) := B(I) + C(I);
end loop;

Т.е. "параллельность" необходимо "натягивать", вероятно, на весь заголовок цикла, который к тому же может быть комплексным. Или на всё "тело". Однако, выше "тело" цикла одновременно запускалось как множество экземпляров потока, но возможен иной вариант -- экземпляр "параллельного тела" может стартовать после итерации (ниже пример на ParaSail -- в then-части в качестве "следующего" значения указываются "параллельные" значения):
Код:
for X => Root then X. Left || X. Right while X not null loop
  Process (X. Data);
end loop ;

Параллельные действия могут быть и как части тела цикла (в примере ниже в отличие от предыдущего "Process(X.Data)" исполняется одновременно с обработкой над X.Left и X.Right):
Код:
for X => Root while X not null loop
     Process(X.Data);
  || continue loop with X => X.Left;
  || continue loop with X => X.Right;
end loop ;

Собственно то, параллельные действия могут быть в произвольном месте (Ada):
Код:
procedure Traverse (T : Expr_Ptr) is
begin
  if T /= null
    and then
     T.all in Binary_Operation'Class
  then -- recurse down the binary tree
    parallel do
      Traverse (T.Left);
    and
      Traverse (T.Right);
    and
      Ada.Text_IO.Put_Line
        ("Processing " & Ada.Tags.Expanded_Name (T'Tag));
    end do;
  end if;
end Traverse;


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 04 Март, 2021 20:26 

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

На Р-схемах выразить переходы возможно (в примере, та же задачка ранее, дивергенция/конвергенция потоков отмечена спецвершинами, внутри цикла под двойной "дугой-петлёй" return и continue заданы как структурные переходы соответственно на конец схемы и начало (звёздочка) данной структуры) -- текстовая псевдографика:
Код:
PROCEDURE Search(Root: Tree_Node; Desire_Value: Value_Type): REF Key_Type;
BEGIN
  FOR T := Root WHILE T <> NIL DO
    IF T.Value = Desire_Value THEN
      RETURN T.Key;
    ELSE
      CONTINUE T := T.Left;
    PAR
      CONTINUE T := T.Right;
    END
  END;
  RETURN NIL;
END;

Вложение:
r_search.png
r_search.png [ 5.04 КБ | Просмотров: 4674 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Март, 2021 01:12 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
PSV100 писал(а):
Предлагаю оценить и иной вкус, построив схемку для вот такого примерчика, на языке ParaSail -- тренировочная площадка для Ada/SPARK:
Вложение:
Search_parasail.png

Есть специфика в синтаксисе языка, напр., через "T => ..." объявляется ссылка, в языке нет указателей, есть опциональные типы-значения, принимающие null. Алгоритм можно представить в иной форме, пусть с указателями. Псевдокод (для continue аргумент цикла задаётся императивно в виде "T := ...", что возможно и в ParaSail):
Код:
PROCEDURE Search(Root: Tree_Node; Desire_Value: Value_Type): REF Key_Type;
BEGIN
  FOR T := Root WHILE T <> NIL DO
    IF T.Value = Desire_Value THEN
      RETURN T.Key;
    ELSE
      CONTINUE T := T.Left;
    PAR
      CONTINUE T := T.Right;
    END
  END;
  RETURN NIL;
END;


Если в IF присутствует RETURN (или BREAK, CONTINUE), блок ELSE теряет смысл, схемы будут выправлять эту ситуацию. Блок кода с CONTINUE можно расположить в закрывающей иконе цикла, либо добавить параллельный процесс с двумя иконами Вопрос и на каждой по висящей иконе CONTINUE.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Март, 2021 06:50 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Уже существует представление SELECT запросов SQL на ДРАКОН-схемах?

Пока что вижу запросы в перевёрнутом виде, сначала идёт WHERE, внутри него FROM, поля SELECT в самом низу.

Иконы Вопрос задают условия в блоках WHERE, ON, HAVING, на выходе ДА находятся блоки Действие для FROM, JOIN, GROUP BY.
Список полей можно расположить сбоку от иконы Вывод, либо в самом поле, поля сортировки и группировки сбоку от икон Действие, так же, как изображается архив, сбоку от поля может быть вложенный запрос.

Внешне будет похоже на вложенные анонимные функции, строит строку с SQL-запросом.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 08 Март, 2021 20:23 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Похоже для SQL придётся делать на основе икон ВОПРОС иконы ФИЛЬТР, у которых нет выхода НЕТ на крайних иконах справа, лишь ДА с возвратом на основной шампур, будут располагаться под иконами ДЕЙСТВИЕ. Под блоком икон FROM и JOIN это будет WHERE, под иконой JOIN это ON, под GROUP_BY — HAVING. Икона SELECT может быть на иконе КОНЕЦ, внизу блока SQL. Иконы SELECT, GROUP_BY, ORDER_BY могут содержать список полей, если их больше одного, которые могут расширяться на подзапросы.

Ещё один вариант, это расположение икон ФИЛЬТР справа от ДЕЙСТВИЙ, но тогда схема будет занимать много пространства по ширине, чего не хотелось бы делать, чтобы было удобно работать с несколькими схемами (файлами) на одном экране.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Март, 2021 18:42 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Получается вот так:


Вложения:
IMG_20210309_184022_469.jpg
IMG_20210309_184022_469.jpg [ 82.85 КБ | Просмотров: 4595 ]
IMG_20210309_184019_798.jpg
IMG_20210309_184019_798.jpg [ 44.09 КБ | Просмотров: 4595 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Март, 2021 03:12 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
Это выглядит как натягивание совы на глобус


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Март, 2021 08:50 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
PSV100 писал(а):
сложно определить фундаментальный критерий "супер-эргономичного" иконостроения. Велика вероятность, что часть жаждущих моделировать окажутся за бортом, либо же не получится изъять "ключевые" слова в полном объёме, или возникнут именно что иероглифы.

Автор идеи ibnteo пытается решить свою задачу по максимуму (программа-максимум).
Однако даже частичное решение задачи (если ее удастся решить) принесет большую пользу.
Было бы интересно увидеть программу-минимум.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Март, 2021 15:34 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Comdiv писал(а):
Это выглядит как натягивание совы на глобус

А иначе задачу не решить, либо всё текстом пишем, либо можно будет на схемы перейти полностью.

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

Работа с SQL-дампом тоже понадобится, но там лишь CREATE и INSERT запросы, их тоже надо будет натянуть на схемы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Март, 2021 15:45 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Владимир Паронджанов писал(а):
Автор идеи ibnteo пытается решить свою задачу по максимуму (программа-максимум).
Однако даже частичное решение задачи (если ее удастся решить) принесет большую пользу.
Было бы интересно увидеть программу-минимум.
Не совсем так, ключевых слов будет довольно таки мало, сейчас это лишь те, что задают структуру программы, где вставляем отступы, оборачиваем в блоки, где хотим визуально выделить структуру, плюс возможность скрывать исходный код под комментарии, и возможность программировать сверху вниз, сначала создавая общую структуру, и лишь затем наполняя её кодом, маленькими кусками, икона за иконой.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Март, 2021 16:25 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 133
Откуда: Киев
ibnteo писал(а):
А иначе задачу не решить, либо всё текстом пишем, либо можно будет на схемы перейти полностью.
В данном случае получаются схемы ради схем во что бы то ни стало, бикоз ви кэн. То есть, задачу, возможно, или не надо решать, или надо решать не так.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 11 Март, 2021 20:25 

Зарегистрирован: Пятница, 18 Январь, 2019 12:03
Сообщения: 50
ibnteo Вы тратите энергию впустую. Ничего личного, но Вам ibnteo надо учится работать в команде на правах младшего. Сами Вы пока не можете тянуть проект самостоятельно. Не пройдете ступень подмастерья дальше будет только хуже.
Я Вам не родственник и не друг поэтому могу говорить открыто.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 01:02 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
Рассмотрел вариант, где код будет разложен на максимальное количество икон, не понравился такой вариант, буду укрупнять иконы, любой IF это одна икона Вопрос, но будет конструктор логических выражений, который появляется на схеме при входе в икону, при потере фокуса логическое выражение будет складываться в главную икону. Это позволит увидеть логическое выражение в схеме, и не будет мешать при обзоре всей схемы, где важнее видеть описание таких икон, чем их код.


Вложения:
IMG_20210227_163238_956.jpg
IMG_20210227_163238_956.jpg [ 32.59 КБ | Просмотров: 4522 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 12 Март, 2021 20:52 

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

Скорее всего, для SQL на схемах не убрать текстовые ключевые слова вовсе, даже для where c having (см. ниже). Иначе придётся изобретать неимоверное количество иероглифов (в т.ч. и комплексных -- ака значок "создать" плюс "свисающий" от него "database" и т.п.), что, прежде всего, чуждо для репертуара моделирующих. И с помощью графа для SQL вряд ли получится выразить "реляционные" операторы в каком-либо удобоваримом виде (для чего, собственно то, исходный язык предназначен).

Когда-то, во времена моды на "объектные СУБД", был такой проект SBQL (мало кому известный) -- Stack Based Query Language -- язык запросов к структурам данных, альтернатива SQL, LINQ, OQL, Prolog/Datalog и прочим всяким XQuery и т.д. Краткое введение (родного спецсайта уже нет):
Stack-Based Architecture and Stack-Based Query Language

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

Например, ниже выборка на SBQL в виде текст/схема и аналог на SQL (где знак "#" является обычным символом, применимым для идентификаторов -- "номер", "ID"):
Вложение:
sbql1.png
sbql1.png [ 40.05 КБ | Просмотров: 4498 ]

Вложение:
r_sbql1.png
r_sbql1.png [ 4.11 КБ | Просмотров: 4498 ]

На схеме над дугой указывается "проекция", под дугой -- "предикат". Смежные по вертикали дуги одной направленности -- оператор "соединение" ("join", в языке только один вид соединения). Присоединение структуры справа -- "навигация" ("точка"). В языке нет потребности в декларациях вида "group by", "having". Операции ака классическое "объединение" ("union") в чистом виде нет, предполагается при потребности следование запросов комплементарной структуры (последовательность схем). В принципе то, можно и явный оператор ввести, на схеме -- параллельное соединение структур (по вертикали, где каждая структура со своими вершинами). В языке имеются специализированные "объединения" для рекурсивных запросов: операторы "close by" и "leaves by" для "полного" замыкания и выборка только структур-"листьев" (не имеющих "дочерних" связей). На схеме: присоединение справа циклической структуры как "петля" (двойная дуга) для "полного" замыкания, циклическая структура с обратной дугой -- для "листьев". Для всех "замыканий" имеются вариации как "unique", но эта декларация может быть указана как "distinct" в "проекции" (над дугой). Запросы могут быть представлены в виде системы уравнений в стиле Prolog/Datalog (с иной семантикой, в исходном языке в рамках уравнений есть непосредственно оператор "union" как аналог "leaves unique by") вместо громоздких вложенных конструктов, на схемах -- возникает их совокупность (связи -- по именам переменных, схемы частично можно упорядочить, как и составляющие уравнений).

Пример рекурсивного запроса -- текст и схема (в двух вариантах) на SBQL, и два варианта аналога на SQL -- в диалекте Oracle и как common table expression:
Вложение:
sbql2.png
sbql2.png [ 75.65 КБ | Просмотров: 4498 ]

Вложение:
r_sbql2.png
r_sbql2.png [ 6.58 КБ | Просмотров: 4498 ]

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

Но не в случае SQL. В примере выше такие выражения как "start with" и пр. требуют отличения от "where" и т.д. Некая обвертка в виде геометрических фигур, в нагрузке которых, фактически, не изъять текстовые ключевые слова, представимая лишь как некая "mindmap" (вся суть графа в данном случае) -- "визуальный шум". Скорее, нечто вроде "Code Bubbles" может оказаться полезнее -- продвинутый текстовый редактор с пониманием семантических связей, если таковой сможет делать более удобное расположение отформатированных "кусков" текста, к примеру, расположить список столбцов по колонкам в соответствие с источниками, вспомогательными линии указать какие-то связи и т.п.


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

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


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

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


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

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