Пресловутая совместимость с языковыми возможностями Паскаля от Н.Вирта… Если в языке метки есть, они либо должны работать, либо должны быть четко прописаны где-то ограничения на работу с ними в данном диалекте языка. В противном случае приходится обращаться с этой системой, как с “черным ящиком”, отсюда и пионерские “обнаружения”…
Пора вводить предупреждения при использовании goto, место которому только в ассемблере.
Я не сомневаюсь в Вашей высочайшей квалификации, но предлагаю Вам взять фортрановскую программу (хотите, я перепишу её на псевдокод) и реализовать в Паскале заложенный в ней алгоритм без “go to”. И засечь время, которое у Вас уйдет на реализацию и отладку. А потом вспомнить, что есть школьники, студенты и даже молодые выпускники, не имеющие Ваших знаний и опыта. И подумать, сколько времени понадобится на подобную работу им. Вы можете возразить, конечно, что это никому не нужно, что есть готовые пакеты… что же, попробуйте найдите готовый бесплатный пакет, к которому сможете обратиться и который будет решать необходимую задачу. Просмотрите алгоритмы, которые приводит в своем трехтомнике Д.Кнут - алгоритмы, не MIX-коды. Они содержат переходы по шагам. Потому что классика описания алгоритма - это переходы по пунктам-меткам.
В целом, можно убрать метки из Паскаля. Только тогда давайте его не будем называть языком Паскаль…
1 лайк
ну допотопный код при переводе на современные языки или версии языка надо рефакторить, приводить к удобочитаемому и поддерживаемому виду. такова программистская жизнь.
Верно. Это тоже требует времени, знаний, умений и инструментария, не так ли? Вот, к примеру, есть книженция “Структурный подход к программированию”, Джоан К. Хьюз, Джей И. Мичтом, М.: «Мир», 1980. Её при наличии желания можно стащить отсюда Там авторы добрых полторы сотни страниц разбираются, как структурировать коды, чтобы “без goto”. Т.е. все же это задача нетривиальная. Уберите метки из ABC.NET - и Вы отправите людей решать подобные задачи в FPS. Вернутся ли они потом - еще вопрос…
Да никто их не будет убирать из языка.
И то хорошо…
Ну приведите код с goto, который сложно перевести на нормальный структурный язык.
Компилятор, конечно, всегда прав, когда нет формальной спецификации языка… Хотя, согласен, что “мертвый код” на этапе исполнения и область видимости блочных переменных на этапе компиляции – разные вещи. Но уверен, что это не для всех очевидный факт и стоило бы этот момент явно прописать, хотя бы в справке пока.
З.Ы. Думал, что помогаю тестировать/отлаживать образовательный продукт, ан нет, оказалось, “безобразиями и сумасшествием занимаюсь” :)) Ну, ладно, от добра добра не ищут, как говорится…
Проблема не в том, чтобы фрагмент перевести. Проблема перевести программу, чтобы она работала так же, как работала в старой ипостаси. Плюс дополнительно накладываются ограничения. Например у меня сейчас они таковы, что нельзя дробить программу на отдельные структурные единицы. Есть простой подход в структуризации - все, куда делается переход, объявляем процедурами и вместо перехода вызываем их. Понятнее программа не становится, но уходят goto. Я чуть позднее приведу Вам код, на котором сейчас несколько подзастярл. К сожалению форум - не лучший механизм для диалога, но альтернативных мне не сообщают))
Вот моя старая программка, работающая в ТурбоПаскаль. В свое время делал на Фортран, потом перенес в Паскаль “as is”., Я сейчас с ней разбираюсь… можете попробовать структурировать. У меня на нынешний момент осталось две метки)) MIN104.PAS (4,4 КБ)
А вот еще один способ избавления от меток. Но кто сказал, что логика программы при этом стала понятнее или программа короче? 000.txt (1,3 КБ)
Сейчас меня, наверное, предадут анафеме, но я все же рискну продолжить свои безобразия 
label _1, _2;
begin
goto _1;
_1:; // Нет ошибки компиляции -- и правильно! ;)
var x := 123;
goto _2;
_2: // Уже ошибка? "Нельзя устанавливать метки на описании переменных"
var y := 456;
write(x, y)
end.
Видимо, хотели заблокировать попытки перехода на раздел описаний, а в итоге досталось и блочным переменным…
Забавно, что я не только параллельно обратил внимание на ту же проблему, что и вы, но и, фактически, уже использовал в своем тестовом примере то же решение, которое предложил один из разработчиков. Хотя, конечно, это довольно банальный случай.
Я не стал ставить пустой оператор, потому что где-то уже нарвался на случай, когда его компилятор забраковал. Счел, что нарываться снова себе дороже)))
Исправим. Это не гигантская проблема.
По поводу goto - это я смеюсь конечно. Потому что до какого-то момента мы следовали стандарту языка, и goto работали. Потом стали вводить новые конструкции пачками и - известно - что есть некая интерференция - новые конструкции валят старые. Причем, не сразу, а вот так - выясняется спустя… Так вот, goto - рекордсмен по интерференции с другими конструкциями.
Всё это ошибки конечно. Тут нет другого пути - надо всё это исправлять и всё.
ЗЫ. Если бы Вы знали, какой автогенерится код при раскрутке yieldа! Там - не только кишьмя кишит goto, да ещё есть goto внутрь блока.
Исправили ещё раз. Пробуйте.
Это внутренняя кухня, сгенерированная программой и её пользователь не видит. А исходники пишутся людьми и для людей. Ясно, что есть хорошие, правильные стили написания кода, а есть и совсем неудовлетворительные. Но даже самый непристойный исходник, если он синтаксически верен, все же должен давать работающий код. У меня есть старая программка, которая сделана была под ТурбоПаскаль в 1993 году. Я адресовал её @ibond - вот Она пока что работает в PascalABC.NET 3.2. И это правильно, так и должно быть. Код жуткий даже по уровню тех лет, потому что была в спешке портирована с Фортран-77. Вот сейчас хочу кое-что там модифицировать, причесать и поместить в пакет численных методов - это поиск минимума функции многих переменным достаточно забавным способом:модифицированным методом Монте-Карло с уточнением решения по Хуку-Дживсу. Изначально было писано в машинных кодах (!) для небольшой ЭВМ “Наири-К” с 2048 машинными словами оперативной памяти и к нам на кафедру очередь стояла по ней считать)))
Я имел в виду исправление вот этого кода
Тогда приношу извинения.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021