DRAKON.SU

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

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




Начать новую тему Ответить на тему  [ Сообщений: 46 ]  На страницу Пред.  1, 2, 3
Автор Сообщение
 Заголовок сообщения: Re: Моё видение языка ДРАКОН
СообщениеДобавлено: Воскресенье, 21 Июнь, 2009 11:14 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 511
Рэйлвэй Каген писал(а):
Ярослав Романченко писал(а):
..Необходимо же как-то декларативную часть привести :wink:
имхо, не в Драконе это делать надо, а в любом субдшном кейсе. Ещё лучше - генерить для него автоматом.
Кое-что украдено до нас :mrgreen:
http://download.microsoft.com/download/D/A/B/DAB9E2D8-3A27-4BA7-BE66-8600EE4E33B0/M_Language_Specification.pdf
Весьма занятна гл.13 SQL mapping.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моё видение языка ДРАКОН
СообщениеДобавлено: Суббота, 26 Декабрь, 2009 21:41 

Зарегистрирован: Пятница, 04 Декабрь, 2009 22:41
Сообщения: 1
Где-то говорили что название ДРАКОН в русском сознании негативно отражается (типа в наших сказках он - зло и т.п.). Я же вижу ДРАКОН иначе, хоть я и русский. Во-первых он мне сразу понравился, особенно после прочтения книги. Во-вторых я его действительно ВИЖУ на схеме:
Верхние блоки - это как бы головы :D
Нижние блоки - это как бы лапы :D
Все остальное варится в пузе :D
Прикольно, да? :D :D :D
Художники - нарисуете может? :wink:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О новых возможностях техноязыка
СообщениеДобавлено: Воскресенье, 21 Февраль, 2010 05:22 

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моё видение языка ДРАКОН
СообщениеДобавлено: Четверг, 09 Декабрь, 2010 21:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Это ответ на сообщение viewtopic.php?p=30110#p30110

TAU писал(а):

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

Кстати, по-моему, в самой исходной технологии ГРАФИТ-ФЛОКС генерируется программа именно на автокоде БЦВМ "Бисер".
Может, Паронджанов прояснит.

Уважаемый TAU!

1. Вы совершенно правы в исходной технологии ГРАФИТ-ФЛОКС генерируется программа именно на автокоде БЦВМ "Бисер". Точнее, не на автокоде, а на ассемблере БЦВМ Бисер.

2. Насчет ""ручками" что-то подрихтовать" у меня есть возражение. В существующем у нас Драконе (то есть в ГРАФИТ-ФЛОКСе) никогда не рихтуют в ассемблере. Все исправления и изменения делаются только в исходном Драконе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моё видение языка ДРАКОН
СообщениеДобавлено: Пятница, 10 Декабрь, 2010 11:14 
Аватара пользователя

Зарегистрирован: Пятница, 11 Май, 2007 21:57
Сообщения: 234
Откуда: Украина, Киев
Владимир Паронджанов писал(а):
2. Насчет ""ручками" что-то подрихтовать" у меня есть возражение. В существующем у нас Драконе (то есть в ГРАФИТ-ФЛОКСе) никогда не рихтуют в ассемблере. Все исправления и изменения делаются только в исходном Драконе.
И это правильно! "Ручками" запросто и ошибку допустить.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Моё видение языка ДРАКОН
СообщениеДобавлено: Воскресенье, 28 Февраль, 2021 20:13 
Аватара пользователя

Зарегистрирован: Пятница, 19 Февраль, 2021 14:48
Сообщения: 128
RANUX писал(а):
1. разработчик будет сконцентрирован на диаграмках, вместо того чтобы начать реализовывать функцию
2. посчитайте сколько времени уйдёт на то, чтобы вставить икону, потом её выравнять, соединить с другими иконами, совершить лишние нажатия мышкой, вместо того чтобы сразу написать текст.
3. попробуйте убедить хотя бы часть программистов полностью отказаться от текста и перейти на чистый ДРАКОН :)

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

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

Можно сделать команды для вставки заготовок из икон, в текстовых редакторах такое тоже встречается.

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

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


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

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


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

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


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

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