Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>На Хабре опубликована моя статья по языку ДРАКОН: ВП>https://habr.com/ru/post/537294/
Прочёл. Опять — много эмоций, повторения мантр. Никаких обоснований того, что Дракон волшебным образом помогает писать безошибочные программы, нету.
Одни намёки, и наваливание бессмысленных подробностей вроде "аксиоматического подхода".
Ну да — ограничение возможности рисовать стрелки и произвольно размещать блоки в схеме гарантирует синтаксическую корректность алгоритма. Ну и что? Ценность её близка к нулю — синтаксические ошибки в современном мире вообще не являются предметом борьбы.
Их в любом случае отловит компилятор; и 99.9% современных IDE указывают на такие ошибки ещё в процессе набора текста.
Чтобы претендовать на спасение жизней, нужно предложить что-то большее, чем "в нашем языке нет прямого способа задавать тело цикла, поэтому разработчик не забудет закрыть фигурную скобку".
В частности, в алгоритме летающей тарелки — ошибка. Помог ли её обнаружить Дракон? Нет, не помог.
Вместо этого начинается елозинье задом по муравейнику:
Если левый двигатель в норме, то мы включаем плазменный реактор. Так и должно быть. Здесь нет никакой ошибки
А в моей конструкции тарелки так нельзя — неисправный двигатель при подаче энергии взрывается. Ну, и где же "доказательство корректности"? Ничего подобного нет.
В общем, ДРАКОН как не обладал никакими волшебными свойствами, так и не обладает. К корректности программ он никакого отношения не имеет — нет в нём средств сопоставить алгоритм с ограничениями (предусловиями, постусловиями, и инвариантами). Всё, что есть — это способ редактирования программ, при котором экран замусоривается визуально громоздкими конструкциями, а текстовые операции типа копирование/вставка и контекстная замена затруднены.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали: ВП>На Хабре опубликована моя статья по языку ДРАКОН: ВП>https://habr.com/ru/post/537294/ ВП>
Умеет ли человечество писать алгоритмы? Безошибочные алгоритмы и язык ДРАКОН
Человечество вообще ничего не умеет делать без ошибок. Ошибаются все.
В комментариях к статье на Хабре было много просьб привести доказательства утверждений, приведённых в статье, но это не было сделано.
Много эмоций по поводу аварии Боинга 737 MAX, но не приведено доказательств, что на Драконе нельзя сделать ту-же самую ошибку, которые допустили разработчики Боинга.
Много говорится про алгоритмы, но ничего не говорится ни про типы данных, ни про структуры данных.
Для гибридных языков объявление переменных делается средствами языка, который в паре с Драконом применяется.
А были ли попытки сделать язык, предназначенный для использования в Драконе?
Для примеров схем не приводится тот же самый алгоритм в псевдокоде, что бы сравнить схему и псевдокод и показать преимущество схемы.
набросайте, например, псевдокод для схемы покраски забора https://hsto.org/webt/4o/jo/nv/4ojonvww3gylmlj6hc0rkcwxfp4.png
Первое сообщение в этой теме сделано в 2012 году и за это время только 3 редактора появилось. Но в них и близко нет возможностей современных IDE, например — перехода к объявлению функции и поиска мест, где она используется. Так и не сделан контроль версий.
Рассмотрим простой пример из редактора — сравнение строк (взят первый попавшийся пример).
В экран не влезает
Это не способствует удобству работы и уменьшению числа ошибок.
В сгенерированном коде struct String объявлена как
struct String
{
char* Buffer;
int Length;
};
Но где эта структура в схеме задаётся?
В статье и комментариях много говорится про то, что goto это плохо, но посмотрим на
В этом коде goto применяется. Противоречние со статьёй.
А теперь, сравним с кодом, написанным традиционным способом
int String_Compare(
const struct String* left,
const struct String* right
)
{
int result = 0;
for ( int i = 0; i < left->Length && i < right->Length && !result; i++)
result = left->Buffer[ i ] - right->Buffer[ i ];
if ( !result )
result = left->Length - right->Length;
// Что бы возвращаемый результат был в том же виде, что и у сгенерированной функции.if ( result < 0 )
result = -1;
else if ( result > 0 )
result = 1;
return result;
}
Ни удобства, ни лучшего понимания, ни уменьшения вероятности ошибок, при использовании Дракона, я не вижу.
Если Вы видите, почему за много лет нет продвижения в создании удобных инструментов и примеров крупных работ?
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>На Хабре опубликована моя статья по языку ДРАКОН: ВП>https://habr.com/ru/post/537294/
Очень длинно, читать невозможно, всё жутко размыто, абсолютный промах по формату подачи. Такое впечатление, что Владимир изрядно оторван от реального мира и той аудитории, для которой готовит такие вот публикации. Усилий для них требуется колоссальное количество, но результат нулевой, как вода в песок и сквозь пальцы.
Имеет смысл пересмотреть структуру и подачу материала, вне зависимости от того, насколько он годный по существу, по качеству. Сам профессионально в разработке софта с 90-х, более четверти века, а реально читать подобное не в состоянии. Несмотря на привычку продираться сквозь многочисленные и убогие документации в корпоративном мире.
Если не удаётся достучаться до таких вот, то и до остальных не получится и подавно.
А спекуляция на катастрофе Боинг 737 MAX с кучей погибших не вызывает ничего кроме чувства гадливости, как посещение кладбища с разрытыми могилами.
Здравствуйте, Sinclair, Вы писали:
S>Ну да — ограничение возможности рисовать стрелки и произвольно размещать блоки в схеме гарантирует синтаксическую корректность алгоритма. S>Ну и что? Ценность её близка к нулю — синтаксические ошибки в современном мире вообще не являются предметом борьбы. S>Их в любом случае отловит компилятор; и 99.9% современных IDE указывают на такие ошибки ещё в процессе набора текста.
Наконец-то началась критика по существу.
Плюсик поставил.
Течёт вода Кубань-реки куда велят большевики.
Re[19]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, AleksandrN, Вы писали:
AN>Первое сообщение в этой теме сделано в 2012 году и за это время только 3 редактора появилось. Но в них и близко нет возможностей современных IDE, например — перехода к объявлению функции и поиска мест, где она используется. Так и не сделан контроль версий.
Ну, это не аргумент. Скажем для Немерла или Нитры тоже не хватает ресурсов качественную ИДЕ замутить. Но не от того, что языки плохие, а из-за того, что тупо нет людей готовых выделить средства.
Но вот я за недельки сбацан на них новый ДСЛ и таки душа радуется. Ни на каких Шарпах или СыПлюсПлюс такое за такие сроки не возможно сделать. А если вложить денег, то можно такие вещи не за неделю делать, а за пару дней.
Дракон это — тупо рисовалка блок-схем. Сделать к ней финтифлюшки вроде навигации более чем можно. Вопрос лишь в том, что за задачи он позволит решать (хоть с ними, хоть без них). Наверно есть класс задач, который он решит. Но согласен с Синклером — это точно не про корректность программ и не про AI.
AN>Это не способствует удобству работы и уменьшению числа ошибок.
+1
AN>В статье и комментариях много говорится про то, что goto это плохо, но посмотрим на AN> goto item_677;
Опять каша в мыслях. Сгенерированный код смысла читать нет. Генерировать можно и ассемблер, и Си, и MSIL. Это низкоуровневый язык генерации. Тебя ж не смущает, что в машкодах и ассемблере нет структурных операторов? Ты же их не читаешь? Собственно и генерацию можно улучшить. Просто блок-схемы они тяготеют к goto и проще на них отображаются. Но при некотором старании можно и в if-ы переписать. Почти любые goto можно в if-ы переписть. Возьми любой декомпилятор — это оно и есть.
Проблема Дракона не в этом. Проблема в том что ты написал выше. Нужно много экранов для описания вполне простых вещей. Т.е. выразительность блок-схем на сложных алгоритмах хромает.
Вот потому лично я тяготею к DSL-ям. Где выразительность рвет все пределы дозволено.
AN>В этом коде goto применяется. Противоречие со статьёй.
В Драконе их нет. Так что не гони. AN>А теперь, сравним с кодом, написанным традиционным способом AN>
AN>int String_Compare(
AN> const struct String* left,
AN> const struct String* right
AN>)
AN>{
AN> int result = 0;
AN> for ( int i = 0; i < left->Length && i < right->Length && !result; i++)
AN> result = left->Buffer[ i ] - right->Buffer[ i ];
AN> if ( !result )
AN> result = left->Length - right->Length;
AN> // Что бы возвращаемый результат был в том же виде, что и у сгенерированной функции.
AN> if ( result < 0 )
AN> result = -1;
AN> else if ( result > 0 )
AN> result = 1;
AN> return result;
AN>}
AN>
Откровенно говоря тоже говнокод. Я бы это написал как-то так:
Compare(xs : string, ys : string) : int
{
| (x : tailX, y : tailY) when x != y => x - y // строка состоит из символов префиксов и продолжения и префиксы не равны
| (x : tailX, y : tailY) when x == y => Compare(tailX, tailY) // тоже самое но префиксы равны, продолжаем рекурсивно...
| ([], _ : _) => 1 // xs содержит пустой список, а ys - нет.
| (_ : _, []) => -1 // наоборот
| ([], []) => 0 // все символы равны и списки пусты
}
Вот это как-то ближе к идеалу. Сводим все к рекурсии и абстракции списка. А твой императивный говнокод читается не лучше дракона, хотя он и пушистее. Вопрос ведь не в занимаемой площади на экране, а в том насколько просто код понять.
Ну, а от объемов позволяет избавиться банальное процедурное программирование. Вводим именованную функцию и она может скрыть любой по сложности алгоритм.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[20]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>На Хабре я опубликовал статью: ВП>
Как улучшить блок-схемы алгоритмов по ГОСТ 19.701-90? Эргономичный визуальный алгоритмический язык ДРАКОН. Критерии
ВП>https://habr.com/ru/post/541478/ ВП>Статья содержит критику стандарта ГОСТ 19.701-90 и обоснование необходимости создания нового стандарта для представления алгоритмов.
Мне кажется, что что за 10 лет пора бы было понять, что нельзя улучшить блок-съемы до уровня приемлемо для практического программировангия сложных систем. Да, что-то можно описывать в блок-схемах. Для детей осваивающих информатику. Или для каких-то далеких от программирования служащих от которых нужно описание бизнес процессов и можно удовлетворится примитивными описаниями. Но на них нельзя написать Виндоввс, Антивирус или сайт. Это слишком сложные задачи требующие более подходящих инструментов. Сосредоточьтесь на обучении. Там блок-схемы имеют право быть. Я сам учился на блок-схемах.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, VladD2, Вы писали:
VD>Мне кажется, что что за 10 лет пора бы было понять, что нельзя улучшить блок-съемы до уровня приемлемо для практического программирования сложных систем. Да, что-то можно описывать в блок-схемах. Для детей осваивающих информатику. Или для каких-то далеких от программирования служащих от которых нужно описание бизнес процессов и можно удовлетворится примитивными описаниями.
Это не совсем так.
Вот пример. Язык ДРАКОН в военно-патриотическом парке «Патриот»
на военно-техническом форуме «АРМИЯ-2021»
В рамках форума 26 августа 2021 состоялся Круглый стол:
«Актуальные вопросы развития и применения автоматизированных систем управления комплексом технических средств жизнеобеспечения объектов военной инфраструктуры»
Цель круглого стола:
— обмен опытом и информацией о новых научно-технических разработках в области создания и развития автоматизированных систем управления, мониторинга и контроля комплексов технических средств,
— объединение ведущих научных школ,
— поиск партнёров и установление деловых контактов.
Организатор Круглого стола:
9-е Управление Министерства обороны Российской Федерации
Модератор:
начальник 43 кафедры Военно-космической академии имени А.Ф.Можайского, доктор технических наук, доцент, полковник Абсалямов Дамир Расимович.
На круглом столе представлен доклад И.Е. Ермакова и А.М. Муравицкого:
Русский визуальный язык ДРАКОН — инструмент для быстрой и надёжной разработки алгоритмов систем управления
ie@iermakov.ru
a_muravitsky@okbamur3.ru
Краткое содержание доклада:
В ОКБ АМУР 3 разрабатывается широкий спектр управляющих алгоритмов для ПЛК, для разнообразных промышленных, инфраструктурных и коммунальных объектов.
По нашему опыту, все языки МЭК мало приспособлены для быстрой и надёжной разработки алгоритмов управления.
Они не отображают наглядно состояния управляющей системы, переходы между ними, различные сценарии и исходы каждого логического блока. Управление через дополнительные логические переменные ещё сильнее снижает наглядность.
Как следствие – разработка ведется «методом проб и ошибок», с последующей «агонией отладки».
Мы постоянно встречаем в открытых библиотеках на языке ST пропуски целых логических веток, игнорирование особых случаев – а ведь эти библиотеки используются на тысячах реальных объектов.
Как выход мы применили визуальный язык ДРАКОН (https://drakon.su/), который выводит на другой уровень наглядность и проверяемость алгоритмов управления, улучшает повторное использование логических блоков.
Становится возможной визуальная верификация алгоритма (это не исключает интерактивную отладку как дополняющий инструмент).
Ключевая особенность языка – двумерное структурное программирование, дающее большую свободу управляющих структур, чем классическое структурное программирование (см. И. Е. Ермаков, Н. А. Жигуненко. Двумерное структурное программирование; класс устремлённых графов. – https://drakon.su/_media/biblioteka_1/ermakov_zhigunenko.pdf).
ДРАКОН определяет однозначное размещение схем на плоскости, для автоматической реализации редакторами. Схема не рисуется, а быстро набирается блоками.
В продуманной до мелочей наглядности, обозримости сценариев, в расширенном структурном программировании, в строгом размещении на плоскости – отличие ДРАКОНа от всех нам известных визуальных алгоритмических схем.
Кроме того, ДРАКОН непосредственно поддерживает программирование на основе конечно-автоматной модели.
Опыт ОКБ АМУР 3 по разработке систем управления на основе ПЛК ОВЕН, с генерацией кода на ST из ДРАКОН-схем:
— насосные станции;
— станции высокого давления СОЖ;
— станции поддержания пластового давления;
— тепловые пункты и вентиляционные установки;
— водозаборно-очистительные узлы;
— туннельные водооткачивающие установки;
— сверлильные станки;
— гибочные прессы;
— координатно-режущие станки;
— пищевые производства (пивзаводы и др.);
— процессы взаимодействия ПЛК с базами данных SQL.
Мы использовали ДРАКОН-редактор предыдущего поколения (ИС ДРАКОН), который позволял чертить схемы и в полуручном режиме генерировать ST-код.
В настоящее время мы ведём разработку новой интегрированной среды программирования ПЛК на основе ДРАКОН-схем.
Её преимущества: поддержка проекта ПЛК в целом, высокопродуктивный ДРАКОН-редактор с быстрым вводом схем, поддержка сильной инкапсуляции и повторного использования блоков, экспорт проекта в формате PLCopenXML.
Результатом нашего проекта должна стать отечественная универсальная визуальная система программирования ПЛК нового поколения.
Доклад вызвал интерес участников Круглого стола.
С уважением В. Паронджанов
Re[22]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>b]Круглый стол: [/b]
Вот для круглых столов он отлично подходит. А для написания сложных систем — нет. Ты пойми. Есть понятие объема. Вот я сейчас работаю в Касперском. Код антивируса занимает гигабайты. Одна сборка продута идет десятки минут. С тестами — часы. Код в системе контроля версий. Для иго изменения используются пулреквесты на которых тесты гоняются. Одновременно код меняют сотни человек. Как я буду мержить эти блоксхемы?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[23]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, VladD2, Вы писали:
VD>Вот для круглых столов он отлично подходит. А для написания сложных систем — нет. Ты пойми. Есть понятие объема. Вот я сейчас работаю в Касперском. Код антивируса занимает гигабайты. Одна сборка продута идет десятки минут. С тестами — часы. Код в системе контроля версий. Для иго изменения используются пулреквесты на которых тесты гоняются. Одновременно код меняют сотни человек. Как я буду мержить эти блоксхемы?
Я с уважением отношусь к вашей работе у Касперского. Впечатляет.
Но отвечать на ваш вопрос не берусь.
На этот вопрос можете ответить вы сами (если захотите).
Сожалею, что вы невнимательно прочитали текст доклада на круглом столе военно-технического форума АРМИЯ-2021.
Поэтому напомню важные факты:
Опыт ОКБ АМУР 3 по разработке систем управления на основе ПЛК ОВЕН, с генерацией кода на ST из ДРАКОН-схем:
— насосные станции;
— станции высокого давления СОЖ;
— станции поддержания пластового давления;
— тепловые пункты и вентиляционные установки;
— водозаборно-очистительные узлы;
— туннельные водооткачивающие установки;
— сверлильные станки;
— гибочные прессы;
— координатно-режущие станки;
— пищевые производства (пивзаводы и др.);
— процессы взаимодействия ПЛК с базами данных SQL.
Список показывает, что ДРАКОН уже успешно работает, уже используется для практического программирования.
Предметная область ПЛК (программируемые логические контроллеры).
Если кто сомневается, можно задать вопросы Главному инженеру ОКБ АМУР №3 Алексею Михайловичу Муравицкому a_muravitsky@okbamur3.ru
Да, это не сложные системы. Но это первые шаги.
Посмотрим, что будет дальше.
Будущее покажет.
Подведем итоги.
VladD2 писал:
Да, что-то можно описывать в блок-схемах. Для детей осваивающих информатику. Или для каких-то далеких от программирования служащих от которых нужно описание бизнес процессов и можно удовлетворится примитивными описаниями.
Это не так. На самом деле, речь идет не о «каких-то далеких от программирования» вещах, а о настоящем программировании.
Теперь о сложных системах. Возможно, именно вы, VladD2, со временем предложите что-нибудь дельное о применении языка ДРАКОН.
С уважением В. Паронджанов
Re[24]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Владимир Паронджанов, Вы писали: ВП>Список показывает, что ДРАКОН уже успешно работает, уже используется для практического программирования.
Ну, само по себе это никакой не показатель.
ВП>Предметная область ПЛК (программируемые логические контроллеры).
Вопрос не в том, можно ли программировать ПЛК с помощью Дракона. А в том — какую пользу это даёт?
Вот я прочитал вашу статью на Хабре.
Задал по ней конкретные вопросы. Ответа не получил. Утверждения про то, что Дракон помогает предотвращать ошибки, остались голословными.
Ну, ок — ваша умозрительая задача про запуск космического корабля, рассмотренная в статье, остаётся умозрительной. Но раз кто-то программирует ПЛК, то, наверное, сталкивается с реальным оборудованием и реальными ограничениями.
Вот тут-то и можно поговорить о том, как Дракон помогает (если помогает) обеспечить выполнение инвариантов, которые нужны для железа.
Классический пример, который у нас только что рассматривали на лекции по верификации софта:
Допустим, у нас есть глобальный параметр x — знаковое целое.
И есть три процедуры, которые с ним работают. Процедуры работают параллельно, реагируя на входные сигналы, поступающие независимо:
public void Increment()
{
if(x < 200) x = x + 1;
}
public void Decrement()
{
if(x > 0) x = x - 1;
}
public void Reset()
{
x = 0;
}
От железячников поступила информация: безопасные значения x находятся в диапазоне [0; 200]. Если мы попробуем скормить в исполнительную систему другие значения x — установке кирдык.
1. Есть ли ошибки в этих процедурах? Т.е. сгорит ли наша установка при такой реализации контроллера, или нет?
2. Можем ли мы применить магию языка Дракон для того, чтобы обнаружить ошибки (если они есть)?
3. Поможет ли язык Дракон исправить ошибки, если они будут найдены?
Честно ответив на эти вопросы, вы определите место Дракону в мире промышленной разработки.
ВП>Теперь о сложных системах. Возможно, именно вы, VladD2, со временем предложите что-нибудь дельное о применении языка ДРАКОН.
Наверное, на этом языке можно учить детишек основам информатики. Для записи алгоритмов типа евклидова целочисленного деления — самое то. Конечно же, детям будет удобнее рисовать блок-схемы в специальном редакторе, который заточен только под дракон-диаграммы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, VladD2, Вы писали:
VD>Вот для круглых столов он отлично подходит... Как я буду мержить эти блоксхемы?
Основной(а может и единственный) плюс блок-схем — это 2D визуализация, а не плоский 1D текст.
Поэтому тебе достаточно было бы кнопку-опцию в VisualStudio — показать ветки if-else таблицей — одна слева, другая справа. Только отображение на экране, а cам текст в файле остается тот же. Может и для switch такое же. Может еще мелкие детали, например, прямоугольник вместо "{}".
Но чтобы от этого была польза надо:
1) Много if-else с обеими ветками(если одна, то нагляднее плоским текстом), и желательно вложенных и с маленькими телами. Но в мейнстриме сейчас такого мало.
2) Обязательно чтобы оно уместилось на одном экране. Это нереалистично, в мейнстриме дают очень длинные имена.
Но есть ниши, например, разработка для контроллеров — там много разных графических визуализаций. Может там будет полезно?
Re[24]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Silver_S, Вы писали:
S_S>Но чтобы от этого была польза надо: S_S>1) Много if-else с обеими ветками(если одна, то нагляднее плоским текстом), и желательно вложенных и с маленькими телами. Но в мейнстриме сейчас такого мало. S_S>2) Обязательно чтобы оно уместилось на одном экране. Это нереалистично, в мейнстриме дают очень длинные имена.
Взаимно противоречащие требования. На самом деле можно и скороилть. Видел как parallel steak в Студии и Райдере сделан? Там по нему можно прекрасно перемещаться по уменьшенной миниатюре в углу.
Проблема в самом представлении кода в таком виде.
S_S>Но есть ниши, например, разработка для контроллеров — там много разных графических визуализаций. Может там будет полезно?
С этим связан не был. Но что-то мне кажется, что и там блоксхемы не очень то подойдут для реальной жизни.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Владимир Паронджанов, Вы писали:
ВП>Язык Дракон значительно облегчает алгоритмизацию и программирование
Пришла в голову мысль, что 99% промышленных программистов не занимаются "алгоритмизацией и программированием" в его олдскульном виде, когда есть спецификация процесса и его необходимо изложить кодом. Большинство современного программирования — это СRUD и преобразования потоков данных, а не рисованные блок-схемы с кучей нелогичных (для неспециалиста) ветвлений с последующей верификацией.
Но есть BPML/BPMN, есть saga pattern, есть задачи координации выполнения бизнес-процессов в микросервисной системе. Где уже применяются блок-схемы и где первичны не типы, структуры данных и циклы, а последовательность действий и условные ветвления. Думаю, дракон в современном мире можно продвигать как BPM движок.
Re[25]: Язык ДРАКОН — новая идея в программировании
VD>Откровенно говоря тоже говнокод. Я бы это написал как-то так: VD>
VD>Compare(xs : string, ys : string) : int
VD>{
VD> | (x : tailX, y : tailY) when x != y => x - y // строка состоит из символов префиксов и продолжения и префиксы не равны
VD> | (x : tailX, y : tailY) when x == y => Compare(tailX, tailY) // тоже самое но префиксы равны, продолжаем рекурсивно...
VD> | ([], _ : _) => 1 // xs содержит пустой список, а ys - нет.
VD> | (_ : _, []) => -1 // наоборот
VD> | ([], []) => 0 // все символы равны и списки пусты
VD>}
VD>
VD>Вот это как-то ближе к идеалу. Сводим все к рекурсии и абстракции списка. А твой императивный говнокод читается не лучше дракона, хотя он и пушистее. Вопрос ведь не в занимаемой площади на экране, а в том насколько просто код понять.
А вот так нельзя? Или можно, но читается хуже?
Compare(xs : string, ys : string) : int
{
| (x : tailA, x : tailB) => Compare(tailA, tailB) // префиксы равны, продолжаем рекурсивно...
| (x : tailX, y : tailY) => x - y // префиксы не равны
| ([], _ : _) => 1 // xs содержит пустой список, а ys - нет.
| (_ : _, []) => -1 // наоборот
| ([], []) => 0 // все символы равны и списки пусты
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, Sinclair, Вы писали:
S>А вот так нельзя? Или можно, но читается хуже?
S>
S>Compare(xs : string, ys : string) : int
S>{
S> | (x : tailA, x : tailB) => Compare(tailA, tailB) // префиксы равны, продолжаем рекурсивно...
S> | (x : tailX, y : tailY) => x - y // префиксы не равны
S> | ([], _ : _) => 1 // xs содержит пустой список, а ys - нет.
S> | (_ : _, []) => -1 // наоборот
S> | ([], []) => 0 // все символы равны и списки пусты
S>}
S>
Так получается бессмыслица. Конструкция x : tailA означает образец не пустого списка где первый элемент помещается в локальную переменную x типа строка, а хвост списка в переменную tailA. Строка при этом представляется в виде однонаправленного связанного списка.
В твоем коде первая строка попросту теряет первые элементы списков и безусловна начинает сравнивать их хвосты. Вторая строка у тебя никогда не выполнится и компилятор просто не должен позволить скомпилировать этот код. В моем же примере у паттернов есть гуарды when x != y и x == y. Так что секция срабатывает только при когда они вычисляются в true. Так как условия взаимно исключающие, выполнится одна из двух секций. Паттерн _ : _ означает любой не пустой список (т.е. имеющий один или более элементов). _ — означает безымянная переменная сопоставляемая с чем угодно. [] означает пустой список. Таким образом мы
| (x : tailX, y : tailY) when x != y // это паттерн сопоставляется когда оба списка не пусты и первые символы строки не равны.
| (x : tailX, y : tailY) when x == y // это паттерн сопоставляется когда оба списка не пусты и первые символы строки равны.
| ([], _ : _) => 1 // это паттерн сопоставляется когда первый список пуст, а второй содержит по меньшей мере один элемент
| (_ : _, []) => -1 // это паттерн сопоставляется когда первый список содержит по меньшей мере один элемент, а второй пуст
| ([], []) => 0 // это паттерн сопоставляется когда оба списка пусты
Сумма всех паттернов с гуардами охватывает все возможные значени переменных xs и ys.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[21]: Язык ДРАКОН — новая идея в программировании
Здравствуйте, VladD2, Вы писали:
VD>Так получается бессмыслица. Конструкция x : tailA означает образец не пустого списка где первый элемент помещается в локальную переменную x типа строка, а хвост списка в переменную tailA. Строка при этом представляется в виде однонаправленного связанного списка.
Я надеялся, что одна переменная связывается только с одним значением, так что (x:y, x:z) матчит строки с одинаковой головой и произвольными хвостами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.