Лекции по построению компилятора на Pascal
#### a=b c= d e=e+1
Я полагаю, что это главная... возможно единственная... причина точек с запятой: не давать
программам выглядеть странно.
Но идея со связыванием множества утверждений вместе в одну строку в лучшем случае
сомнительная. Это не очень хороший стиль программирования и возвращение назад к дням,
когда считалось важным сэкономить карты. В наши дни CRT и выровненного кода ясность
программ гораздо лучше обеспечивается сохранением раздельных утверждений. Все-таки
хорошо иметь возможность множественных утверждений, но это позор - оставлять
программистов в рабстве у точек с запятой только чтобы этот редкий случай не "выглядел
странно".
Когда я начинал KISS, я попытался держать глаза открытыми. Я решил, что буду
использовать точки с запятой когда это станет необходимо для синтаксического анализатора,
но только тогда. Я рассчитывал, что это случится примерно в то время, когда я добавил
возможность разложения утверждений на несколько строк. Но как вы можете видеть это
никогда не случилось. Компилятор TINY совершенно счастлив анализировать наиболее
сложные утверждения, разложенные на любое число строк, без точек с запятой.
Однако, есть люди, которые использовали точки с запятой так долго, что они чувствуют себя
без них голыми. Я один из них. Как только KISS стал достаточно хорошо определен, я
попробовал написать на этом языке несколько программ-примеров. Я обнаружил, к своему
ужасу, что пытаюсь в любом случае расставлять точки с запятой. Так что теперь я стою
перед перспективой нового потока ошибок компилятора, вызванных нежелательными
точками с запятой. Тьфу!
Возможно более важно, что есть читатели, которые разрабатывают свои собственные языки,
которые могут включать точки с запятой или которые хотят использовать методы из этого
руководства для компиляции стандартных языков типа C. В обоих случаях, нам необходима
возможность работать с точками с запятой.
СИНТАКСИЧЕСКИЙ САХАР
Вся эта дискуссия поднимает вопрос "синтаксического сахара"... конструкций, которые
добавлены к языку не потому, что они нужны, но потому, что они заставляют программы
выглядеть правильно для программиста. В конце концов, хорошо иметь маленький простой
компилятор, но от него было бы мало пользы если бы полученный язык был
закодированным или сложным для программирования. На ум приходит язык FORTH. Если
мы можем добавить в язык возможности, которые делают программы более легкими для
чтения и понимания, и если эти возможности предохраняют программиста от ошибок, тогда
мы бы сделали это. Особенно если эти конструкции не добавляют слишком много сложности
в язык или его компилятор.
Как пример можно было бы рассмотреть точку с запятой, но существуют множество других,
такие как "THEN" в операторе IF, "DO" в операторе WHILE или даже утверждение
"PROGRAM" которое я убрал из TINY. Ни один из этих токенов не добавляет много к
синтаксису языка... компилятор может выяснить, что происходит и без них. Но некоторые
люди чувствуют, что они улучшают читаемость программ и это может быть очень важно.
Существуют две школы мысли на эту тему, которые хорошо представлены двумя из наших
наиболее популярных языков C и Pascal.
По мнению минималистов весь подобный сахар должен быть выброшен. Они доказывают,
что это загромождает язык и увеличивает число нажатий клавиш, которое должен сделать
программист. Возможно более важно, что каждый дополнительный токен или ключевое
слово представляет собой ловушку, лежащую в ожидании невнимательного программиста.
Если вы не учтете токен, пропустите его или сделаете в нем орфографическую ошибку,
компилятор достанет вас. Поэтому эти люди утверждают, что лучший подход - избегать