OberonCore

Хороший оператор, часто хочется его иметь, чтобы выражать вот эту... синхронность смены состояния.

Мне тоже нравится.
Тогда еще по поводу if-fi спрошу.
По аналогии с циклом можно сделать так:

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

Нет, не лучше. Лучше иметь оба варианта. И вот почему:

1) Давно ощущается потребность в чем-то среднем между операторами case и if, что бы по-возможности объединяло прозрачность, однозначность и надежность case с гибкостью и быстротой записи if.

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

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

Я бы еще добавил дефолтную ветку else.


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

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

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

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

Для одного (или вообще для первого) выражения значок | можно пропустить.
А вот repeat получается плохо.

После do перед end - пусто.
Значок ~ означает отрицание
1. Значит ли это, что сам Дейкстра предпочитал подсознательно цикл while. Я, кстати, тоже практически НИКОГДА не использую цикл repeat по причине постоянных ошибок в логическом выражении цикла, и цикл do-while тоже. Хотя в последнем случае ошибок не делаю.
2. Значит ли это, что в язык нужно добавлять обычные формы циклов.
Похоже, что надо.
Второй пример я бы хотел видеть таким:

Фактически это - синтаксический сахар.
Но цикл со счетчиком - по-любому добавить придется.
Тут тоже вариантов много. На РСДН в теме о техникеи программирования один даже написал:

Вопрос в том, делатьь ли foreach или традиционную форму с явной переменной цикла?
ИМХО foreach - это тоже синтаксический сахар. Явная переменная нам позволяет же и вычисления выполнять, а не только перебирать элементы контейнера.
Поэтому я склоняюсь к явной переменной. Но, может быть, еще и foreach добавить? Или поступим как в С++ - алгоритм foreach включим в библиотеку?

Мое мнение:

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

2) Не стоит отказываться от абстрактных лаконичных высокоуровневых конструкций (foreach) только потому, что их можно моделировать низкоуровневыми (for). Параметр цикла нужен не всегда, и зачем в таком случае загромождать программу лишней переменной? Да и вообще, запись на языке программирования должна быть как можно ближе к тем терминам, в которых изначально думает разработчик. Он ведь думает так: перебрать все элементы массива (вариант: записи файла). Вот если вдруг в теле цикла понадобится параметр, тогда у программиста должна быть возможность парой щелчков мыши заменить foreach на for с уже подставленным по умолчанию параметром.

3) Традиционные конструкции while и if не должны быть частными случаями многоветочных. Они должны быть совершенно самостоятельными элементами коллекции управляющих конструкций.

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

5) Цикл repeat, возможно, нуждается в коренной переделке. Он может стать по синтаксису ближе к while: условие должно переместиться в заголовок цикла и потерять отрицание. Скорее всего, к while просто будет добавлен какой-то параметр. Что-то более конкретное я пока не придумал.

6) В многоветочных конструкциях вроде case вертикальные черточки имеет смысл заменить на кружочки, квадратики, ромбики или тругольные стрелки, которыми обычно выделяют перечисляемые абзацы. И вообще, нужно широко использовать юникод. Программа в семантическом редакторе - это не текст, и поэтому можно вполне избавиться от аскетизма "текстовых" языков программирования. Например, сравнения => и <= нужно заменить обычными математическими знаками, а двухсимвольный оператор присваивания - каким-нибудь юникодовским значком вроде ←.

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

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

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

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

Это не дело.

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

Согласен. Но меня трудно упрекнуть в экстремизме. Если декларативная форма в каком-то конкретном случае недостаточно очевидна, то надо возвращаться к процедурной.


Теперь об операторе foreach. Можно, в принципе, соединить преимущества этого оператора с преимуществами оператора for:



эквивалентно

Вот! Илья, как всегда, все очень хорошо сформулировал!

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

Ну, мы и признаем полезным... Илья - в настоящем, я - в прошлом - профессиональные программисты...

Прям как в том анекдоте: "А чего нас бояться?"

Нет, я имел в виду, когда широкие программистские массы отшвырнут подальше Вижуалстудию, Эклипс и Дельфи ради семантического редактора, а Микрософт с Гуглом и Ораклом наперегонки будут предлагать миллиарды за Вашу компанию (или бесплатно воровать идеи).

Вот вариант многоветочных конструкций, о которых писал Валерий Лаптев:



В данном случае код приспособлен под структурный/семантический редактор. Поэтому код не содержит "end" и ";", которые заменяются графическими элементами.

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

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

Зачем нужна альтернативная форма цикла Дейкстры, понять я так и не смог.

Но вот проблемка его оптимизации (как и простого WHILE), ощущается.
Оптимизации в том смысле, что операнды конъюнкции в охранах могут быть сложными и вычисляться с побочными эффектами.
Например, некое условие может получаться как OUT-результат процедуры.
Это единственная ситуация, в которой у меня есть несколько LOOP-ов.

Конечно, можно обернуть (вычисление операнда) в локальную процедуру, но как вариант можно подумать про такой вариант LOOP:

Во-первых, допускаются несколько веток. Для конкретности пусть будет ключевое слово BRANCH:

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

Дальше: EXIT запретить, но вместо него требовать, чтобы в каждой ветке -- и обязательно только на самом верхнем уровне -- присутствовал хотя бы один оператор "охраны", аналогичный ASSERT, например, в таком виде:
GUARD( логич. условие );
Смысл оператора: при выполнении условия выполнение ветки продолжается;
в противном случае попадаем в точку сразу после следующего BRANCH, а если такого нет, то последнего END.

Например, лин. поиск

переписывается так:


Долго думал и укрепился во мнении, что никаких других вариантов LOOP не должно быть нужно при систематическом построении циклов.

Можно и вообще выкинуть LOOP, разрешив такой GUARD в обычном WHILE ... DO ... ELSIF ... DO ... END,
-- вряд ли WHILE TRUE будет накладно, а может и компилятору будет нетрудно интерпретировать такое как чистый LOOP.

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

... а кто-нить из благородных донов не соблаговолит объяснить весь изначально-глубинный смысл мероприятия? ...

ЗЫ в смысле: "а, за что, собственно, боремся?"

Была ли количественно измерена практическая потеря производительности при таком "оборачивании"?

Функция с побочным эффектом... Непривычно, не нравится как-то. Хотя, может быть, предрассудок в данном случае.