Здравствуйте, Privalov, Вы писали:

P>По-моему, гораздо удобнее, когда служебные слова языка можно использовать только как таковые.

Но при этом нужно сохранять возможность каким-то (помеченным) образом задавать идентификаторы, совпадающие с ключевыми словами. Во всех более-менее адекватных современных языках такое есть (C#: @if, Rust: r#if, Swift: `if`, Erlang: 'if', Go: экспортируемые идентификаторы с заглавной буквы, и так далее).
C, C++, Java в этом смысле образец подходов допотопья.

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

P> Я думал, это очевидно любому, кто читал чужой код.

Не совсем. Могут использоваться другие меры, а можно просто писать так, чтобы не абьюзить фичу попусту.
Переименовать внутренние идентификаторы (внутри процедуры/функции/модуля) тривиально. Остаётся крошечная часть внешних.

кт>>Ну да, поэтому слова и незарезервированы.
P>Чтобы говнокод плодить? Его и так достаточно.

Для легаси. Вон в C++ ввели co_await. А если у кого-то такое в библиотеке было, всё срочно переименовывать?

P>Служебного слова. Ключевых в Pl/1 нет. Идентификатор вполне может иметь имя, совпадающее со служебным словом. Как и метка. И вот тогда начинаются неоднозначности. Об этом еще в годы, когда PL/1 был популярен, многие писали. И ладно бы просто так писали. Ведь по следам разбора такого кода. В то время только по распечаткам, да с маркером в руках. Это сегодня хорошая IDE может отличить, как используется слово: как служебное или как идентификатор. Но в случае с Фортраном или PL/1 трудоемкость такого анализа слишком высока. В Фортране раньше хоть метки только числовые были.

В Фортране из-за парсинга пробелов чудеса веселее, ты в курсе